We will use some terminology throughout these docs that may be worth reviewing.

UE Auth Terms

• AuthGroup - An AuthGroup is a pool of uniquely identified users. AuthGroups can be private, requiring admins to add users, or public, allowing users to simply self-register. It is also possible to make the AuthGroup public but add further restrictions at an Organization, Domain or Product level. AuthGroups allow configuration of the OIDC Identity Provider settings solution which users rely upon for login. The term AuthGroup, Platform, and your tenant may all be used depending on context to reference your instance of Core EOS, UE Auth, or UE Streams.
• Accounts - Accounts in UE Auth consist of an email, username, password, and id. Information such as Name, Address, visible contact numbers, or other personal data is not persisted here by design. This means that you cannot simply get the user's information by requesting the scope "profile". We do this to protect the user's data above all else. A secured Profile system exists to manage that information for an Account should the user wish.
• Secured Profile - A Secured Profile is personal information about an account holder such as name, email addresses, phone numbers, biographical data, or images, which the Account holder may optionally choose to populate. No one other than the Account holder and an AuthGroup administrator can access this data directly. Organizations or other entities may request access to the data which an Account holder can agree to supply or deny. You can manage your own Secure Profile by clicking "Account" in the upper right of the UE Auth portal.
• User Management - You have the ability to define and administrate Accounts (users) globally across the AuthGroup or within the context of an Organization. This feature is what allows both self-managed B2C accounts and B2B enterprise account management to coexist. You can access manage Users in UE Auth by accessing the portal and selecting "Users" on the left navigation.
• Organization Management - You have the ability to define collections of accounts within an AuthGroup that have common access to things like customers or departments. For example: If Sage Industries has an AuthGroup representing a pool of unique users, they may also have a B2B customer called Acme Rockets Inc. which some of their users would need to access. Acme Rockets Inc. is an Organization within the Sage Industries AuthGroup. You can manage your Organizations by clicking "Organizations" on the left nav of the UE Auth portal.
• Organization User Profiles - Even though Accounts themselves do not have profile information beyond an email address, an Organization may need to manage additional descriptive profile information for users they associate to that Org. Organizations may need to define information about their users such as first and last name, address, or other data over which they wish to have a measure of control. This data is limited in scope to the Organization itself and access is limited to Organization administrators or the Account holder. As such, Organization User Profiles are unique only to the Organization but reference a single unique Account in the AuthGroup. One Account could have as many Organization User Profiles as there are Organizations to which the Account has been given access. In contrast, Secured Profiles are entirely controlled by the Account holder (user) and not accessible by anyone other than that user. Secured Profile data can be requested but must always be actively approved and provided or denied by the User. It is possible to seed an Organization User Profile using a Secure Profile with the Account holder's approval. You can manage Organization User Profiles by clicking "Users" on the left nav of the UE Auth portal and then selecting a specific Organization form the available list on the User window left navigation. Once selected, if you then select an email address in the middle column, you will see input fields for personal data.
• Domain Management - Domains are further subsets of Organizations which create finer access control. For example: Lets say Sage Industries sells Enterprise Resource Management (ERM) software to Acme Rockets Inc. Sage Industries has a large global pool of users, this is their AuthGroup, and some of those users need access to Acme Rockets Inc. which is represented as an Organization within Sage Industries. Acme Rockets has multiple departments that use the new ERM software and each needs different access to that software. Each department could be represented as a Domain with in the Acme Rockets Organization. You can manage Domains within the context of an Organization by clicking "Organization" on the UE Auth portal left nav.
• Product Management - You have the ability to define and manage Products to which your users, organizations, or domains will need access and permissions within UE Auth. Products could be public with self-service access or private requiring admin provided access. To manage them, click "Products" on the UE Auth portal left nav.
• Role Management - Roles are groupings of permissions which can be applied to Accounts (users) within the context of an Organization, Domain, and Product. Roles can also be applied to Services (oAuth Clients) within the context of a Product. To manage them, click "Roles" on the UE Auth portal left nav.
• Permission Management - Permissions are a data record indicating a coupling of a TARGET, an allowed ACTION, and an OWNERSHIP requirement conditional, within the context of a Product. The UE Auth Permissions service does not enforce permissions for external products that have been mapped, it defines them. When requesting a token, all permissions can be requested to be part of that token through the "access" scope. TO ONLY return permissions and none of the other access properties such as Products or Organizations, you may request the "access:permissions" scope instead. You can define and manage them in UE Auth by clicking "Permissions" in the left nav of the portal.
• Product Access - Product Access is the notion that access to a specific Product can be defined for Accounts, Organizations and Domains so that when a user's access privileges are queried, it is clear if they should or should not be able to interact with a given Product. Product Access further provides context as to which Roles and Permissions that a user may have are applicable at any given time. In UE Auth, Product Access is a function of Product association to Organizations and Domains, where Domains can not be associated to a Product that was not first associated to the parent Organization. Users are provided access by being associated to a Domain, and through this association, inherit access to any Products associated to that Domain. You can give a user access to a Domain within the context of an Organization by clicking "User" on the UE Auth left nav, highlighting the Organization you wish, highlighting the Account email address, and then scrolling to the right most panel of the window and selecting the Domains desired.
• Services (oAuth Clients) - In UE Auth, when working with an oAuth Client that has been associated to a Product, we refer to it as a Service. These Services can be configured as any oAuth Client would be but have some additional parameters to specify their function. For example, you can specify that this a Service functions to provide user login to the product. To be clear, UE Auth is an oAuth 2.0 and OpenID Connect Identity Provider. When you see oAuth Client anywhere in these documents, this is just a short hand and should not be confused with the oAuth specification vs oAuth 2.0.
• Seamless Federation - UE Auth allows you to configure a Login Service to completely bypass the normal login screen where a user my select a social login or SSO button and immediately direct the user to an external federated login experience. The Identity Provider of that login experience can then be configured to redirect back to UE Auth, allowing the final token to be provisioned from UE Auth instead of the federated IdP. To the user, it appears as though they have signed on using the federated IdP only, but behind the scenes UE Auth is managing access and your solution can now leverage UE Auth capabilities. We call this Seamless Federation, and it is a useful tool for migrating from or augmenting an existing Auth investment.

UE Streams Terms

• NATS JetStream - We built our data streaming solution on top of NATS.io JetStream and our integration is fully compatible with their clients and APIs. If you can connect to NATS, with just a few additional parameters you can connect to UE Streams.
• Subject - A subject is like a simple pipe of data. On its own, it has no persistence. If someone pushes data into this pipe and you are there on the other listening, you will receive the data. Otherwise, you will never receive that particular data event. This is called "at-most-once" delivery. Subjects can be configured to allow data to be partitioned through wildcards (tokens). You can create and manage Subjects in UE Streams by accessing the portal and clicking "Simple Streams" on the left navigation under Data. In the newly opened window, you'll see that the Streams view is defaulted. At the top you can click "Subjects" to change the view.
• Subject Tokens - Subject naming is setup as a series of tokens delimited by a period. For example, "this.is.a.subject" is a Subject name that has 4 tokens. Subject names can also include two wildcard tokens, "*" and ">". As an example, "this.subject.*" and "this.subject.>" are both valid names. The asterix character denotes a single token wildcard. So for "this.subject.*", "this.subject.one" and "this.subject.two" are valid, but "this.subject.more.than.one" is not. The greater than character denotes as many additional tokens as there may be after the last non-wildcard token. In this example, all of the previous subject names including the last one would be valid. Wildcard tokens allow for permutations of data within a Subject or Stream so that Subscribers, Consumers, and Publishers can manage different kinds of data in the same stream.
• Stream - A Stream wraps one or more Subjects to provide data persistence so that Consumers can catch up on all data within that stream after it has been published without having to be actively listening at the time of publish. This is called "at-least-once" delivery. Most enterprise integrations will use Streams. You can create and manage Streams in UE Streams by accessing the portal and clicking "Simple Streams" on the left navigation under Data. In the newly opened window, you'll see that the Streams view is defaulted.
• Access Object - UE Streams lets you define access objects which allow you to connect clients to a data stream from anywhere that there exists an internet connection that allows access to our API. Access Objects define the specific permissions your desired integration should have such as publish, subscribe, and queue group. Access Objects also include a Client ID and Client Secret so that you can securely and continuously update your Access JWT as it expires. To manage all existing Access Objects, click "Access Management" on the left nav of the portal under "Data".
• Consumers - Streams require Consumers to access data. Consumers themselves require specific permissions to create, update, or manage outside of the UE Streams ecosystem. To enable developers to manage some integrations outside of UE Streams, a configurable number of Reserved Consumers are generated with an Access Object and incorporated into the Access Object permissions. If additional Consumers are required after an Access Object has been created, they can be managed centrally within UE Streams. To access Consumers, click "Access Management" on the left nav of the portal under "Data". Select an Access Object that is associated to a Stream (not Subject). On the right panel, you will see a button for Consumers specific to this Access Object.
• Native Connector or Client - Currently integration with UE Streams is primarily through a native connection using an open source NATS.io client. This connection is compatible with many technology stacks. A full list can be found here for all NATS clients which would work with Subjects and specific JetStream clients which would work with Streams.