An entity for which identity information is stored and managed by a system.
Jane Smith is an employee of BigCorp.
The representation of a principal in a system.
A user may be represented in a system by storing their attributes in a database such as first name, last name, email address, etc. E.g. BigCorp's database stores Jane Smith's name, email, employee Id, etc.
The process of establishing that identity information associated with a particular entity is correct.
HR has verified the evidence that proves the user in the HR database with the name Jane Smith and personal email address of j***@gm**l.com is a person born on MM/DD/YYYY, with a social security number of XXX-XX-XXXX, having a California Driver's License number: XXXXXX and a physical address of 123 Main St. Somewhere, CA USA.
The act of securely associating a principal's identity to an app, a browser or a device upon request by the principal. The user agents could include APIs that are used by one system to communicate with another.
The user jsmith@bigcorp.com is now associated with the web browser session as identified by a cookie.
In order to prevent impersonation of one principal by another, this requires the principal to prove their identity using a combination of mechanisms such as passwords, SMS-based verification, biometric proofs, security keys containing one-time-passwords or cryptographic private keys.
User jsmith@mycompany.com is authenticated using a password and a Yubikey hardware security token.
A central storage of identities in an organization. This is typically organized as a hierarchy, where each identity is uniquely identified by a path from the root of the hierarchy to the specific identity.
Jane Smith's directory entry in BigCorp's “Active Directory” is identified by “CN=JSmith,OU=Support,OU=Users,DC=BigCorp,DC=com”
This would generally mean that Jane Smith has an entry in the directory as a user in the support organization of BigCorp.
A hierarchical unit of directory organization. Principals (e.g. users or computers) belong in exactly one OU, but OUs may be nested within other OUs. An OU may be used as a principal in many situations such as applying policies.
As seen in the previous example, BigCorp's support employees are all stored in the OU named “support”. The “support” OU is stored in the OU named “Users”.
Users in a directory that may or may not belong in the same OU are grouped together in a “free form” group. In the context of authorization, a group is referred to as a role. A group may be used as a principal in many situations such as applying policies.
Jane Smith is a member of the group “Tiger Team”, along with select members of engineering, product management and the leadership team.
The privilege granted to a principal to access specific resources in specific ways.
Jane Smith has authorization to update a discount percentage in an invoice record of the customer SuperCo. In Role-based access control (see below), the authorization could be something like: Tiger team has authorization to update customer billing information.
A mechanism, typically based on open, standards-based protocols, in which an independent provider (the identity provider) can authenticate a user in order for them to be authenticated at another system (the service provider or relying party). Also known as federated authentication
BigCorp uses SAML (popular federated identity protocol) to login employees such as Jane to their 401(k) provider using their employee authentication.
Or Jane uses an expenses app on their mobile phone to authenticate themselves using OpenID Connect (another popular federated identity protocol) to authenticate as a BigCorp employee and enter their expenses.
The authenticating service or software in a federated identity system.
Okta, Microsoft Azure AD, Sign-in with Google.
In the context of federated identity, this is the system that consumes the authentication token from the identity provider so that the principal may be authenticated without separately authenticating them at the service provider. A service provider is also known as a Relying Party.
Cloud SaaS platforms such as Salesforce, ServiceNow, Workday can be configured to rely on identity providers for user authentication.
Security Assertion Markup Language. A federated identity protocol that is popular with enterprise services. It is used mainly for single sign-on between independent web-based services, such as SaaS providers. It also has the capability to provision new accounts at the service provider and to logout the user from multiple websites where they are signed in using SAML. However, the provisioning and single logout features are not commonly used.
SAML Identity providers include Microsoft Azure AD, Okta and Google
SAML service providers include Salesforce, ServiceNow and Workday.
A federated identity protocol that leverages the Open Authorization 2.0 protocol (OAuth 2.0) to implement single sign-on and optionally, authorization. It is more often used where the interaction is client application based rather than web-based, but many websites also use OIDC as a federated identity sign-in mechanism.
OIDC Identity providers include: Microsoft Azure AD, Okta, and Google
OIDC relying parties include: Gmail mobile app, Uber mobile app, Dropbox and Expedia.
The result of a federated authentication protocol exchange, which conveys the identity of a user from an identity provider to a relying party (AKA service provider.)
A SAML token is also known as a SAML Assertion. An OIDC token is also known as an ID token.
An action taken by an authenticated principal to interact with objects in a system. Objects with respect to access could be data, applications, computing resources (virtual machines, storage buckets, etc...) or physical resources, e.g. rooms, buildings, etc...
Interactions are dependent on the type of object. E.g. a principal may create, read, modify or delete data. They may start or stop virtual machines, etc.
A cryptographically un-spoofable data item that represents specific access granted to the possessor of the token.
Sometimes, such a token is just a long, unguessable number. Sometimes it is a digitally signed JSON web token.
An open standard protocol of communication between independent systems that results in an access token being received by the requesting system, which enables them specific access capabilities on behalf of a principal.
The protocol defines scope codes (called just “scopes” in the protocol) understood by the “resource server” (i.e. the system of which the access is requested) that are used limit what the requester has access to
The protocol also defines an optional mechanism for a user principal to provide consent to the specific scopes being requested.
Consumer example: A ride-sharing mobile application uses OAuth to obtain a user's profile picture from Facebook. Facebook requires consent from the user in order to release this information
Enterprise example: An API client from a security company may use OAuth to access an API provided by a smart-devices manufacturer to assign a specific device to a customer user of that company.
The authorization server (AS) in an OAuth protocol issues access tokens after authenticating and authorizing the request.
A service or server that accepts an OAuth token, verifies the scopes and grants access to the possessor of the access token to resources within its service.
Google Drive service
A system to manage authorization that enable an organization to specify which principals have access to which objects.
A software component that makes an authorization decision based on policy
A software component that provides information required by the PDP to make an authorization decision
A software component that enforces an authorization decision made by a PDP
A software component that enables users to define and manages policies
An authorization system wherein access control rules are different for smaller collections of objects rather than broad categories.
An authorization system wherein the principals that are either allowed or denied access to a specific object or collection of objects are specified in a list. If the members of the list are allowed access, then the list is called an “allow list” (formerly known as a “whitelist”). If the members of the list are denied access, then the list is called the “deny list” (formerly known as a “blacklist”). The access may be a specific type of access (e.g. create or delete), or a generic access, which could mean any operation on the target object.
“Deshaun@company.com, Mary@company.com and Arun@contractor.com” can update firewall rules.
A system to manage shared credentials to highly sensitive resources. Users are often required to use secure two-factor authentication to login to the PAM system. The PAM system then uses the shared credential to enable the user to access the critical resource, such as a production server.
An authorization system wherein each principal is assigned a role, and access control lists include such roles rather than the principals directly within them.
Managers have access to historical employee performance report files.
An authorization system wherein the decision to grant access to a principal to a specific object is determined at run-time, based on factors that may change more rapidly than the content of an access control list.
Environmental properties that affect a user's access to an organization's resources.
This may include the user's authentication mechanism (e.g. password or two-factor), IP address, time of the day, whether the device they are accessing from is secure or not.
A dynamic authorization system wherein policy rules can be specified regarding access to objects or collections of objects. The rules can include roles, but also more dynamic attributes such as the access posture. In some cases, principals and objects / collections are assigned text attributes, and policies can also include such text attributes in determining whether the user has access to a specific object or not.
Example policy: A user accessing from a private location (as indicated by their IP address) may access files that have the attribute “PII” (personally identifiable information) if the user's role is in the access control list of the file being accessed.
A dynamic authorization system wherein policy rules may include attributes as in ABAC, and specific computations that can determine a business justification for a user to have access to a certain object.
Example policy: A user with the right access posture and role may access a customer's data if they are assigned an open case which includes the customer as an affected entity and the user's jurisdiction is the same as the customer's jurisdiction.
The OpenID standard defines an ID token with specific fields in it.
In the OAuth protocol, an access token may be renewed by presenting the refresh token to the authorization server.