Identity & Single Sign On – Part 2

Identity Protocols

To implement and configure SSO you will need to use a modern authentication protocol such as SAML, OpenID Connect and OAuth. In this post I’ll focus on SAML.

Security Assertion Markup Language (SAML)

Think back to the airport analogy in Part 1, then read on….

SAML is a standard used to exchange authentication and authorization information between different parties. This normally occurs between an Identity Provider (IdP) and a Service Provider (SP)

I’ll go into more detail later, for now I just want to keep it simple.

Identity Provider (IdP)

An IdP is a platform that is used to create and supply security tokens (SAML) to the SP you want to access. Security Tokens are created and issued after authentication occurs and used for authorization. An IdP can also be referred to as an ‘issuer’.

An IdP is something your organisation owns or subscribes to. Examples of these are Active Directory Federation Services (ADFS), Azure AD or Okta, there are plenty more. Any documentation I reference will be aligned to these platforms.

Service Provider (SP)

The Service Provider is the service or application that you want to access using a security token (SAML). For the SP to accept security tokens from your IdP it must have a trust in place so that it knows that the requests are coming from a valid source of identity, this is achieved by using a metadata file.

Metadata File

A metadata file is information provided by your IdP and can be given to the vendor of the SP, ingested into the service or application which ensures the SP trusts any security tokens (SAML) it receives from the IdP.

A metadata file will always have at least 3 common properties

EntityID – This is the identifier of the IdP (SP’s have these as well). Every SAML message sent contains an EntityID of the IdP (issuer).

Cryptographic Keys – Each SAML message sent is digitally signed by the IdP and the SP can decrypt the message using it’s private key verifying the signature using the public key of the IdP. This is stored in the metadata file.

Protocol Endpoints – The SAML message (also known as a SAML Assertion) once it has been digitally signed by the IdP is sent to a special URL or endpoint where it is processed by the SP. This is also known as the ‘Single Sign On URL’

SAML Assertions

SAML Assertions come in 3 parts and are sent from the IdP to the SP.

  • Authentication assertions are you used to confirm the user has authenticated and includes the time and the protocol used.
  • Attribute assertions are specific user attributes or information that identifies the user.
  • Authorization assertion confirms what the user has access to within the SP.

Part 3 coming soon

One thought on “Identity & Single Sign On – Part 2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s