Federation Concepts

SAML v2.0

Simple Access Markup Language is an XML based protocol exchange, for platform Independent interaction between an IDP and SP. SAML version are SAML v1.0 and v 2. SAML v2 support is standard for may Access Manager product like Oracle Access Manager and Forgerock OpenAM.  The SAML request, the assertion(response)  and the SAML logout request are all XML based document.

The different components of SAML are profiles, binding, protocols and assertion.  The SAML binding support the following HTTP Redirect, HTTP POST, SOAP, HTTP Artifact. Assertion consist of user authenticated information, authorization, protocol in a well formatted meeting the XML specification.  Assertion will have zero or  more statements of user confirmed by the IDP.  They are  authentication, attribute and authorization decision. The authentication information has the subject information,  time and method of authentication. The attribute statement has the claims of the user who was authenticated and the authorization information.  The attribute is an piece of information of the authenticated user.

 An authorization include information to allow access or deny access to  particular resource. All the information are in SAML specified XML format.

 Identity provider:

 IDP is the service which authenticates the user who submits the credentials or uses a x509 crt. The IDP verifies the user and creates and assertion. When creating the assertion, it signs the assertion with the public certs it had exchanged with the service provider.

The assertion will contain the attributes/ claims of the authenticated user. The assertion is signed and encrypted by the singing and encryption key. The assertion is created in response to the SAML request created by the SP. The assertion will have the request id seen in the SAML  Authn request.

Service provider:

 SP are the portal or application which provide services to the authenticated user, the assertion generated by the IDP after successful authn, will have the information required by SP to allow the user in for the services. The private key of the SP will be used to decrypt the contents of the assertion. The nameID value in the assertion will give the SP, maybe the email address or any unique identifier to link the user to the local repository.

 Circle of Trust / Trust RelationShip:

In a trust model, a IDP creates an trust with SP or multiple SPs through the exchange of metadata.  The metadata has the information of the IDP and SP. It has the entity id (unique), the certificates, the nameID format either unspecified, email or x509. The nameID is the unique identifier  to map the user. The metadata also has information on the assertion consumer Url, single sign on url and the single logout url.   The metadata will also have information as to how the assertion is consumed, either as HTTP POST or artifact.

Signing & Encryption:

The signing certificate and encryption certificates are used to sign and encrypt the assertion contents. These certificates are exchanged as part of the metadata exchange embedded within the  KeyDescriptor tag of the metadata.

SSO using SAML : Single sign on and Single logout url are configured at the identity provider and service provider side to allow for users to properly sign in and successfully terminate the session.

Dynamic profile & Federation Enabled :

If the dynamic profile creation is enabled, and if the profile doesn’t exist in the service provider’s repository, an profile is created with the attributes send in the assertion.   The NameID in the assertion will also be stored with the user profile and it becomes the linking value for the user who has successfully authenticated at the IDP end.