Federation Policy

1,234 views
1,161 views

Published on

This presentation gives an overview of the policy developed for the UK Access Management Federation

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,234
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Federation Policy

  1. 1. Federation Policy Issues The UK Perspective Nicole Harris Programme Manager – JISC
  2. 2. Issues from the UK <ul><li>Experience from the UK highlights the importance of: </li></ul><ul><ul><li>Making the move from a pilot to full service </li></ul></ul><ul><ul><li>Getting it right for your national requirements </li></ul></ul><ul><ul><li>Mapping requirements across the UK educational sector </li></ul></ul><ul><ul><li>Managing ‘outsourced identity providers’ </li></ul></ul><ul><ul><li>Managing ‘outsourced service providers’ </li></ul></ul><ul><ul><li>Not just the Federation and Policies but outreach, assisted take-up, vendor liaison </li></ul></ul>
  3. 3. Moving from SDSS to the UK Access Management Federation UKERNA EDINA National Data Centre Home National Programme Scale Ongoing 3 years Duration Service Project Status UK federation SDSS federation
  4. 4. Differences for Users in Transition from SDSS <ul><li>Very little: </li></ul><ul><ul><li>Metadata recommendations have been preserved </li></ul></ul><ul><ul><li>SDSS team in place to provide second-line support for the foreseeable future </li></ul></ul><ul><ul><li>Communication: pushing people to use SDSS in the interim (don’t wait!) </li></ul></ul><ul><ul><li>Communication: explaining the changeover process </li></ul></ul><ul><ul><li>Formalising: actually signing formal policy documents rather than pilot recommendations can be scary / institutionally difficult </li></ul></ul><ul><ul><li>Athens “gateways” will be live and in service: </li></ul></ul><ul><ul><ul><li>Athens will join the Federation as an outsourced Identity Provider and represent many institutions that have not made the move to full federated access management </li></ul></ul></ul><ul><ul><ul><li>Athens will join the Federation as an outsourced Service Provider and represent many resource owners that have not made the move to full federated access management </li></ul></ul></ul>
  5. 5. Federation Stats: 13 th April 2007 <ul><li>50 MEMBERS. </li></ul><ul><li>113 ENTITIES (two dual in nature): </li></ul><ul><ul><li>51 Identity Providers </li></ul></ul><ul><ul><li>64 Service Providers </li></ul></ul><ul><li>29 ‘Core’ Institutional Members. </li></ul>
  6. 6. Policy Document 1: Rules of Membership <ul><li>The basic contractual framework for trust. </li></ul><ul><li>Covers: </li></ul><ul><ul><li>Definitions </li></ul></ul><ul><ul><li>Rules for all members </li></ul></ul><ul><ul><li>Specific rules for IdPs and SPs </li></ul></ul><ul><ul><li>Data Protection and Privacy </li></ul></ul><ul><ul><li>User Accountability </li></ul></ul><ul><ul><li>Liability </li></ul></ul><ul><ul><li>Audit and Compliance </li></ul></ul><ul><ul><li>Termination </li></ul></ul><ul><ul><li>Membership Cessation </li></ul></ul><ul><ul><li>Changes to Rules </li></ul></ul><ul><ul><li>Dispute Resolution </li></ul></ul>
  7. 7. Policy Document 2:Recommendations for Use of Personal Data <ul><li>Recommendations for use of personal data </li></ul><ul><li>Covers legal requirements – Data Protection Act 1998 </li></ul><ul><li>practical use of attributes: </li></ul><ul><ul><li>eduPersonScopedAffiliaton: represents the least intrusion into the user’s privacy and is likely to be sufficient for many access control decisions. </li></ul></ul><ul><ul><li>eduPersonTargetedID:designed to satisfy applications where the service provider needs to be able to recognise a returning user without revealing real identity. </li></ul></ul><ul><ul><li>“ For most applications a combination of the attributes eduPersonScopedAffiliation and eduPersonTargetedID will be sufficient. A requirement to provide other attributes should be regarded as exceptional by both Identity and Service Providers and will involve considerable additional responsibilities for both.” </li></ul></ul><ul><ul><li>eduPersonPrincipleName comes under the personal data guidelines of DP Act. </li></ul></ul><ul><ul><li>eduPersonEntitlement: may be possible to determine Identity from entitlement so again governed by DP Act. </li></ul></ul>
  8. 8. Policy Document 3: Technical Recommendations for Participants <ul><li>Specifies the technical architecture for Federation and participants. </li></ul><ul><li>Choice of IdP / SP software (UK is neutral but must be SAML compliant and tested by Federation) </li></ul><ul><li>Authentication response profiles </li></ul><ul><li>Metadata processes </li></ul><ul><li>Digital Certificate processes </li></ul><ul><li>‘ Discovery’ processes - to WAYF or not to WAYF </li></ul><ul><li>Attribute usage </li></ul><ul><li>Includes Future Directions for each area of work </li></ul>
  9. 9. UK Federation Required Attributes Used when a specific resource has a specific entitlement condition not covered elsewhere: must be over 21, must have completed foundation course module. eduPersonEntitlement (expressed as an agreed URI) mutually agreed by institution and service Used when a persistent user identifier is required across services. Typically used in for internal institutional services. Real identity can be established from attribute. eduPersonPrincipalName (harrisnv) defined by institution – login name ‘ A persistent user pseudonym’ to allow for service personalisation and usage monitoring across sessions. Not a real world identity. eduPersonTargetedID (r001xf4rg2ss) opaque string defined by institution Establishes user’s relationship with institution – e.g. staff, student, member. Terms as used in JISC Model license. Most authorisation can be done against this attribute. eduPersonScopedAffiliation ( [email_address] ) UK specific controlled vocabulary WHAT THIS REALLY MEANS TECHNICAL ATTRIBUTE NAME
  10. 10. Policy Document 4: Federation Technical Specification and Policy Document 5: Federation Operator Procedures <ul><li>Federation Technical Specification: </li></ul><ul><ul><li>High level document about trust fabrics and how the UK Access Management Federation achieves trust. </li></ul></ul><ul><li>Federation Operator Procedures: </li></ul><ul><ul><li>The procedures actually undertaken by the Federation Operator (UKERNA): </li></ul></ul><ul><ul><ul><li>Enrolment </li></ul></ul></ul><ul><ul><ul><li>CA Qualification </li></ul></ul></ul><ul><ul><ul><li>Support </li></ul></ul></ul><ul><ul><ul><li>Monitoring / Audit </li></ul></ul></ul>
  11. 11. Upcoming…in Policy <ul><li>More practical documents related to baseline Federation such as Identity Provider deployment. </li></ul><ul><li>More advice and policy as developments move to service: </li></ul><ul><ul><li>Levels of assurance </li></ul></ul><ul><ul><li>Virtual organisation support </li></ul></ul><ul><ul><li>Virtual ‘orphanage’ (SDSS already offering TypeKey and ProtectNetwork solutions) </li></ul></ul><ul><ul><li>Detailed policies for outsourced identity providers and outsourced service providers </li></ul></ul>
  12. 12. The Gateways ATHENS INSTITUTION UK ACCESS MANAGEMENT FEDERATION FEDERATED INSTITUTION ATHENS CENTRAL ATHENS PROTECTED RESOURCE FEDERATED RESOURCE IdP Gateway SP Gateway
  13. 13. <ul><li>www.ukfederation.org.uk </li></ul><ul><li>www.jisc.ac.uk/federation.html </li></ul><ul><li>[email_address] </li></ul><ul><li>[email_address] </li></ul>

×