Thursday, 3 December 2015

Example Configuration - Anonymous Session Generation With Federated Attributes

The situation

In this example we will walk through connecting an SP which has no attached datastore, and an IdP which also have a list of users. By logging into the IdP the user will generate an anonymous session on the SP where their session properties are filled with the attributes mapped from the IdP’s datastore attributes.

The Setup

To configure anonymous session generation 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 in the generated anonymous session”.

Next, we need to enable the anonymous user account in the SP’s configuration. This should be done by entering ‘anonymous’ in the Transient User field.

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 - let’s include 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 the session generated on the SP’s side.

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 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, let’s ensure that the user profile is ignored by dictating so to the settings:

Next, generate a new SAML2 authentication module. Here you’ll want to enter the meta alias and IdP Entity ID for your local SP and your remote IdP respectively. As we don’t want the accounts to be persistently linked, we’ll set the NameID Format to urn:oasis:names:tc:SAML:2.0:named-format-transient. No other configuration settings are necessary to demonstrate the anonymous session 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. Once authenticated they will be redirected back to the SP with a session belonging to the anonymous user, and the mapped attributes in their session's properties.

No comments:

Post a Comment