1 / 32

GN2 JRA5: Roaming and Authorisation, year 2 results and year 3 plans

GN2 JRA5: Roaming and Authorisation, year 2 results and year 3 plans. Jürgen Rauschenbach (DFN), Diego Lopez (RedIRIS), JRA5 team DICE meeting 11/07/06. Tasks resulting from JRA5 visions (reminder).

beck
Download Presentation

GN2 JRA5: Roaming and Authorisation, year 2 results and year 3 plans

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. GN2 JRA5: Roaming and Authorisation, year 2 results and year 3 plans Jürgen Rauschenbach (DFN), Diego Lopez (RedIRIS), JRA5 team DICE meeting 11/07/06

  2. Tasks resulting from JRA5 visions (reminder) • JRA5 builds a European Roaming Infrastructure(eduroam-ng) taking into account existing experience from the roaming area and provides a first (simple, but operational) federation example • JRA5 will pilot the federated support for existent Authentication and Authorisation Infrastructures for Research and Education, this will be called eduGAIN • In some countries federated AAIs are already available, eduGAIN will be able to cooperate with them (Shibboleth, PAPI, FEIDE, A-Select) • JRA5 enables AA access needed in the GÉANT partner countries and in other GN2 activities (JRA1 for now) • Development of an universal single sign-on architecture • Integration of advanced technologies into the 3 main work items

  3. Achievements of the first 2 project years in work item 1 • Deliverables • “Glossary of Terms” DJ5.1.1, a terminology document • “Roaming Requirements document” DJ5.1.2; security, standardisation and operational requirements • “legislation overview” for roaming DJ5.1.3,1 part 1 • “eduroam confederation policy” DJ5.1.3,2(review procedure started 17/03/06, extended EXEC review just passed) • Roaming architecture DJ5.1.4(1st part of review done) • Inter-NREN roaming infrastructure and service support description (cookbook 1st version)DJ5.1.5,1(ToC prepared, material mostly available, last roaming document in year 2)

  4. Achievements of the first 2 project years in work item 2 • Deliverables and internal documents • “AAI Requirements document” DJ5.2.1 (February 05) • “AAI architecture document” DJ5.2.2 (October 05) • “eduGAIN Profiles and Implementation Guidelines, internal document, Spring 2006 • “AAI architecture document” DJ5.2.2bis (internal document based on the experiences/corrections during the implementation work, available on request, May 2006) • “AAI Best practise document (cookbook v1)“ DJ5.2.3 (exists as an almost complete draft, work on-going on the guideline part)

  5. Achievements of the first 2 project years in work item 3 • Goal: integrate eduroam and eduGAIN for logging in once for both network and applications • Deliverables and internal documents • “SSO Requirements document” DJ5.3.1 - first draft available • Preparation of CPT for DAMe (Murcia, Stuttgart) – approval informally (signing procedure started) • “Survey of possible solutions for universal SSO”, MJ5.3.2 - shifted to y3 and converted to a milestone • Universal SSO Architecture (new DJ5.3.2) planned for month 32 (March 07)

  6. Eduroam (from 1st TWS) • Providing roaming network access at higher education and research institutions • Developed by TERENA taskforce on mobility (TF-Mobility) initially • First pilot service started begin of 2004 • JRA5 will transform the pilot service into a full service by: • Creating the neccesary policies and governance bodies • Making the infrastructure more robust

  7. European eduroam confederation policy • The policy document set the rules for the European participants (rules between different regional confederations like AsiaPacific or NorthAmerica not included, will be negotiated when the regional policy is settled) • The policy was developed in JRA5, but also discussed in the eduroam community (TF Mobility meetings and mailing list) • We tried to find the right level of abstraction for the confederation, more specific rules are listed in the blueprint for a federation policy (appendix) • The document is also setting the organisational framework for the confederation and the policy authority.

  8. Connect. Communicate. Collaborate Eduroam organisational structure

  9. Technology: bypassing the hierarchy overhead? • AA traffic goes through all intermediate entries • All links are peer-to-peer agreements / static routes / p2p secure • DIAMETER? DNSsec? RadSec? Work on-going in Telematica Instituut/JRA5 partners

  10. eduroam Architecture alternatives • RadSec (OSC, modification of the RADIUS protocol) • Uses TCP/SCTP instead of UDP • TLS tunnels used between servers: authentication is based on certificates instead on IP addresses, RADIUS packet transported in the tunnel (encrypted), no shared secrets needed • Experimental work done (and integration into pilot planned with 4 partners initially) • Dynamic peer discovery in beta state (will be exploited later) • Not a standard solution (yet), not all RADIUS implementations for now, but good signals from FreeRadius

  11. eduroam architecture alternatives (2) • DIAMETER (RFC 3588) • Problem: no DIAMETER “quality” implementation so far • DAMe will use openDIAMETER and provide the needed transfer agents to integrate into the RADIUS infrastructure • Diameter support for Radiator now available (not yet tested) • RADIUS/DNSSec • Look-up through secure DNS (not very much in use) • Dedicated roaming domain secure DNS tree needed

  12. RadSec and the IETF • Proposal to write an I-D on RadSec, discussed with IETF wg radext activists and AD • Charter says: no new transport, no new security for RADIUS -> RadSec is not in-line with the official Diameter support policy • Support for the I-D from Mike McCauley (OSC) and Alan DeKok (NitroOS9) granted • Aboba: 2 interoperable implementations would be very helpful for the procedure (Radiator, FreeRADIUS) • Integration into eduroam service planned

  13. The AAI Scenario within GN2 • We started from • Scattered AAI (pilot) implementations in the EU and abroad • The basic idea of federating them, preserving hard-won achievements • So we decided to provide the possibility for • Building the infrastructure on top of existing AAIs • Dynamically locating components • Establishing loose and dynamic trust links • Allowing for both centralized and de-centralized connections

  14. eduGAIN Concepts • Confederations and dynamic trust establishment • A confederation is a loosely-coupled set of cooperating identity federations • Identity management and authentication-authorisation must be properly handled by the participating federations • Trust must be dynamically established • Members of a participant federation do not know in advance about members in the other federations • Federations are loosely coupled by the confederation

  15. The eduGAIN Model • Use a set of interconnection points (Bridging Element, BE) at each federation • Announce BE metadata through the FPP (Federation Peering Point) • Distribute these metadata through the Metadata Service (MDS) • Metadata is retrieved through the eduGAINMetaQuery API and delivered to the requesting BE • BEs exchange data using the eduGAIN SAML-based profiles • Interactions are based upon the eduGAIN trust model

  16. The eduGAIN Components • Bridging Elements (BE) • Interconnection points • Federation-wide (LFA) or distributed (LA) • Federation Peering Point (FPP) • Able to announce BE metadata • The Metadata Service (MDS) • Publishing interface (to FPPs) • Querying interface (to BEs)

  17. Connect. Communicate. Collaborate The eduGAIN Model Metadata Query MDS Metadata Publish Metadata Publish R-FPP H-FPP R-BE H-BE AA Interaction AA Interaction AA Interaction Resource(s) Id Repository(ies)

  18. Component Identifiers • eduGAIN operations strongly depend on having unique, structured and well-defined component identifiers • Based on URNs delegated by the eduGAIN registry to the participating federation • Identifiers establish the kind of component they apply to by means of normalized prefixes • Identifiers follow the hierarchy of the trust establishing process • Including the identifiers of the federation (and BE) the component is using to connect to eduGAIN

  19. Some identifier examples • A typical MDS server identifier urn:geant:edugain:component:mds:galaxian | COMMON PREFIX |TYPE|CONFEDERATION| • A typical FPP identifier urn:geant:edugain:component:fpp:starfleet | COMMON PREFIX |TYPE|FEDERATION| • A typical BE identifier urn:geant:edugain:component:be:starfleet:enterprise | COMMON PREFIX |TYPE|FEDERATION| IDENT |

  20. eduGAIN Operations • Defined in abstract terms, following the SOA paradigm • Metadata Service (MDS) • Authentication Service (AuthN) • Attribute Exchange Service (Attr) • Authorisation Service (AuthZ) • Formally defined parameters for each operation • Bindings defined for SAML 1.1 and part of SAML 2.0 • SAML 2.0 over REST for MDS • SAML 1.1 over SOAP (and REST in WebSSO) for the others • Plans for evolving these bindings as required • Authentication assertions and attribute exchange mechanisms are designed to be Shibboleth 1.x compatible

  21. Connect. Communicate. Collaborate A general model for eduGAIN interactions <samlp:Request . . . RequestID=”e70c3e9e6…” IssueInstant=“2006-06…”> . . . </samlp:Request> <samlp:Response . . . ResponseID=”092e50a08…” InResponseTo=“e70c3e9e…”> . . . </samlp:Response> TLS Channel(s) Requester Responder Resource Id Repository

  22. eduGAIN Trust Fabric • Based on a PKI • Validation procedures include • Normal certificate validation • Trust path evaluation, signatures, revocation,… • Peer identification • Certificates hold the component identifier • It must match the appropriate metadata • Applicable to • TLS connections between components • Two-way validation is mandatory • Verification of signed XML assertions

  23. eduGAIN API Structure • The eduGAIN APIs are the common libraries for all eduGAIN components • Direct implementation of the eduGAIN service definition • And also available to local requesters and responders • Building blocks: • eduGAINBase: Adapt the abstract service definition plus specific profile-based access points • eduGAINMetaQuery: Queries to the Metadata Service • eduGAINMetaPub: Publication at the Metadata Service • eduGAINVal: Validation procedures

  24. Connect. Communicate. Collaborate A Layered Model for Implementation Component logic eduGAINBase Profile Access eduGAINBase + eduGAINVal + eduGAINMeta SAML library SOAP/TLS/XMLSig libraries

  25. eduGAIN Profiles • Define the precise exchange of messages and the processing rules for these messages in particular use cases • Two profiles defined so far • Web SSO (Shibboleth compatible) • Automated client (no human interaction) • Others envisaged • Extended Web SSO (allowing the send of POST data) • Non-web applications (based on Web SSO) • eduGAIN usage from roaming clients (DAMe)

  26. eduGAIN WebSSO • Intended to connect existing Web-based AAIs • And to experiment with the whole eduGAIN model • Based on HTTP redirects • Making use of the user’s browser • Fully compatible with Shibboleth 1.3 • The R-BE redirects the user’s browser to the H-BE • Parameters go in the URL using a GET method • The H-BE makes the user’s browser send a SAML response • By means of a POST operation back to the R-BE

  27. Automated client • Customized to the needs of perfSONAR (but can be reused in other cases later on), described in the perfSonar service specification • Not yet implemented, and still discussions on details • Client will provide a certificate for authentication to the H-BE and gets a SubjectHandle for further AuthZ needs • GIdP will be useful • Discussion to use SASL-CA for the automated client

  28. Where We Are • Implementing the eduGAIN APIs (July target date) • Polishing profiles • Through interaction with user activities • Preparing the first version of a cookbook • Deployment and component implementation guidelines • First pilot to be run around 4th quarter of this year • Establishing links with other potential user communities beyond the GN2 project • Policy for eduGAIN will follow eduroam policy

  29. Y3 plus 6 months plans • Work item 1: Roaming • Further Eduroam service preparation • Policy installation • Preparation and establishment of a SA (and a service group later on to take over after GN2) • Defining tasks and installation of the eduroam operational team • Service start planned for policy approval + 9 months • Monitoring and diagnose tools development • RadSec testing and integration • On-going evaluation of other alternatives (openDiameter, other implementations: DJ5.1.5,2 cookbook v2, month 32) • Integration of DAMe results and further evaluation of the architecture DJ5.1.6, month 37)

  30. Y3 plus 6 months plans (2) • Work item 2: AAI • Stabilising eduGAIN basic elements and interoperation in an eduGAIN testbed • BE specification and implementation (internal report) • eduGAIN testbed with (established) local AAIs (Shibboleth, PAPI, A-Select, FEIDE-LA) and Guidelines document (cookbook v2): DJ5.2.3,2, month 28 • Provisioning of the automated client profile in eduGAIN and integration with perfSonar • Interoperation with GIdP • Establishing links with other potential user communities beyond the GN2 project (Lobster, Grid) • eduGAIN policy • integrate roaming with the European AAI eduGAIN

  31. Y3 plus 6 months plans (3) • Work item 3: SSO • Development of the universal SSO architecture (DJ5.3.2, month 34) • Integration of DAMe results (final report will be a JRA5 deliverable: DJ5.3.3, month 40) • Evaluation of available solutions including DAMe, SSO final report DJ5.3.4 in month 46) • Work item 4: Integration of advanced technologies • Defining of the advanced technologies to be integrated into work item 1 to 3: deliverable DJ5.4.1, month 30

  32. Questions please ?

More Related