Like most areas of IT, Identity and Access Management (IAM) has its own terminology, acronyms and jargon. Lots of terms are specific to standards such as SAML and others are more generic and apply to the entire domain of digital identity. Here’s some of the important terms and concepts to understand:
Identity Provider (IdP)
This is a technology service (for example, OneLogin) that can “assert” a user’s identity to another resource. An IdP is responsible for authenticating users in an identity management system.
Service Provider (SP)
This is the service that the user wants to access (such as a public or private web application). The application is a SAML Service Provider (also known as a Relying Party), because it provides some service to the user.
SAML represents a user’s identity in the form of a “SAML assertion”. A SAML assertion is a message of text with a specific format (the SAML format) that identifies the user to the Service Provider they are trying to access. The Identity Provider’s SAML message to the Service Provider is often called a Claim or Token. Token is understandable as a name because a token by definition is an object that represents something abstract; in this case it’s a message (object) that has the users identity (abstract value). Claim, is a little stranger if you’ve never heard this term before; basically, the Identity Provider claims that the user is a particular person and has a level of permission associated with them. The IdP communicates the user’s identity via SAML to the Service Provider. In this case, the Identity Provider is making a claim about the user’s identity to an application.
Endpoints are tricky and you need to be technical to really understand them. To put it simply, a web application will expose an “endpoint” on the internet (it will be a web address like www.myapp.com/saml/consume for example). This is the place where the Identity Provider sends the SAML assertion. So, when OneLogin is telling a web app who the user is, OneLogin will send a SAML assertion to a web app’s SAML endpoint. It’s usually sent via HTTP or through a redirect (don’t worry too much about this), but when it arrives at an application’s endpoint the application has some code sitting there that can receive the token/claim/SAML assertion and perform the required workflow to create a session for that user and sign them in! There is also an endpoint that exists at the Identity Provider. The Identity Provider’s endpoint is where the application can ask the IdP “Hey, who is this user?”.
SAML is a request/response workflow. If a user goes to a web app and attempts to sign in, the application will send a SAMLRequest to the Identity Provider. The SAMLRequest is the mechanism through which the app can ask the identity provider about a user’s identity. The Identity Provider will then receive the SAMLRequest, try to authenticate the user, and once the user is authenticated will send a SAMLResponse back to the application’s SAML Endpoint.
The service provider’s mechanism for requesting a user’s identity.
The message sent back to the application containing the user’s identity. It’s important to note that the SAMLResponse contains the SAML assertion within it. The SAML Response is the Token/Claim.
A federation is the act of setting up a SAML connection between an identity provider and the service provider. This involves the customer providing the Service Provider with certain information related to their Identity Provider so that SAML based single sign-on can take place. Once the configuration is complete, it is said that a federation exists between the IdP and the SP. A federation may also be called a “trust”, because setting up single sign-on is the act of establishing trust between an application (the Service Provider) and an Identity Provider like OneLogin.
Yes, there is definitely more terms to add this list. So, please leave your comments below on what you think I left out and I can add them to the list!