Thursday, 3 December 2015

Example Configuration - Dynamic Account Federation

The situation

In this example we will walk through connecting an SP which has an attached datastore with no users in it, and an IdP which has a list of users. By logging into the IdP if the user does not exist in the SP’s datastore, it will generate a user in the datastore on the SP whose attributes will be populated by the mapped attributes from the IdP’s datastore for that user. Those attributes will also be available in the user’s session properties. If a login does already exist in the SP’s datastore these values will not be updated by this process, but new values read from the IdP’s datastore on each login will be propagated into the SP user’s session properties.

The Setup

This article will briefly describe the method to configure an SP which wishes to federate in their entirety accounts on the IdP’s side into a local datastore. To configure dynamic account federation using the SAML2 authentication module, it’s necessary to configure some specific options inside the module and also inside the SP’s settings.

We’ll start by generating an SP using the common tasks wizard.

It is necessary to map the attributes which will be used to generate the data from the datastore - this is performed on the SP’s side. In this example, we will use the special *=* mapping, which means “for each attribute in the assertion, generate an attribute with that same name and value and store it in the generated session (and in the datastore if generating a local user account)”.

Next, we need to enable auto-federation in the SP’s configuration. This should be done by selecting the ‘auto federation’ checkbox and supplying an attribute which acts as a unique identifier on the IdP’s side. As we’ll be federating the ‘uid’ attribute from our IdP (see the later steps of this article), we’ll enter ‘uid’ here.

Finally as we’ll be using this SP in an authentication chain, as per the article SAML2 in chain authentication - The SAML2 Auth Module we must alter the Assertion Consumer Service for HTTP-Artifact and HTTP-POST binding types.

Now we’re ready to link our IdP and SP together using the ‘register remote [service/identity] provider’ common tasks in the appropriate provider. While you’re linking the SP to the IdP, you should set up some attributes from the IdP which will be included in the assertion which is sent to the SP - earlier we indicated that ‘uid’ would be our unique identifier, so let’s ensure we’re going to expose that, alongside a field we’ll recognise when we see it on the SP’s side - in the example here I’ve chosen the ‘mail’ attribute, and mapped it to a key/value in our assertion whose key is also ‘mail’. As the SP was configured with *=*, the ‘mail’ attribute in our assertion will be dynamically mapped to a ‘mail’ attribute in our SP’s datastore, as well as a session property named ‘mail’.

Finally on the IdP, let us generate a subject in the IdP’s datastore with a subject whose mail attribute is populated so that we will recognise it when we see it in the SP’s datastore later, and when we check the value of the federated session's properties.

Now the IdP is configured, it’s time to set up the authentication module proper.

Head back to the SP. Firstly, dynamic account creation must be enabled in the realm’s authentication settings:

Next, generate a new SAML2 authentication module. Here you’ll want to enter the SP meta alias and IdP Entity ID for your local SP and your remote IdP respectively. As we want the accounts to be persistently linked, we’ll allow for identifiers to be generated on the IdP by enabling Allow IdP to Create NameID and setting the NameID Format to urn:oasis:names:tc:SAML:2.0:named-format-persistent. No other configuration settings are necessary to demonstrate the dynamic account federation process.

Finally, we’ll need to generate the chain which will hold the authentication module. In this example, we will simply have the authentication module alone, and no other module following it.

Users attempting to access the SP will be prompted to log in to the IdP. If their accounts are already linked, they will then immediately be logged into the SP also. If their accounts aren't already linked, after successful IdP authentication their account information will be federated over to the SP, and they will be redirected back to the SP as that newly federated user.

No comments:

Post a Comment