Federated Access Management (FAM) systems have been in use in the Library and Educational IT communities for a number of years and have came about from a need to have common standards to allow external users access to services. This is a high-level discussion with a brief history of FAM, how it ties in with an organisation's existing Single-Sign-On (SSO) infrastructure, the role that the Federation has in maintaining the trust relationships between organisation's Identity Providers (IdPs) and Service Providers (SPs) and now between federations and how it's being used by the wider (non-academic) community.

1. Federated Access Management
Mark Cairney
Information Services IT Infrastructure
UNIX Section
University of Edinburgh

2. What is Federated Access
Management?
• Trust framework between institutions and
services
• User Authentication devolved to each
institution via a local Identity Provider (IdP)
• Authorisation handled by the Service Provider
(SP) based on attributes sent to it by the IdP

3. What is FAM?
• Trust relationship handled by both sides
containing metadata describing each other
• Federation is responsible for managing and
publishing metadata for all members (IdPs and
SPs)
• Also responsible for establishing policies
regarding data exchange between members
and ensuring they are being adhered to.

4. What is FAM?
• Federations established at a geographical area
(country/continental) level e.g. InCommon
(US), UKAMF (UK), eduGAIN (Europe)
• Now starting to see inter-federation
agreements e.g. UK Federation <-> eduGAIN
• Establishing standards/good practice becomes
an even bigger issue with inter-federation!

5. FAM Systems
• Number of competing FAM solutions (both
FOSS and commercial)
– OpenAthens
– Shibboleth
– OpenAM
– Microsoft AD FS
• We’ll be looking at Shibboleth as it’s what I
know best! 

6. Shibboleth
• Free, Open Source
• Popular in education sector
• Gaining traction outwith education
• 3 main components:
– Identity Provider (IdP)
– Service Provider (SP)
– Discovery Service (DS aka Where Are You From?)

7. Identity Providers (IdP)
• Locally-installed server integrated with
organisation’s local infrastructure (SSO,
identity management)
• User logs in with their local SSO credentials
• IdP authenticates user and looks them up in
local Identity source (LDAP, AD, database)

8. Identity Providers (IdP)
• User information parsed, processed and only
permitted attributes are sent back to the
Service Provider (SP)
• By default all members of the UK Federation
are sent a minimal set of attributes
• Additional attributes have to be explicitly
released by the IdP administrator
Can have multiple metadata sources and rules
for attribute disclosure

9. Service Providers (SP)
• Module performing login to service
• Receives attributes from IdP and uses these to
perform authentication and authorisation of
user.
• N.B. Service Provider performs authorisation
decision based on attribute data received- it’s
NOT the IdP’s job to perform authorisation!!

10. Discovery Service
• Formerly Known as WAYF (Where Are You
From)
• Essentially a list of available IdPs
• UK Federation run one for general use OR
• Roll your own to present a subset of these
• Optional- you can hardwire your SP to speak
to a specific IdP (but this isn’t really
federation)

11. SAML
• AKA Security Assertion Markup Language
• Standard dialect for IdPs and SPs to talk to
each other
• Standards (SAML1 / SAML2)
• Possible (though not always straightforward!)
for IdPs and SPs of different flavours e.g.
Shibboleth and OpenAthens to talk to each
other.

12. WOW!
User
IdP
SP
Discovery
Service

13. The Federation
• Maintains and publishes the metadata
consumed by member entities (i.e. IdPs and
SPs)
• Metadata used to form trust relationships
• Responsibility for the metadata feed and for
ensuring members adhere to good practice
(security, privacy etc)
• Monolithic

14. Inter-federation Trust
• More of a political challenge than a technical
one
• Participating federations have to negotiate
common standards re: metadata structure,
key lengths/types, attributes required.
• Best practice wins!
• End result is an aggregated metadata file is
published by participating federations

15. Other Federated Identity Systems
• OpenAthens- very similar to Shibboleth
• Commercial entity, ran by EduServ
• Can either run your own IdP or have
OpenAthens run it for you for a fee.
• Technology very similar to Shibboleth(SAML-
based, monolithic Federations)

16. Other Federated Identity Systems
• Eduroam- used in Higher Education to provide
federated roaming wireless access
• Built on FreeRADIUS
• Managed and maintained in the UK by JANET
• External users credentials are relayed back to
their home institution for authentication

17. Future of Federation
• Current models work well for web-based
authentication (Shibboleth) and/or specific
protocols (eduroam)
• However there is an increasing requirement
for support of multiple protocols and for some
level of devolved federation management

18. Shibboleth IdPv3
• Still SAML2-based but with a number of
improvements based on experience gained
with v2
• Improvements include:
– User consent for releasing attributes
– Session state largely stored client-side in
encrypted cookie store.

19. Moonshot
• Based on FreeRADIUS 3 with additional
functionality provided by Shib libraries
• Provides some level of devolved management.
• Multi-protocol support (SSH, Web, Exchange)

20. Moonshot - Disadvantages
• Requires bleeding-edge versions of
FreeRADIUS and Moonshot dependencies
• Work-in-progress- steep learning curve and
documentation not comprehensive
• Requires software to be installed on both
clients and services to support it- some of
these (e.g. OpenSSH) depend on locally
patched versions.

21. Questions?
• E: Mark.Cairney@ed.ac.uk
• T: @mcairney
• http://www.ukfederation.org.uk
• http://shibboleth.net/
• http://www.jisc.ac.uk/assent