Elements Manual
Elements 2 Manual
Elements 2 Manual
  • Welcome 👋
  • QUICK START
    • Elements in Five Minutes or Less
  • General
    • General Concepts
    • N-Tier Architecture
    • Security Model
  • SCRIPTING ENGINE
    • Scripting Engine Overview
      • Intro to Resources and Cloud Functions
      • Horizontal Scaling Model
      • Database Access
      • Server-to-Server API Calls
      • Deploy Cloud Functions via Git
      • Creating and Destroying Resources
      • Cross-Resource Invocation
      • Indexing Resources
      • Coroutines
      • Manifest
  • Core Features
    • Core API Overview
    • Sessions
    • Applications
      • Facebook Application Configuration
      • Firebase Application Configuration
      • Amazon GameOn Application Configuration
      • iOS Application Configuration
      • Android Application Configuration
      • Matchmaking Application Configuration [deprecated]
    • Users and Profiles
    • Digital Goods
    • Progress and Missions
    • Leaderboards
    • Matchmaking
    • Followers
    • Friends
    • Reward Issuance
    • Push Notifications
    • Auth Schemes
    • Save Data
    • Schemas and Metadata Specifications
    • Queries
      • Base Query Syntax
      • Boolean Queries
      • Object Graph Navigation
      • Advanced Operators
        • .ref
        • .name
  • Web 3
    • Omni Chain Support
    • Vaults
    • Wallets
    • Smart Contracts
      • Smart Contracts: Ethereum
      • Smart Contracts: Flow
      • Smart Contracts: Solana
      • Smart Contracts: Neo
    • Know Your Customer
      • Formidium
  • CONFIGURATION
    • Using the Web Console
    • iOS and Android Product Bundles
    • Direct Database Access and Batch Configuration
  • UNITY PLUG-INS
    • Unity Plugin
    • Content Delivery Management and Unity CDN Plugin
  • DEPLOYMENT
    • Deployment Overview
      • Docker Containers
      • AWS Deployment
      • Standalone docker-compose
  • LUA SAMPLES
    • lua Samples
      • main.lua
      • event.lua
      • hello_world.lua
      • model.lua
      • startup.lua
      • HTTP Manifest
        • Example endpoint handler
        • Example operations table
  • RESTful APIs
    • Swagger and Swagger UI
    • Elements 3.0.X (Preview)
      • Applications
      • Friends and Followers
      • Digital Goods and Inventory
      • Leaderboards
      • Missions and Rewards
      • User and Profiles
      • Save Data
      • Custom Metadata
Powered by GitBook
On this page
  • User Access Levels (Detailed Overview)
  • Single Sign-On
  • Facebook Single Sign-On
  • Apple Sign-In
  • Username/Password Sign-In
  • Create new User
  • Sign in with existing User
  • Create New Profile
  • Fetch Existing Profiles
  • Add Profile Id to Session Key
  1. General

Security Model

Elements offers a proven security model with three levels of access for users. Take advantage of SSO with Facebook and Apple accounts, or native account login - all with profile management.

PreviousN-Tier ArchitectureNextScripting Engine Overview

Last updated 2 years ago

Elements uses a three-tiered security model through a single API. When accessing the API a user may access at one of three access levels. Briefly, these include:

  • Anonymous - the user is not logged in or has not provided any valid access credentials.

  • User - the user is a regular user and can access some APIs intended for the general purpose users.

  • Superuser - the user can access full APIs which generally includes access to all records in the system.

User Access Levels (Detailed Overview)

Currently, a user may have one of the three following access levels. This applies to the User's entire account. Across all of Elements, the security model applies as follows:

  1. Anonymous (or Unprivileged) provides access to information that is considered public. Few APIs will supply information when used without any kind of credentials. Some APIs may only return limited sets of data at this level. Anonymous is the default access level and tends to grant very little access. If the client supplies no credentials, Elements will process all requests at this level. It is possible to greatly restrict a logged-in User's access by assigning this level. This will give the user the same access level as if they were not logged in. It may, however, still allow for valid session creation.

  2. User is the level of access for all authenticated users. This is what the average user will use when accessing your applications. When creating new accounts, the system will automatically assign users to this level of access. User is the access level for normal users. Additionally, it is the default level for making new accounts. Only a Superuser may escalate a user's access level allowing for access to the whole system. In general, users of your application should always be assigned this level.

  3. Superuser allows for complete control over the system. APIs may return all information requested. Admins may perform operations such editing user accounts, resetting passwords for other users in the system, or adjust the application parameters. Using the requires superuser access.

Important:

  • Elements intercepts incoming requests as soon as possible, reads credentials information, and applies scope based on the user-supplied credentials.

  • For a majority of endpoints, including those defined as cloud functions in the scripting engine, the user scope will be set before the presentation layer receives the code.

  • Elements will instantiate the specific version of a based on the access level.

Elements provides a Swagger definition for its APIs with every release. When running the local instance, you may always access the latest documentation at to see the current documentation for the deployed build.

Additionally, when troubleshooting, it is often times useful to fetch the version endpoint which prints out the revision, build time, and version number by visiting this link in your local browser . This information should also be visible upon logging in to the admin console.

At the time of this writing, Elements does not support full user segmentation by group and permission scheme. This is a feature slated for future releases. However, future versions will still operate against group-based access. (TODO: Describe in more detail)

Single Sign-On

Facebook Single Sign-On

Apple Sign-In

Username/Password Sign-In

Username/password sign in is the default method of authentication within Elements.

Create new User

When someone signs up for Elements (via the UserSignupApi), they must provide a user name, a password, and an email address. This will provide you with the new User object in the response, which will be needed for the next step.

Sign in with existing User

After creating the new User, or if someone has already created a User in Elements, they can retrieve a session key with just the Username and Password via the UsernamePasswordSessionApi. This will return a SessionCreation object that contains the SessionSecret property, which is your session key.

Once the session key has been retrieved, you can then authenticate User related requests by adding the session key to the singleton client configuration in your generated code. For example:

C#
Server.Elements.Client.Configuration.ApiKey["Elements-SessionSecret"] = <SessionSecret>;

There will likely be two configurations, one for Elements and one for your application. It will be necessary to add the same session secret to both of these.

Adding this will automatically add the session key to any requests that require auth.

Most requests are profile related, so we are not quite done with the login process yet.

Now that the session secret for the User has been acquired, we can either retrieve all of the Profiles for that User, or create a new Profile.

Create New Profile

  • UserId (Required)

  • ApplicationId (Required)

  • DisplayName (Required, can be changed later)

  • ImageUrl (Optional, can be changed later)

The CreateProfile request will give you the created Profile object if the request was successful.

Fetch Existing Profiles

If someone has already created a Profile and simply wishes to log back in to that Profile, then you can retrieve all profiles for a User and Application using the GetProfiles via the ProfilesApi. At this point it's up to you to decide whether to let someone choose their Profile (for example, if you have a game that allows for multiple characters) or to choose for them.

Add Profile Id to Session Key

Once the Profile has been acquired, to authenticate any Profile specific requests (e.g. Progress), the Profile Id must be appended to the session key using the following format:

//Session key string, then <space>, then 'p', then the profile id
<session key> p<profile id>

once this is created, overwrite the previous session key stored in the API configurations, for example:

C#
Server.Elements.Client.Configuration.ApiKey["Elements-SessionSecret"] = <New Session Secret>;

and with this, the login process is complete!

Elements supports SSO through Facebook OAuth Tokens. Please review our documentation to implement Facebook SSO.

Elements supports SSO through Apple Sign-In. Please review our to implement Apple SSO.

Creating a new Profile will require a reference to the Application that it's being created for. See for more information on the relationship structure. The CreateProfileRequest object used to create a new Profile contains the following properties:

Please review the documentation to ensure you've provided the proper access levels to new users.

admin console
Service
http://localhost:8080/api
http://localhost:8080/api/localhost/version
Users and Profiles
Sessions > Facebook SSO
Sessions > Apple Sign-in documentation
Sessions > Scoping Rules