Overview

The AAF employs certain software to maintain a Federation, identity management and service provider software. Our technical and support staff are constantly upgrading, maintaining and changing this software so it stays current to other supporting software, additional technological advances and a better standard of service in general. Every effort is made to make participants aware of new versions, amendments and variations to our software and services. 


Prerequisites

Federation, software including identity management and service provider software which is utilised by all participants may need to be changed and upgraded periodically to ensure it complies with standards of security, versions as well as the Federation rules which have been agreed to during sign up. Each entity must comply within a reasonable timeframe or may face issues of compatibility and usability. The details below will vary according to age and currency and may be checked periodically to ensure that your institution or organisations is compliant with the current protocols, versions and software systems.


Details

AAF protocols, Software systems and Versions.

 Protocol      Level of Support
 SAML 2.0  Supported
 SAML 1.1  Limited support   
 SAML 1.0  NOT supported


 Software      Level of Support
Shibboleth System 2.x and minor releases   Shibboleth IdPv2 series will be End-Of-Life on the 31 July 2016.
This does not apply to the Service Provider software, which is fully supported.
Shibboleth System 1.3.x and older   Limited support - being phased out of the AAF. (Shibboleth 1.3 had its end-of-life on June 30, 2010)  
Other SAML-based, federated identity management systems   Limited support, best efforts from AAF support staff.



Federated Service Outline

We understand that each service is different, and we are able to provide additional advice to help you with your specific integration challenges. However, there are some common elements which all service providers should understand before trying to build a custom solution.

Federated Authentication Interaction

With traditional authentication mechanisms, the user would present their username and password directly to the web server (e.g. basic authentication) or to your application (web form authentication). In a federated environment this interaction does not take place directly with your web server.

Additionally, because your server will not verify the user's credentials directly, you no longer need be concerned about ensuring you have secure password storage.

The basic interaction is:

  1. User attempts to visit your application, and is intercepted by Shibboleth SP
  2. Shibboleth redirects the user to the DS
  3. User selects their IdP from the list
  4. DS redirects the user to their IdP
  5. IdP authenticates the user and resolves their attributes
  6. IdP generates a SAML Assertion, which identifies the user
  7. SP receives the SAML Assertion, verifies cryptography and uses it to establish a session
  8. SP redirects the user back to your application
  9. SP components inject user's attributes into the web environment

Shibboleth handles all the communication and verification required for federated authentication, so your application can trust the user attributes that are injected without needing to verify anything. This also simplifies development, as you can create your own development component which injects attributes as if they had come from Shibboleth. With this in mind, your application can treat the environment simply as:

This means your application will receive user attributes, and can trust and consume those without being concerned about where they came from.

Requirements

To deliver a service using Shibboleth, you will need the following components:

  • Shibboleth
  • Apache or IIS, configured to include the Shibboleth module
  • Your application which is capable of receiving attributes in the way Shibboleth provides them

See the Shibboleth documentation for information on the deployment and operation of Shibboleth.

Rapid Connect Interaction

When using Rapid Connect, the interaction is all your application's responsibility. While this sounds like more work, it is our experience that adding Rapid Connect authentication to an application is much simpler than testing and deploying with a Shibboleth SP. Additionally, as all the logic lives in your app, it enables the use of cloud services which don't support Shibboleth such as Heroku and Google App Engine.

The interaction is now:

  1. User attempts to visit your application, and is intercepted by your Application Request Filter.
  2. Your Application Request Filter redirects the user to your Rapid Connect Endpoint. This endpoint is provided by Rapid Connect during registration. It will make your life easier if this is easily configurable in your app.
  3. Rapid Connect performs federated authentication as detailed above. This means the user performs a normal federated login.
  4. Rapid Connect receives the user's attributes, and uses them to generate a signed JWT which is sent to your Callback URL via HTTP POST.
  5. Your Callback URL receives the JWT, verifies that it is valid per the AAF Rapid Connect documentation and uses it to establish a session.
  6. Now that the session is established, your Application Request Filter permits access to the Protected Content.

Requirements

To deliver a service using Rapid Connect, you will need the following components:

  • Your application which is capable of performing the redirect and receiving a JWT response

The goal of Rapid Connect was to ensure as few dependencies as possible are required, to greatly simplify deployment.

Consuming attributes injected by SP

There are two basic models for using a Shibboleth SP:

  • Directly protect all the content with the SP
  • Protect a "login" endpoint with the SP, and use that endpoint to establish a session with your application

The second of these is more common and much more flexible but requires a little more work.

Directly protecting content with the SP

This model is best suited to static content, or web applications with no need to maintain session state (e.g. displaying a user's name purely for customisation).

In this model, the flow of a request is quite simple:

For each request, Shibboleth will verify the user's session with the SP, and pass the attributes through to your application. When the user's session expires, they will be transparently authenticated again and be able to continue.

This is supported out-of-the-box by Shibboleth SP, by simply requiring a Shibboleth session for the entire website.

Managing your own sessions

In this model, the flow of requests is a little more complex, but affords much greater control:


Notes

(Note this is only an example of one potential setup, for illustrative purposes. Endpoint names and other specific details are just a sample.)

In this scenario, when the user attempted to access Protected Content without an active session, they would be directed to a login selection page (in Unprotected Content), where the user could choose to log in via the AAF or via whatever additional mechanisms are available. From there, the user's browser would be sent to one of the login mechanisms:

  • /auth/aaf which accepts attributes from Shibboleth SP, and uses them to create a session which can be inspected later to verify the user has authenticated. It is intuitive that a Rapid Connect Callback URL could be used in place of /auth/aaf, if Rapid Connect was being used in place of Shibboleth SP.
  • /auth/other which provides an alternate login mechanism for users who are not part of the federation, or for special use cases such as administrative login. In a real app, there can be as few or as many login mechanisms as you like, and you may use any endpoint naming scheme you wish.

Once you have control over session establishment via whatever mechanism, you can use that to launch extra steps such as auto-provisioning of unknown users, updating attributes that have changed for known users, or forcing users through a one-time "Terms of Service" page for your SP.

The Application Request Filter would be responsible for detecting an unauthenticated session, and redirecting the user to the login selection page. Once a session has been established, access to the Protected Content would be permitted by the Application Request Filter.