McShibboleth Presentation

Access Management Transition Programme Meeting Technical Birds of a Feather Session

JISC Announcement
In March 2006, JISC formally announced its intention to support federated access management as the preferred access management solution for UK Further and Higher Education
JISC will continue funding the Athens service until July 2008
Athens will be available via a subscription model post July 2008
The UK Access Management Federation will launch in November 2006, with early adopters joining in August 2006
The Federation is a combined venture between JISC and BECTA
All members of the successful pilot federation (SDSS) will be seamlessly moved to the UK Access Management Federation
A full support service will be made available to the JISC community to support the transition to the new service

What is Federated Access Management?
Current Athens service is a centralised service:
Institution provides information about users to Athens (identity information).
Athens brokers both authentication and authorisation on the part of the institution with service providers.
Federated Access Management devolves authentication back to the institution:
Authentication achieved through normal institutional log-on.
Service Providers trust institutions to appropriately authenticate.
Service Providers and institutions exchange information about users to determine what they can access (attributes: staff, student, law).
Same system can be used for internal, external and collaborative access (e-learning partnerships with other institutions, e-portfolios).

Institutional Options
BECOME A FULL MEMBER OF THE FEDERATION USING COMMUNITY SUPPORTED TOOLS
COSTS: Institutional effort to implement software, join federation and enhance institutional directories
BENEFITS: Full institutional control, skilled staff and access management solution for internal, external and collaborative resources
BECOME A FULL MEMBER OF THE FEDERATION USING TOOLS WITH PAID-FOR SUPPORT
COSTS: Cost of support from supplier and institutional effort in liaison with supplier and Federation
BENEFITS: Full support in implementation and access management solution for internal, external and collaborative resources
SUBSCRIBE TO AN ‘OUTSOURCED IDENTITY PROVIDER’ TO WORK THROUGH THE FEDERATION ON YOUR BEHALF (SUCH AS USE OF CLASSIC ATHENS WITH THE GATEWAYS)
COSTS: Subscription costs to external supplier (from July 2008) and internal administration role
BENEFITS: Minimum institutional effort to achieve access to external resources only

The Gateways ATHENS INSTITUTION UK ACCESS MANAGEMENT FEDERATION FEDERATED INSTITUTION ATHENS CENTRAL ATHENS PROTECTED RESOURCE FEDERATED RESOURCE IdP Gateway SP Gateway

The JISC Roadmap

Reviewing Readiness How many institutions will adopt federated access by July 2008? (FE figures: Scotland, Wales and Northern Ireland only)

Technical Background
JISC ‘Institutional Preparedness’ Study (170 institutions):
Directory Services:
66% HE / 69% FE use Active Directory
31% HE / 13% FE use Novell eDirectory
27% HE / 31 % FE use OpenLDAP
Outsourcing / Delegation of Identity Management:
2% of HE / 0% FE outsource directory / identity management
25% HE allow departmental control of identity management
Current use of Athens:
Classic Athens: 57% HE / 78% FE
AthensDA: 35% HE / 7% FE

Strategic Case: Example – Kings College London
VISION STATEMENT: “Using a single password, postgraduate students can access not only King’s own electronic resources but also those of other universities and institutions by co-operative agreements.
VISION STATEMENT: “Provide services which reduce the burden of administration and information management.”
VISION STATEMENT: “Provide services which facilitate scholarly communication, collaboration and research
Federated access management allows not only single sign-on internally using an institutional password, but also allows users to access resources (such as VLEs) at other institutions using that same password (i.e. no need to register elsewhere).
Devolved authentication means that institution do not have to administer Athens accounts and single sign-on reduces the need for libraries to manage people as well as resources.
Federated access management supports the adoption of ‘virtual organisations and key research tools (such as open access repositories) have been ‘federated’.

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!

Costs
Costs associated with adopting federated access management need to be assessed on an institution by institution basis.
Depend on starting point (state of directory services, choice of directory services, use of Athens, size of institution etc. etc.).
Depends on ‘end’ goal (full single sign-on implementation or more lightweight approach).
Use case studies of ‘early adopters’ to judge where you might be – please contact me.
Talk to the early adopters (they are very nice).
NMI-EDIT full Enterprise Directory project example: £250,000 capital, £130,000 recurrent.
Simple adoption of federated access management: £5,000.
Early adopter projects: £50,000. All successful within these constraints.
Athens: no more than 50p per user account for all Athens systems.

Achievability: Skill Set (with thanks to Swish!) Setting up a CVS Repository; Populating (importing) new data;Check out/in. CVS Profiles, bindings and extensions SAML Format and content of XML files ; Namespace (xmlns) definition and use ; XML Schema definitions XML Log4j and log4cpp configuration options ; Analyzing stack traces and locating configuration errors. Java Configuration files: server.xml, workers2.properties, tomcat-users.xml Application WAR deployment ; Use of conf, webapps, WEB-INF and classes directories. Mod_jk use and Tomcat modification to use it ; “ant command” and editing build.properties and build.xml files.Build WAR and dist files. Tomcat Writing simple web pages ; Meaning of every HTTP code ; CSS authoring HTTP and HTML PKI ; Use of the openssl command and every option Trust stores and certificate stores Obtaining certificates, installing them, converting to/from different encoded methods. Building certificate chains. SSL Knowledge of the configuration files for the webserver and being able to correctly specify values for all directives. Virtual host configuration with SSL. Adding modules, building modules Configuring a content management system to host documentation about procedures and configuration file changes. Webserver (Apache, IIS) Security policy management for controlling port use . Where to install applications, configuration files. Syslogd operation, writing startup services, obtaining and inspecting packet dumps, writing scripts to monitor and control multiple log files in many windows and using filtering, sorting and pattern matching to reformat output. Operating System Minimum requirements Skill area

Joining the Federation: Technical Details

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.

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.

McShibboleth Presentation

by JISC.AM on Sep 19, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

McShibboleth Presentation — Presentation Transcript