Page Comparison

...

Success metrics

Assumptions

Milestones

...

Requirements

...

An Authentication Server contains an Identity Realm and provides a UI for interactive logins, an API for service logins , and an API for managing security tokens. An Authentication Server is deployed for each cloud shard and ensures the Personally Identifiable Information (PII) for managed users remain within the shard’s home AWS region. This is important for shards, such as GDPR, that have regulatory requirements for data location and lifecycle. A second type of Authentication Server is designed to integrate with a customer’s Active Directory (AD) or LDAP domain where the PII is stored and managed externally while the tokens are still managed locally.

Cloud Manager

The Cloud Manager provides myriad services related to the operation and management of the OpenMethods cloud including playing key roles in user authentication and permission management. The Cloud Manager contains an Identity Realm that is responsible for handling logins and security tokens for Cloud Team Admin users and shared infrastructure systems. It provides similar APIs for service logins and security tokens as the Authentication Server, but the interactive login is handled by . It also provides the UI for all interactive logins for access to the Cloud Manager Admin Console instead of being an independent UI.

In addition to the identity information for some users, the Cloud Manager is responsible for storing and providing access to extended information for all users regardless of home identity realm. Cloud Manager includes a component that manages the extended user information and exposes a secure REST API for retrieving this information. The REST API requires a valid security token for a user that has the appropriate permissions. Changes to a user’s extended information, including user permissions, can only be made through the Public Console by an authenticated user with appropriate permissions.

...

There are two types of cloud users: Humans and Systems. There are two styles of login: UI and API. Human logins are restricted to the user interface and cannot be used with the Login API. System logins use the Login API and will not work in the user interface. Humans access the login screen using a browser and provide their username (email address) and password to authenticate. Systems use the Login API and provide the username (special value) and password (special value). Once the user’s credentials are validated, a JWT is generated for the user. A Human user is only allowed to maintain a single active token with any existing tokens being immediately revokedtoken. Issuing a new token for a Human user automatically revokes any existing tokens for that user. Human users access the main login screen by visiting Cloud Management Console. This will be available at console[.shard].openmethodscloud.com and is hosted by the Cloud Manager. After the login is successful, a cookie will automatically be set containing the JWT and associated with the shard’s domain.

System logins use the Login API and will not work in the user interface. Systems provide a username (special value) and password (special value). A System user can have any number of active tokens, each with their own lifecycle. There may be some identifiable information related to the specific instance of a system user that can be used to unsure only a single token is active for that instance.

Human users access the main login screen by visiting their home shard’s authentication server. This will be available at login[.shard].openmethodscloud.com. If the user attempts to visit the public console directly, the public console will redirect the user to the authentication server login page. After the login is successful, a cookie will automatically be set containing the JWT and associated with the shard’s domain.

Roles

...

Roles

A role is a predefined set of permissions that can be applied to a user. A role typically groups permissions based on the type of activities being enabled. There are 4 standard role types: VIEW, MANAGE, ADMIN, and SUPER. The role types generally inherit the capabilities of lower role types. For example, the MANAGE role type includes all the permissions associated with the VIEW role type. It would be hard to MANAGE something if you can’t VIEW it to begin with. A role also has a scope that determines which objects are applicable to a role’s permissions. There are 3 role scopes: DEPLOYMENT, CUSTOMER, SYSTEM. DEPLOYMENT scoped roles hold permissions tied to a specific customer deployment. CUSTOMER scoped roles hold permissions related to a customer and any of their deployments. SYSTEM scoped roles hold permissions related to overall system operation, customer activities, and customer deployments.

A user can have any number of roles assigned. A user must be associated with a customer before a customer or deployment scoped role can be assigned. Similarly a user must be associated with the system level object before a system level role can be assigned.

Each customer will have 3 roles automatically created. These default roles will reflect the VIEW, MANAGE, and ADMIN role types and will contain all permissions for those types and are scoped for that customer and all deployments owned by that customer. Assigning the customer VIEW role will allow a user to view all customer information and all information for every deployment. Each deployment will also have 3 roles automatically created that reflect the VIEW, MANAGE, and ADMIN role types. These roles are specific to the deployment.

Permissions

A permission represents the ability to perform some action within the system. Similar to roles, permissions follow the standard types of VIEW, MANAGE, ADMIN, AND SUPER. Permissions also are targeted for a specific scope of DEPLOYMENT, CUSTOMER, or SYSTEM. A permission can be assigned to either a role or to a user directly.

Extended User Information

...

There is a separation between authenticating a user and retrieving the properties associated with a user, including a user’s permissions. The user’s token DOES NOT include the user’s extended information. This information must be retrieved in a separate request to the cloud manager. This request uses the token of the system or human user making the request and provides the token id of the user whose information is being requested. The Cloud Manager first determines if the requester token is authentic and valid. If the requester token is authentic and valid, the Cloud Manager then determines if the requester has the RETRIEVE_EXTENDED_INFORMATION permission. If the requester is authentic, valid, and has the correct permissions, the Cloud Manager determines if the query token is authentic and valid. If the query token is authentic and valid, the query user’s extended information is returned to the requesterreturns the extended information.

Token Renewal

When a token is issued for a user, the time it remains valid is limited. After time expires, the token is no longer valid and the user must log in again. API requests using an expired token will fail. The token expiration can be extended through renewal. This involves making a request to the Login API and providing the original token as well as the security stamp returned during the initial login. The renewal can occur any time prior to expiry. An updated token will be issued to the requester. A token owner should leave plenty of time prior to expiry to attempt to renew the token in case of network delays or temporary outages. Typically the token owner should begin the renewal process with at least a quarter of the time remaining.

Token Leasing

For APIs that receive multiple requests from the same client in quick succession, the process of validating the client’s token can get very expensive and would produce significant traffic directed at the authentication service. To avoid this situation, a service can choose to lease a token’s validation result. Part of the user’s extended information is values related to token leasing. These values represent the length of time a previous validation can be used to service the request without having to revalidate the token.

...