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

...