ULM Cloud Glossary
Content
Overview
This topic itemizes and defines common concepts, terms, and functions in the User Lifecycle Management (ULM) domain.
General Terms and Items
| Term | Definition |
|---|---|
| Action Token | A unique one-time use token that triggers a one-time action (i.e., invokes a ULM Process) when it is redeemed by the GET /session/token API. Tokens are context-aware so that, upon token redemption, ULM knows what task (Process) needs to be performed, and what user is redeeming the token. Tokens are delivered to user's external contact channels (i.e., in an email or SMS) as either: - A longform redirect URL back to the client's browser with the token value appended to the URL - A shortform custom One Time Passcode (OTP) that represents the actual token, and that the user supplies to the UI - Both a URL and OTP Shortform token length and type, as well as longform token URLs, are configured in the MarketONE ULM Admin web application. The type of token that a user receives depends on the notification settings as defined in the onboarding and integration between a business and ULM Cloud. See ULM Action Tokens for more details. |
| Activation | A ULM entity or attribute has its status updated from activating or pending to activated. The Activate User and User Attribute Process handles this task in ULM Cloud. In more common terms, a user verifies their registered email address or mobile number and, as a result, their email/mobile – which is registered as an attribute on the ULM User entity – is activated in the ULM Cloud server. |
| Alias |
An optional type of authN ID that is not verifiable. Email addresses and mobile numbers are authN ID types that require verification wherein a verification message sent to those channels (e.g., with an action token). Conversely, aliases cannot be verified, so they are activated immediately upon creation. A user can use an alias (and password) for authentication instead of their email/mobile.
Commonly referred to as a "nickname" or "handle." |
| Application Settings |
Also known as "app settings" or simply "settings." These are configuration points for various aspects of ULM Cloud, including ULM Process behaviour.
A business customer can modify their settings by signing into the ULM Admin web application and navigating to the Settings menu. User documentation for this menu will be added to the MarketONE User Admin UI User Guide in a forthcoming release. |
| Authentication |
A human proves their identity in order to access a digital service. The user proves who they are through one of two primary paths:
- Standard User Authentication: user supplies an authN ID and password to the Authenticate User Process. - Social Authentication: the client invokes the Authenticate with Social Account Process and then redirects to a third-party social account provider wherein the user authenticates with that provider. The provider then redirects the user back to the client, and sends along an authentication token to ULM Cloud. |
| AuthN ID |
Short for Authentication Identifier. Commonly referred to as a "username," an authN ID is a user's registered email address, mobile number, or alias. Every ULM User ID requires at least one verified (i.e., activated) authN ID. An activated, authenticated user can update or add multiple authN ID(s), if the client wishes to allow it.
When a user registers an authN ID, that authID is stored on the ULM User entity as an attribute. If the user has more than one registered authN ID, they can use the Remove User Attribute Process to remove authN IDs from their User ID (i.e., from the User entity). |
| CRUD | Create/Retrieve/Update/Delete refers to operations that are performed in persistent data storage. The majority of ULM REST APIs perform CRUD operations against ULM Cloud data, with operations signified by HTTP request methods (POST/GET/PUT/DELETE). |
| JSON | JavaScript Object Notation. An open standard file format, and data interchange format, that uses human-readable text to store and transmit data objects consisting of simple data fields (name and value pairs), complex objects, and array data types and array (or any other serializable value). ULM API and Processes consume and deliver resources using JSON. |
| OIDC |
Open ID Connect (OIDC) is an authentication layer which sits on top of the OAuth authorization framework. Where OAuth 2.0 allows a user to grant a third-party access to protected resources, OIDC extends that to allow the IdP (in this case ULM) to directly provide/request third-party information about the user.
There are two ways in which ULM Cloud supports OIDC: -1. An OIDC client federates authentication to ULM: ULM Users can onboard and authenticate into ULM Cloud using a supported social account. - 2. ULM federates authentication to an OIDC relying party: Administrators can use the ULM Admin web application to set up OIDC replying parties (RPs) for single-sign on. Once an OIDC RP is set up, users can authenticate with ULM Cloud and navigate to the RP client(s) and access services without the need to re-authenticating with those clients. |
| Process |
A ULM Process is a distinct service, executed on the ULM Cloud backend, comprised of multiple, predictable REST API calls in sequence between a client application and ULM Cloud. Each Process is comprised of a number of "Process steps" wherein: - 1. The client initiates a Process in ULM Cloud using an API request. - 2. The Process responds to the client with a request for data (if required). - 3. The client supplies the requested data back to ULM Cloud with another API request, in the format specified in the previous Process response. - 4. Steps 2 and 3 repeat until the desired task is accomplished and the Process ends. In contrast to, for example, a standard independent or "single-shot" API call, Processes invoke a number of separate calls and perform different decisions based on a variety of factors, including: - Hardcoded Process-specific logic. - Configurable system application settings (configured in the MarketONE ULM Admin web application). - User input from the user on the frontend UI, passed back to ULM Cloud in a Process request. Processes are executed by a Process-specific subset of the ULM API library. See the ULM Process Guide for Developers for more information. |
| REST |
Representational State Transfer (REST) is an architectural style built on HTTP standards, and designed around clean, lightweight exchange of data between client and server. RESTful APIs do not return any sort of markup or styling (HTML or CSS). Instead, they return simple, serialized data that a client application consumes, parses, retains, and displays in whatever manner that it requires.
ULM Cloud provides a library of ULM REST APIs for user lifecycle management capabilities. These APIs perform standard CRUD operations against ULM data entities. This library also includes a subset of Process-specific APIs that are used to execute ULM Processes for more complex, user-driven operations. |
| Status |
All ULM data entities have a status property that defines whether or not the entity is active and accessible.
For example, when a user onboards into ULM for the first time, the Onboard User with Email & Mobile Process creates a new ULM User ID (known as a ULM User entity on the backend) with an activating status. The email or mobile they used to sign-up is registered as an authN ID and stored as an attribute on the ULM User entity, and it also has an activating status. By default, the user cannot authenticate into a service until they verify their registered authN ID, which in turn also fully activates the ULM User ID. |
| User | The human agent who interacts with ULM Cloud via a client application. The following clarifications apply:
- End-users onboard with ULM Cloud in order to acquire a ULM User ID or "User Profile" - The User ID / Profile is stored in ULM Cloud as a ULM User entity. - Like all ULM entities, the User entity is composed of properties and attributes (i.e., JSON data fields) Note: For clarity, documentation typically refers to the human user with the lowercase "u." Conversely, documentation refers to the User ID or ULM User entity with an uppercase. |
| User ID | The unique passport that a user owns and uses in order to access services offered by a client. The User ID may be commonly called a "User Profile" depending on how the client displays it. |
| Verification | Verification In the context of ULM authN IDs, verification is synonymous with activation. When a user registers an external contact channel (email address or mobile number), that email/mobile is stored as an authN ID and ULM User attribute. The user must then need to verify that they own that channel. ULM sends a verification message to the channel with a ULM action token that the user must then redeem. Redeeming the token invokes the Activate User and User Attribute Process, and this activates the authN ID (i.e., the attribute status is updated from activating to activated). |
ULM Data Entities
The ULM Cloud Data model is composed of a set of primary entities that represent the end-user and the relevant items in their universe. Each entity is defined by a set of properties (i.e., global data fields that are present on all entities) and attributes (i.e., entity-specific data fields).
| Term | Definition |
|---|---|
| Attributes | A JSON map of lower-level, entity-specific properties that define the ULM entity. The attributes property supports a variety of data types, including simple strings, booleans, objects, arrays, objects of arrays, arrays of objects, and so on. |
| Properties | The default data fields (i.e., name: value pairings) that populate a given ULM data entity type. Some properties are "global" in that they appear on every primary ULM entity type (e.g., createdDate, id, displayName, status, and attributes). Certain properties are not global, however, such as the properties on the ULM Runtime entity. |
| ULM Account | ULM Data entity that represents the account relationship between a user and a service provider. Conditions apply: - A user associates their external account to their ULM User ID with the Associate Billing Account Process. - The Process calls the external Billing / Operations Support System (B/OSS) to retrieve external account data. - The Process then provisions the ULM Account using the external account data, and associates it to the ULM User. - The ULM Account is also associated to a ULM Group of which the ULM User is a Primary User - A service provider must integrate their B/OSS with ULM Cloud in order to support account association. - Depending on the integration and data mapping, the ULM Account entity will also include/contain one or more ULM Subscriptions (and each Subscription may include/contain one or more ULM Features). |
| ULM Associations |
Connective sub-entities that essentially link individual primary ULM entities together. Associations are defined by permission flags and, in some cases, attributes.
Possible associations include: - ULM User to any other entity type - ULM Group to any other entity type - ULM Account to User, Group, and Runtime - ULM Subscription to User, Group, and Runtime - ULM Feature to to User, Group, and Runtime - ULM Runtime to User, and Group For example, if a ULM User entity is associated to a ULM Subscription, then this typically means that the end-user, once authenticated, is entitled to access that service. Associations between two of the same entity type (e.g., User-to-User) do not exist in ULM. |
| ULM Subscription |
ULM Data entity that represents an instance of a service, usually for a fee. Conditions apply:
- A ULM Subscription cannot exist independent of a ULM Account. In other words, in the ULM data store, a Subscription will always be contained in a Account. |
| ULM Feature |
ULM data entity that represents a specific functionality of a subscription-based service. Conditions apply:
- A ULM Feature cannot exist independent of a ULM Subscription. In other words, in the ULM data store, a Feature will always be contained in a Subscription. |
| ULM Group |
ULM data entity that typically represents a single "household," or otherwise group of ULM Users.
On the backend, Groups are used to facilitate Billing Account Association. When a user associates their bulling acocunt, the ULM Account equivalent is associated to both the ULM User and a ULM Group (of which the same User is a Primary). To share the Account (or any Subscriptions or Features within the Account), ULM Cloud associates other ULM Users to the same Group as well as the specific subscription or feature. This one-to-one and one-to-many association is how ULM Cloud extends service sharing capabilities for service providers who do not already have these capabilities. For more details on how ULM Groups support account and service sharing, see the Associate Billing Account to User ID Process for more information. |
| ULM Runtime |
ULM data entity that represents the client device from which an end-user authenticates into ULM. Examples include a web browser, or a set-top-device.
See Tracking User Runtimes for more information on how ULM Runtimes are created and leveraged. |
| ULM User |
The central entity in the ULM User Lifecycle Management data model. It represents an individual person.
Note: User with an uppercase U refers to the ULM User entity (or User ID), whereas user with a lowercase u refers to the end-user or human being. |
Note: See the ULM Data Model section for more information on ULM entities, associations, properties, and attributes.