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.

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 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.

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

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

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

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

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

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

Another Back Channel only request flow.

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

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.

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

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

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

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

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.

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

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.

Back Channel only request flow.

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.

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

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.