Access tokens are JWT's containing [permissions] that consuming clients use to make API requests on behalf of a user. The access token represents the authorization of a specific client and user to access specific resources on applications. Access tokens must be kept confidential in transit and in storage. The only parties that should ever see the access token are the calling client itself, the authorization server (A3S), and resource server/application.
This is the A3S term for referring to a resource server, as commonly referred to within OAuth 2.0 and OpenID Connect contexts. An application is defined as an A3S-protected resource server, which enforces user permissions and data policies, in addition to standard OAuth 2.0 and OpenID Connect JWT components.
These are developer defined groups of related permissions. Note! The applicationFunction entity's only purpose is to make long lists of permissions more human readable within security contract definitions! They are utterly distinct from, and not to be confused with functions
Within the context of A3S and it's documentation, the term client refers to the technical client, as commonly referred to within the OAuth 2.0 and OpenID Connect protocols. OAuth 2.0 provides clients "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. A user is required to use a registered client when obtaining access tokens for accessing resources served by applications.
A child team is team that has been assigned to a another team. Teams can have other teams assigned to them, creating a compound team. A compound team is also referred to as a parent team, as it has one or more child teams assigned to it.
Policies that modify the behaviour of returned data that a particular resource could return. These policies differ from permissions in that they are intended to enable data filtering based on data policy user claims present within the JWT issued for a user, rather than restrict access to resources. They are defined by applications using security contracts.
- Data Policies are assigned to teams.
- Users within a team inherit any data policies assigned to that team.
- Child teams, and their users inherit the data policies of their parent team.
- Parent teams and their users do not inherit data policies assigned to any of their child teams.
A user's effective permission set is defined as the permissions that will be written into JWTs issued for the user. The effective permission set is determined as follows:
- All the roles assigned to the user are obtained.
- All the functions associated with the roles obtained in step 1. are obtained.
- The distinct union of all the permissions that are assigned to the functions obtained in step 2. are the user's effective permissions set.
A Function is a grouping of permissions. Business users assign permissions to functions to create abstractions for business capabilities represented by the collection of those permissions. Note! Functions can only contain permissions originating from a single application. Functions are assigned to roles. Roles are assigned to users.
ID Tokens follow the JWT standard, which means that their basic structure conforms to the typical JWT Structure, and they contain standard JWT user claims asserted about the token itself.
However, beyond what is required for JWT, ID Tokens also contain claims asserted about the authenticated user, which are pre-defined by the OpenID Connect (OIDC) protocol, and are thus known as standard OIDC claims. Some standard OIDC claims include:
- name
- nickname
- picture
- email_verified
Acronym for JSON Web Token. Please refer to the JWT documentation for more details.
A3S supports federating users that are stored within LDAP servers and can authenticate users stored within these stores. An LDAP authentication mode models an LDAP user store, it's access credentials, and possible user claim mapping attributes, enabling A3S to interact with the LDAP server to fulfill these capabilities.
This is an acronym for OpenAPI Specification - V3.
Teams can also have other teams assigned to them, creating a compound team. A compound team is also referred to as a parent team, as it has one or more child teams assigned to it.
Defines a single permission enforced by an application. They are defined and declared by applications using security contracts. Permissions are then assigned to functions by business users.
A fundamental concept in any RESTful API is the resource. A resource is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. It is similar to an object instance in an object-oriented programming language, with the important difference that only a few standard methods are defined for the resource (corresponding to the standard HTTP GET, POST, PUT and DELETE methods), while an object instance typically has many methods.
A Role is grouping of functions. It is comprised of a unique name and a description that gives more information about the role. Roles are assigned to users. Note! Roles can contain functions from multiple applications.
Scope is a mechanism in OAuth 2.0 to limit a client's access to resources. A client can request one or more scopes on login and access tokens issued to the client will be limited to the scopes granted.
OAuth does not define any particular values for scopes, since it is highly dependent on the service's internal architecture and needs.
This is a declarative YAML document that allows idempotent definition of a desired A3S state. Almost all aspects of A3S can be defined using security contracts. Please refer to the security contract documentation for a comprehensive guide to security contracts.
A team is a collection or group of users.
Data policies are assigned to teams, which results in the members of that team inheriting the data policies. Teams can also have other teams assigned to them, creating a compound team. A compound team is also referred to as a parent team, as it has one or more child teams assigned to it. There are conditions for the creation of compound teams, listed below:
- A compound team may not have users directly assigned to it. It's user membership consists of the members of all the child teams assigned to it. Attempting to add users to an existing compound team, or create a compound team from a team that alreay has users assigned, will result in error being returned by A3S.
- A team cannot be assigned to team that is already a child team of another parent team, thus ensuring that compound teams only ever one depth of child teams.
A user models a unique identity for an entity throughout the entire enterprise that is secured by A3S.
A user claim is a statement that a user makes about itself. For example a claim list can have the user’s name, user’s e-mail, user’s age, and user's authorization for an action. A3S issues JWTs that contain permission and dataPolicy user claims, in addition to standard identification and more standard claims. A JWT issued by A3S can be seen as a trusted and verified user claims list.