Glossary of SSO Terms

Assertion

An assertion about a user that an IDP makes.

An assertion is a package of information that supplies one or more statements made by a SAML authority. SAML defines three different kinds of assertion statement that can be created by a SAML authority:

Authentication: The specified subject was authenticated by a particular means at a particular time. This kind of statement is typically generated by a SAML authority called an identity provider, which is in charge of authenticating users and keeping track of other information about them.

Attribute: The specified subject is associated with the supplied attributes.

Authorization decision: A request to enable the specified subject to access the specified resource has been granted or denied.

Assertion Consumer Service

This can mean different things, but in this context, it is NOT SAML specific. In fact, we will have a generic service which will take assertions and convert them into a JWT.

Attributes

Attributes are any data that may come back from an IDP. Typically, these will be in some sort of map format. This data might be roles, groups, birthday, organizations, or any other data that is useful for granting or restricting resource authorization to users.

Authentication

Confirm the identity of the user. This is where the user provides some credentials to prove they are who they claim to be.

Authorization

DANGER: Authentication and Authorization are very different concepts. It is important to fully understand the difference between them as people often shorten either one to "auth" when discussing them.

Determine whether a user has the authority to do an action or access a resource.

Authorization Grant

The grant that proves the user has consented to share data from the third party IDP to the SP

Authorization Server

Tip: This is OAuth specific.
Note: This is often, but not always separate from the Resource Server.

The server which will be doing the authorization activities on behalf of the client.

Back Channel Request

This is a request that is made from one server to another server.

Back Channel requests are made because secure data shouldn't be stored on the browser

Client

Tip: This is OAuth specific.

The client is the system that is requesting authentication/authorization details from the IDP

Client Credentials Flow

Attention: Heretto does not support this flow at this time as it is not considered to be as secure as the authorization flow.

Another Back Channel only request flow.

Client ID

This is the ID that is assigned to the Service Provider (our portal app, in this case) from the IDP. We will reference this in authentication requests that we make to the IDP so it can know who we are, and can verify our identity when it is processing such authentication requests

Client Secret

This is the secret by which we can sign authentication requests that are sent from the SP to the IDP (again, in the case of this document, from the portal to the IDP). This is very important as we want to prevent any impostors from creating a bogus request that looks like it came from our service, but is perhaps really a malicious service.

Front Channel Request

This is any request that is made directly by the browser to a server

Identity Provider

A separate service which knows enough about the user to confirm their identity.

Implicit Flow

Attention: This is not as secure as the Authorization Flow as there is no safe way to store the client secret, as such, Heretto does not support this flow.

This is a front-channel only authorization flow, that doesn't include the server making back-channel requests.

JWT

Attention: Pronounced as "jot".

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

  • Header
  • Payload
  • Signature

OpenID Connect

Built on top of OAuth 2.0, it is a layer which provides Identity management on top of OAuth 2.0. This is the first type of support that we will be building into our portal.

Redirect URI

Callback URI where the User Agent will be redirected back to after authentication from the IDP

Resource Owner

Tip: This is OAuth specific.

This is the owner of private information about the user who we need to authenticate and authorize. So for instance, this is perhaps the third party that will give us the names of the audiences that the user belongs to.

Resource Owner Password Credential Flow

Attention: Heretto does not support this flow at this time as it is not considered to be as secure as the authorization flow.

Back Channel only request flow.

Scope

Indicates the scope of what the client is asking the authorization for access to. For instance, if it is asking access to "Profile contacts", but that's it, and it can't for instance get access to "email content", then this is what would be identified in the scope.

Service Provider (SP)

The provider of the service. In our case, the Service Provider will always be the portal itself.

WAYF

This is an acronym for "Where Are You From". This page is relevant if there is more than one IDP which a user may be able to identify themselves from. For instance, if a user may be able to identify with Twitter, Facebook, and Google, this page will show them all of the available options that are configured for this site.