Are you ready (technically) to join a Trust Federation?
If you are an organisation that wants to join a trust federation then, in order to get the full benefits, your IT functions will need to be up to speed.
Presumably you want to join a trust federation in order to deliver the following benefits to you organisation and its members (staff, students etc):
- Extend the reach of your members by becoming an Identity Provider (IDP):
- Give your members more seamless (single sign on) access to external services (e.g. information resources)
- Give your members access to external restricted services (services that were previously unavailable to you but can now be accessed on a controlled basis only if you are a federation member)
- Extend the reach of your systems/resources by becoming a Service Provider (SP):
- Make it easer for members of other organisations to seamlessly access your resources
- Make your previously in-house/restricted services available to other external federation members on a controlled basis
Identity Provider
Hopefully you already have an internal (enterprise) identity management system (IDM) with single sign on (SSO) to all your internal systems. If so then you are well placed to enhance this capability into a federation Identity Provider (IDP). This is the ideal as it gives your members seamless SSO to both internal and federation systems.
In enhancing your IDM into an IDP you will need to be able to:
- Support the federation’s SSO protocol to authenticate your members to the external SP
- Support the federation’s agreed set of member attributes and attribute values.
For example the Shibboleth-based UK Access Federation requires IDPs to be able to supply (subject to the organisation/member’s privacy/attribute release policy) member attributes like:
- eduPersonScopedAffiliation. This attribute indicates the user’s relationship (e.g., staff, student, etc.) with the organisation.
- eduPersonTargetedID. a persistent user pseudonym (opaque identifier) used to uniquely identity the user.
- eduPersonPrincipalName. the user’s single sign-on (SSO) name.
- eduPersonEntitlement. A more advanced (optional) capability that enables an organisation to assert that a user has a specific privilege.
If you are not at this level yet and/or you are a small organisation then the trust federation usually provides a virtual IDP service that your members could use as an initial solution. This means more proliferation of identities and passwords but at least it gets you going in the federation.
Service Provider
If you want parts of your web-based systems and resources to be accessed on a secure, controlled basis and restricted to only other federation members then you need to enhance your application so that is operates as a Service Provider (SP). The main areas of your application that you may need to enhance are described below.
Registration
Most applications provide a registration form where you have to fill in details about you (identity attributes). A SP-enhanced application can streamline this process by pre-filling in much of the form by querying the federation to get user attributes. The application can also control who can register by querying the user’s attributes. For example you might decide that you don’t want registration open to the public: only federation members are allowed to register.
Logon
A SP-enhanced application can auto-logon the user via SSO with the federation.
Access Control
An SP-enhanced application can implement access control to functions and information based on the user’s attributes provided by the federation. This enables you to implement any combination of access control policies like:
Only federation members can see/do this
Only federation members from a specific organisation can see/do this
Only federation members with a specific affiliation (e.g. staff/faculty) can see/do this
Only federation members with a specific entitlement (e.g. approved purchasing authority) can see/do this
Summary
These concepts are fairly common to most trust federation architectures including:
- Shibboleth
- Liberty Alliance
- WS-Federation
- and even OpenID
Of course, the amount of work and complexity involved can be quite different. Whether or not OpenID qualifies as a trust federation architecture is a subject for another time!
Once your IDM and Web-systems are architectured to support these capabilities you will be well positioned to take early advantage of the benefits of trust federation membership.