1 / 24

Athens/Shibboleth Integration

Athens/Shibboleth Integration. David Orrell, Technical Architect. Core Middleware Programme Meeting, Loughbrough , 16-17 May 2005. Overview. Intro: What does project consist of? Shibboleth-Athens gateway SAML-Athens gateway Demonstration AthensIM Athens-Shibboleth gateway Roadmap.

mandel
Télécharger la présentation

Athens/Shibboleth Integration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Athens/Shibboleth Integration David Orrell, Technical Architect. Core Middleware Programme Meeting, Loughbrough, 16-17 May 2005.

  2. Overview • Intro: What does project consist of? • Shibboleth-Athens gateway • SAML-Athens gateway • Demonstration • AthensIM • Athens-Shibboleth gateway • Roadmap

  3. Project components • Roadmap set out in Athens ‘Next Generation’ whitepaper, published in September 2004 http://www.athensams.net/shibboleth/athens_ng_scoping_1.0.pdf • Shibboleth-Athens gateway • Shibboleth IdPs -> Athens Service Providers • SAML-Athens gateway • SAML-compliant IdPs -> Athens Service Providers • Athens Identity Manager (AthensIM) • Fully Shibboleth 1.2 compatible IdP • Athens-Shibboleth gateway • Athens Service -> Shibboleth IdPs

  4. Athens Federation Service Provider A Athens usernames (Classic Athens) Organisation A Digital Resource Registration Trust Policies Local usernames (AthensDA) Organisation B SAML gateway Digital Resource Localusernames (SAML/Shibboleth) Service Provider B Organisation C What does this look like? Meta- searching Portal (eg. MyAthens)

  5. Shibboleth to Athens • Goal is to allow Shibboleth IdPs to connect to existing Athens Service Providers • Give Shibboleth IdPs access to a wide range of currently available resources • No change required for Service Providers who have implemented Athens • Athens becomes a Shibboleth Service Provider in its own right

  6. How does it work? • Shibboleth IdP is treated as an entirely devolved identity space from conventional Athens • Shibboleth auth occurs between IdP and Athens gateway • Athens requests attributes for user from Shibboleth IdP • Athens infrastructure behaves as a Shibboleth 1.2 Service Provider • attributes used to establish Athens session • attributes may be passed to Athens DSPs

  7. Resource Athens • WAYF • organisations • access policy Shibboleth protocol What does this look like? Organisation - Shibboleth IdP Athens Agent - usernames - attributes

  8. Attributes • Attributes can be used to assist authorisation • Attributes passed from IdP to Athens are held within the users Athens session • destroyed when session is closed or expired • MAY be passed to DSPs, subject to ARP • Athens provides consistent set of attributes • aids compatibility with Athens resources • eg. organisation identifier, name

  9. Authorisation • Athens resources MAY authorise by: • Athens resource attribute (cf. eduPersonEntitlement) • users own attributes • link to customer database • Gateway supports two methods for allocating Athens resources • default set of resources for organisation (does not require special attributes) • permission set(s) passed to Athens via attributes (maps user to role in Athens) • Desired policy is defined at time of registration

  10. Persistent identifiers • The gateway does not require a persistent identifier to be passed to Athens… • users can remain fully anonymous within Athens • …BUT Service Providers probably do! • If a persistent ID is not passed: • requests from Service Providers for persistent identifiers will fail • read/write requests on a users personal profile will also fail • Persistent identifiers can be passed as an attribute to Athens • eg. eduPersonTargetedID

  11. Federations • Organisations wishing to use gateway will probably already use Athens • have agreed to T&Cs for usage of the Athens service • is current requirement for Athens • Connection to the gateway for production use will require strict compliance with the T&Cs and security policy • membership of the ‘Athens UK Federation’ • organisations will be listed in the Athens WAYF and membership lists • Organisations wishing to evaluate and test the service may join the ‘Athens Touchstone Federation’ • can only gain access to test resources through the gateway • minimal T&Cs • access to own WAYF

  12. Registration • Need to register in order to use gateway: • HS/AA URLs • Handle Assertion signing cert must be securely registered • Choose authorisation policy • Nominate attribute to use as persistent ID • May upload CSR requests to Athens CA • Athens requires that AA server cert is signed by a recognised root CA, currently • Thawte Server CA • Verisign Class 3 CA • GlobalSign Root CA • Athens CA

  13. SAML to Athens gateway • Principle is exactly the same as Shibboleth gateway • Athens supports assertions via SAML Artifact or POST profiles • Attribute, authorisation and registration requirements are exactly the same as with Shibboleth • Proven to work with Novell iChain 2.3 • integration document available • ‘out of the box’ solution • supports both LAA and HDD mode (cf. Athens DA) • Available for trial now

  14. Demonstration • Demo of Shibboleth-Athens demo available at: • http://demo1.athensams.net • Can do demo of iChain-Athens connection on request

  15. Athens Identity Manager (AthensIM) • What is it? • SAML identity provider supporting the Shibboleth profile • Shibboleth 1.2 compatible • 100% Java • GPL licensed • What does it require? • same requirements as Shibboleth software • servlet container + Apache/IIS (optional) • SSO and attribute repository • works with Jetty 4.2.x, Tomcat 4.x/5.x

  16. AthensIM (2) • Why have Eduserv developed it? • Ground-up implementation of SAML IdP based on new architecture • Designed to be clean to configure and easy to support • Can be downloaded with pre-configured servlet container • Full and detailed documentation and integration guide • Provides greater choice for organisations implementing a Shibboleth-compatible IdP • Designed with extensibility in mind, especially addition of configuration and install GUIs

  17. What does AthensIM offer? • Uses a flexible attribute processing chain • Attribute requests pass through chain to retrieve, manipulate and release attributes • Conceptually easy to understand • Very extendable • Very flexible • Full support for multiple Federations • Federations can be separated functionally and conceptually

  18. Extensibility • AthensIM comes with 10 attribute processors • support for LDAP, SQL and XML attribute stores • targeted ID generator • name and values may be mapped based on rules • separate rule-sets can be applied to different Service Providers or users • attributes may be released on a per-provider or per-role basis • …pluggable API so very easy to write your own!

  19. Support • Integration support is available for JISC-funded organisations and projects • AthensIM@eduserv.org.uk • Can be downloaded from • http://www.athensams.net/shibboleth/AthensIM

  20. Athens-Shibboleth Gateway • Reverse of what we’ve previously talked about! • allows Athens users to connect to Shibboleth Service Providers • Athens behaves as a Shibboleth IdP • Attributes delivered via a Shibboleth attribute query rather than via Athens Agent

  21. What does this look like? Resource Organisation Athens • organisations • usernames • access policy - user registry Shib. protocol Shibboleth IdP

  22. How will this work? • Athens will act as an attribute store, SSO, and Shibboleth compatible IdP • Integration of production system will be seemless • Authentication point will detect type of resource user is attempting to access (Shibboleth or Athens) • From users point of view, authentication to Shibboleth resource will not look any different from existing Athens resource

  23. Availability • Service will be made available in two stages • Initial trial service will be based on Shibboleth 1.2 protocol • Will NOT be production service • Will be fully functional and suitable for testing and evaluation • Production service will be available at the same time as the next major release of the Athens Agent (v4.0) • The core Athens service, including Agent will have full SAML support (inc. assertion generation) • Will have Shibboleth compatibility mode • Will have ARP management interfaces • Will be maintained to current Athens service levels • Will run on geographically dispersed infrastructure, redundancy, load balanced

  24. Development roadmap 2005 2005 2006 May June …. Sep …. Q4 Shibboleth- Athens gateway launched Classic Athens to Shibboleth Gateway (trial) SAML-Athens gateway launched (trial) Attribute release policy interfaces for central Athens Agent version 4 release Classic Athens To Shibboleth Gateway launched

More Related