Merge pull request #136 from ndeevy/ndeevy-single-sign-on

Added glossary for Single Sign-On

supplementary_style_guide/glossary_terms_conventions/product_conventions/red-hat-single-sign-on.adoc

@@ -0,0 +1,299 @@
+[[red-hat-single-sign-on-conventions]]
+
+[discrete]
+[[access-token]]
+==== image:images/yes.png[yes] access token
+*Description*: An access token is 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.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[assertion]]
+==== image:images/yes.png[yes] assertion
+*Description*: An assertion provides 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.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+
+[discrete]
+[[authentication]]
+==== image:images/yes.png[yes] authentication
+*Description*: Authentication is the process of identifying and validating a user.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[authentication-flow]]
+==== image:images/yes.png[yes] authentication flow
+*Description*: An authentication flow is a workflow that 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 take before they can reset their password.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[client-adapter]]
+==== image:images/yes.png[yes] client adapter
+*Description*: Client adapters are libraries that make it easy to secure applications and services with Red Hat Single Sign-On. Red Hat Single Sign-On has a number of adapters for different platforms that you can download. There are also third-party adapters you can use for environments that Red Hat does not cover.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+
+[discrete]
+[[client-role]]
+==== image:images/yes.png[yes] client role
+*Description*: A client role is a role namespace that is dedicated to a client. Each client can define roles that are specific to it.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[client-scope]]
+==== image:images/yes.png[yes] client scope
+*Description*: When a client is registered, you must define protocol mappers and role scope mappings for that client. To simplify the task of creating clients, you might decide to store a client scope so that you can share some common settings. This is also useful for requesting some claims or roles to be conditionally based on the value of `scope` parameter. Red Hat Single Sign-On provides the concept of a client scope for this.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[client]]
+==== image:images/yes.png[yes] client
+*Description*: A client is an entity that can request Red Hat Single Sign-On to authenticate a user. Most often, clients are applications and services that want to use Red Hat Single Sign-On to secure themselves and provide a single sign-on solution. Clients are also entities that request identity information or an access token so that they can securely invoke other services on the network that are secured by Red Hat Single Sign-On.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[[composite-role]]
+==== image:images/yes.png[yes] composite role
+*Description*: A composite role is a role that can be associated with other roles. For example a `superuser` composite role can 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.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[consent]]
+==== image:images/yes.png[yes] consent
+*Description*: 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, Red Hat Single Sign-On opens a screen identifying the client requesting a login and what identity information is requested of the user. Users can decide whether or not to grant the request.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[credentials]]
+==== image:images/yes.png[yes] credentials
+*Description*: Credentials are pieces of data that Red Hat Single Sign-On uses to verify the identity of a user. Some examples are passwords, one-time passwords, digital certificates, or even fingerprints.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[direct-grant]]
+==== image:images/yes.png[yes] direct grant
+*Description*: A direct grant is a way for a client to obtain an access token on behalf of a user through a REST invocation.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[event-rhsso]]
+==== image:images/yes.png[yes] event
+*Description*: An event is an audit stream that administrators view and connect to.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[group]]
+==== image:images/yes.png[yes] group
+*Description*: A group manages a collection of users. You can define attributes for a group. You can also map roles to a group. Users that become members of a group inherit the attributes and role mappings that group defines.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[identity-provider]]
+==== image:images/yes.png[yes] identity provider
+*Description*: An identity provider (IDP) is a service that authenticates a user. Red Hat Single Sign-On is an IDP.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[identity-provider-federation]]
+==== image:images/yes.png[yes] identity provider federation
+*Description*: Red Hat Single Sign-On can be configured to delegate authentication to one or more IDPs. Social login through Facebook or Google+ is an example of identity provider federation. You can also hook Red Hat Single Sign-On to delegate authentication to any other OpenID Connect or SAML 2.0 IDP.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[identity-provider-mappers]]
+==== image:images/yes.png[yes] identity provider mappers
+*Description*: 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.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[identity-token]]
+==== image:images/yes.png[yes] identity token
+*Description*: An identity token provides identity information about the user and is part of the OpenID Connect specification.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[protocol-mapper]]
+==== image:images/yes.png[yes] protocol mapper
+*Description*: For each client, you can tailor what claims and assertions are stored in the OIDC token or SAML assertion. You do this for each client by creating and configuring protocol mappers.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[realm-rhsso]]
+==== image:images/yes.png[yes] realm
+*Description*: 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.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[required-action]]
+==== image:images/yes.png[yes] required action
+*Description*: A required action is an action that a user must perform during the authentication process. A user cannot complete the authentication process until these actions are complete. For example, an admin might schedule users to reset their passwords every month. An update password required action is set for all these users.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[role]]
+==== image:images/yes.png[yes] role
+*Description*: A role identifies a type or category of user. `administrator`, `user`, `manager`, and `employee` are all typical roles that might exist in an organization. Applications often assign access and permissions to specific roles rather than individual users because dealing with users can be too granular and hard to manage.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[service-account]]
+==== image:images/yes.png[yes] service account
+*Description*: Each client has a built-in service account to obtain an access token.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[session-rhsso]]
+==== image:images/yes.png[yes] session
+*Description*: When a user logs in, a session is created to manage the login session. A session contains information such as when the user logged in and what applications have participated within single sign-on during that session. Both administrators and users can view session information.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[theme]]
+==== image:images/yes.png[yes] theme
+*Description*: A theme defines HTML templates and stylesheets that you can override as you require. Every screen that Red Hat Single Sign-On provides is backed by a theme.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[user-federation-provider]]
+==== image:images/yes.png[yes] user federation provider
+*Description*: Red Hat Single Sign-On can store and manage users. Often, companies already have LDAP or Active Directory services that store user and credential information. You can point Red Hat Single Sign-On to validate credentials from those external stores and pull in identity information.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:
+
+[discrete]
+[[user-role-mapping]]
+==== image:images/yes.png[yes] user role mapping
+*Description*: 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.
+
+*Use it*: yes
+
+*Incorrect forms*:
+
+*See also*:

supplementary_style_guide/master.adoc

@@ -208,5 +208,8 @@ include::glossary_terms_conventions/product_conventions/red-hat-openstack-platfo
 ==== Red Hat Satellite 6
 include::glossary_terms_conventions/product_conventions/red-hat-satellite6.adoc[leveloffset=+1]
 
+==== Red Hat Single Sign-On
+include::glossary_terms_conventions/product_conventions/red-hat-single-sign-on.adoc[leveloffset=+1]
+
 ==== Red Hat Virtualization
 include::glossary_terms_conventions/product_conventions/red-hat-virtualization.adoc[leveloffset=+1]