Technical Requirements of the UK Access Management Federation

Access Management Transition Programme Meeting Technical Birds of a Feather Session

Firstly, an apology…
“ Selling Beauty, Killing Beast: the Role of Binary Oppositions in Children’s Fantasy Literature.”

In this session
What does the Federation require me to do technically?
What about the technical recommendations?
Recently asked questions.
Feedback from an early adopter.
Open Floor for questions and queries.

The Rules of Membership - Important Technical Sections
Section 3 (major undertakings)
To provide accurate and up-to-date information (metadata) and promptly make changes to the metadata known to the Federation Operator.
Reasonable endeavours to comply with the Technical Specifications (Technical Recommendations for Participants).
Good practice in relation to the configuration, operation and security of the system.
Good practice in exchange and processing of Data, and in obtaining and managing DNS names, digital certificates and private keys.
Section 6 (accountability)
Documented process for issuing credentials.
Documented process for educating end users.
Revoke credentials ‘promptly’.
Do not reissue for 24 months after revocation .
Keep authentication logs for between 3 – 6 months.
That’s about it from a technical perspective (see policy session for other arguments).

Technical Recommendations for Participants
8 sections:
Introduction: very general stuff about when and how changes made to documents.
Software: current software options available to use within the UK federation.
Authentication Requests and Response Profiles: profiles you need to be able to talk to other members.
Metadata: the information published describing how members talk to each other.
Digital Certificates: how to use certificates for both the trust fabric and end users.
Discovery: all about the ‘discovery problem’.
Attribute Usage: how to describe your users and their potential access rights.
References: Where to find out more stuff.

Software Choice
Broadly speaking, you can use any software as long as it is SAML compliant, enables you to meet the Rules of Membership (and practically has been tried and tested by the Federation Operator).
Currently:
Shibboleth 1.3 is used around 90% of Members (1.1 and 1.2 not recommended). 1.3 is recommended for all new users at present as 2.0 not yet stable and tested.
Guanxi / Athens IM / others.
Microsoft ADFS??
Extensive testing by JISC projects @ LSE / UKERNA / Internet2 proved that it is technically feasible with some caveats.
Practically, it would require all Members of the Federation to maintain two sets of metadata.
As such, will not be supported.
A better packaged 1.3 and 2.0 Shibboleth for Windows environments coming soon!
That is all the UK federation is going to tell you about software choice!

Authentication Requests and Response Profiles
Authentication Request Profile: basically just a GET request.
ONLY recommended Authentication Request Profile is the Shibboleth Authentication Request Profile. All current Members implement this profile.
Response Profile: how the Identity Provider responds to Service Provider after authentication established.
Recommended: SAML 1.1 Browser/POST with Attribute Pull.
Browser/POST only response profile known to be supported by all Members.
Attribute Pull means that authentication information is sent without attribute information.
Don’t do it with Attribute Push!
SAML 1.1 Browser/Artifact with Attribute Push.
Some good things, e.g. no need for Javascript support in user’s browser.
Not well supported by Members.
Do not deploy on its own.

Metadata (1)
You must have a policy for attribute release!
Standard Shibboleth ARP releases eduPersonScopedAffiliation to all Service Providers, easily modifiable to include eduPersonTargetedID as below:
<?xml version="1.0" encoding="UTF-8"?> <AttributeReleasePolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mace:shibboleth:arp:1.0" xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd" > <Description>Simplest possible ARP plus targeted ID.</Description> <Rule> <Target> <AnyTarget/> </Target> <Attribute name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"> <AnyValue release="permit"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"> <AnyValue release="permit"/> </Attribute> </Rule> </AttributeReleasePolicy>

Metadata (2)
UK federation metadata available at: http://metadata.ukfederation.org.uk/ukfederation-metadata.xml .
Refresh metadata daily – metadata tool with Shibboleth release for this.
Shibboleth 1.2 metadata currently has to be maintained separately – this will be deprecated, but no date is currently set for this.

Digital Certificates
Must use a certificate from one of the published list of providers.
Recommend that you make use of the free certificates available from the Janet Server Certificate Service (SCS): http://www.ja.net/services/scs.html .
Follow instructions with regards to compromised keys.

Discovery
The Discovery Problem: if the user visits the Service Provider from an unknown context, how does the Service Provider direct them to the right Identity Provider?
Avoiding Discovery through Institutional Portals. Recommended that you arrange with Service Provider to be updated with any changes to SP configuration.
SP’s using local WAYFs. JSTOR a good example of this.
The Central WAYF.

Attribute Usage
Recommended Core Set of Attributes:
eduPersonScopedAffiliation (member@jisc.ac.uk).
eduPersonTargetedID (persistent but pseudonymous).
eduPersonPrincipleName (consistent name across multiple identity providers).
eduPersonEntitlement (catch-all entitlements).
Recommendations on how to generate.
Well described in the documentation.
Could be a session by itself!
Get advice from existing users via the mailing lists.
Be aware of the implications of personal data publication.

Recent Issues
How to express Scoped Affiliation for people with multiple roles:
Can be multi-valued (i.e. student and staff and member).
Use Attribute Release Policy to manage what is released!
Where can I find a good up-to-date Shibboleth installation guide:
https://spaces.internet2.edu/display/SHIB/InstallingShibboleth .
What ‘logs’ do I have to keep to meet the requirements of section 6?
Basically, enough to be able to provide enough ‘reasonable assistance’ to associating an infraction with a named user.
Standard logs provided by Shibboleth software are more than accurate.
What attributes do the Federation Gateways use?
Athens to Shibboleth: eduPersonScopedAffiliation and eduPersonTargetedID.
Shibboleth to Athens: eduPersonTargetedID and eduPersonEntitlement (optional).
Anyone using Shibboleth for real?
Yes!
Can one institution have several different management domains?
Yes, so for example MIMAS can be registered as a separate entity within the University of Manchester membership to cover the legal and practical requirements.

Support
I know nothing about this area of work at all:
Try the upcoming basic skills workshops to be provided by Netskills covering SAML, Java and the real basics to get a developer up-to-speed in this area.
I need help installing this Shibboleth thing:
Installation guides on Shibboleth Wiki: https://spaces.internet2.edu/display/SHIB/WebHome .
Shib Common Errors: https://spaces.internet2.edu/display/SHIB/CommonErrors .
JISC website: www.jisc.ac.uk/federation .
I need help with meeting the recommendations of the UK federation:
Helpdesk support available: [email_address] .
Community advice available: [email_address] .
Contact your outsourced Identity Provider.

Technical Requirements of the UK Access Management Federation

by JISC.AM on May 31, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 2

Statistics

Technical Requirements of the UK Access Management Federation — Presentation Transcript