91 lines
6.9 KiB
Text
91 lines
6.9 KiB
Text
|
|
=== Core concepts and terms
|
|
|
|
Consider these core concepts and terms before attempting to use {project_name} to secure your web applications and REST services.
|
|
|
|
users::
|
|
Users are entities that are able to log into your system. They can have attributes associated with themselves like email,
|
|
username, address, phone number, and birthday. They can be assigned group membership and have specific roles assigned to them.
|
|
authentication::
|
|
The process of identifying and validating a user.
|
|
authorization::
|
|
The process of granting access to a user.
|
|
credentials::
|
|
Credentials are pieces of data that {project_name} uses to verify the identity of a user. Some examples are passwords,
|
|
one-time-passwords, digital certificates, or even fingerprints.
|
|
roles::
|
|
Roles identify a type or category of user. `Admin`, `user`, `manager`, and `employee` are all typical roles that may exist
|
|
in an organization. Applications often assign access and permissions to specific roles rather than individual users as dealing
|
|
with users can be too fine-grained and hard to manage.
|
|
user role mapping::
|
|
A user role mapping defines a mapping between a role and a user. A user can be associated with zero or more roles. This
|
|
role mapping information can be encapsulated into tokens and assertions so that applications can decide access permissions on
|
|
various resources they manage.
|
|
composite roles::
|
|
A composite role is a role that can be associated with other roles. For example a `superuser` composite role could be associated with the
|
|
`sales-admin` and `order-entry-admin` roles. If a user is mapped to the `superuser` role they also inherit the `sales-admin` and `order-entry-admin` roles.
|
|
groups::
|
|
Groups manage groups of users. Attributes can be defined for a group. You can map roles to a group as well. Users that become members of a group
|
|
inherit the attributes and role mappings that group defines.
|
|
realms::
|
|
A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another
|
|
and can only manage and authenticate the users that they control.
|
|
clients::
|
|
Clients are entities that can request {project_name} to authenticate a user. Most often, clients are applications and services that
|
|
want to use {project_name} to secure themselves and provide a single sign-on solution. Clients can also be entities that just want to request
|
|
identity information or an access token so that they can securely invoke other services on the network that are secured by {project_name}.
|
|
client adapters::
|
|
Client adapters are plugins that you install into your application environment to be able to communicate and be secured by {project_name}. {project_name}
|
|
has a number of adapters for different platforms that you can download. There are also third-party adapters you can get for environments that we don't cover.
|
|
consent::
|
|
Consent is when you as an admin want a user to give permission to a client before that client can participate in the authentication process.
|
|
After a user provides their credentials, {project_name} will pop up a screen identifying the client requesting a login and what identity
|
|
information is requested of the user. User can decide whether or not to grant the request.
|
|
client scopes::
|
|
When a client is registered, you must define protocol mappers and role scope mappings for that client. It is often useful to store
|
|
a client scope, to make creating new clients easier by sharing some common settings. This is also useful for requesting some
|
|
claims or roles to be conditionally based on the value of `scope` parameter. {project_name} provides the concept of a client scope for this.
|
|
client role::
|
|
Clients can define roles that are specific to them. This is basically a role namespace dedicated to the client.
|
|
identity token::
|
|
A token that provides identity information about the user. Part of the OpenID Connect specification.
|
|
access token::
|
|
A token that can be provided as part of an HTTP request that grants access to the service being invoked on. This is part of
|
|
the OpenID Connect and OAuth 2.0 specification.
|
|
assertion::
|
|
Information about a user. This usually pertains to an XML blob that is included in a SAML authentication response that
|
|
provided identity metadata about an authenticated user.
|
|
service account::
|
|
Each client has a built-in service account which allows it to obtain an access token.
|
|
direct grant::
|
|
A way for a client to obtain an access token on behalf of a user via a REST invocation.
|
|
protocol mappers::
|
|
For each client you can tailor what claims and assertions are stored in the OIDC token or SAML assertion. You do this per client by creating and configuring
|
|
protocol mappers.
|
|
session::
|
|
When a user logs in, a session is created to manage the login session. A session contains information like when the user logged in and what
|
|
applications have participated within single-sign on during that session. Both admins and users can view session information.
|
|
user federation provider::
|
|
{project_name} can store and manage users. Often, companies already have LDAP or Active Directory services that store user and credential
|
|
information. You can point {project_name} to validate credentials from those external stores and pull in identity information.
|
|
identity provider::
|
|
An identity provider (IDP) is a service that can authenticate a user. {project_name} is an IDP.
|
|
identity provider federation::
|
|
{project_name} can be configured to delegate authentication to one or more IDPs. Social login via
|
|
Facebook or Google is an example of identity provider federation. You can also hook {project_name} to delegate
|
|
authentication to any other OpenID Connect or SAML 2.0 IDP.
|
|
identity provider mappers::
|
|
When doing IDP federation you can map incoming tokens and assertions to user and session attributes. This helps you propagate identity information from the external IDP
|
|
to your client requesting authentication.
|
|
required actions::
|
|
Required actions are actions a user must perform during the authentication process. A user will not be able to complete the authentication process until these actions
|
|
are complete. For example, an admin may schedule users to reset their passwords every month. An `update password` required action would be set for all these
|
|
users.
|
|
authentication flows::
|
|
Authentication flows are work flows a user must perform when interacting with certain aspects of the system. A login flow can define
|
|
what credential types are required. A registration flow defines what profile information a user must enter and whether something like reCAPTCHA
|
|
must be used to filter out bots. Credential reset flow defines what actions a user must do before they can reset their password.
|
|
events::
|
|
Events are audit streams that admins can view and hook into.
|
|
themes::
|
|
Every screen provided by {project_name} is backed by a theme. Themes define HTML templates and stylesheets which you can override as needed.
|