1 / 42

Federated peering the NREN way: eduGAIN and eduroam

Federated peering the NREN way: eduGAIN and eduroam. Diego R. Lopez (RedIRIS) Klaas Wierenga (SURFnet). Contents. The drivers for (con-)federations (Diego) The eduroam case (Klaas) The eduGAIN case (Diego) The holy grail aka universal single signon aka DAMe (Klaas).

mignon
Télécharger la présentation

Federated peering the NREN way: eduGAIN and eduroam

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. Federated peering the NREN way:eduGAIN and eduroam Diego R. Lopez (RedIRIS) Klaas Wierenga (SURFnet)

  2. Contents • The drivers for (con-)federations (Diego) • The eduroam case (Klaas) • The eduGAIN case (Diego) • The holy grail aka universal single signon aka DAMe (Klaas)

  3. The drivers for con-federations

  4. The eduroam case Confederation avant-la-lettre

  5. The goal of eduroam • “open your laptop and be online” • To build an interoperable, scalable and secure authentication infrastructure that will be used all over the world enabling seamless sharing of network resources

  6. eduroam concepts • Based on reciprocal (free) access • NREN community • Authentication at home • Authorisation at visited institution

  7. eduroam: ubiquitous network access Supplicant Authenticator (AP or switch) RADIUS server University A RADIUS server University B User DB User DB Gast piet@university_b.nl SURFnet Commercial VLAN Employee VLAN Central RADIUS Proxy server Student VLAN • Trust based on RADIUS plus policy documents • 802.1X • (VLAN assigment) signalling data

  8. Connect. Communicate. Collaborate A general model for eduroam interactions Tue Oct 10 00:05:15 2006: DEBUG: Packet dump: *** Received from 145.99.133.194 port 1025 .... Code: Access-Request Identifier: 1 Authentic: k<145><206><152><185><0><0><0><249><26><0><0><208>D<1><16> Attributes: User-Name = "Klaas.Wierenga@guest.showcase.surfnet.nl" NAS-IP-Address = 145.99.133.194 Called-Station-Id = "001217d45bc7" Calling-Station-Id = "0012f0906ccb" NAS-Identifier = "001217d45bc7" NAS-Port = 55 Framed-MTU = 1400 NAS-Port-Type = Wireless-IEEE-802-11 EAP-Message = <2><0><0>-<1>Klaas.Wierenga@guest.showcase.surfnet.nl Message-Authenticator = <27>`-y<208><232><252><177>.<160><230><177>I<218 ><243>\ Tue Oct 10 00:17:32 2006: DEBUG: Handling request with Handler 'TunnelledByTTLS= 1, Realm=/guest.showcase.surfnet.nl/i' Tue Oct 10 00:17:32 2006: DEBUG: Deleting session for Klaas.Wierenga@guest.show case.surfnet.nl, 145.99.133.194, Tue Oct 10 00:17:32 2006: DEBUG: Handling with Radius::AuthFILE: SC-GUEST-ID Tue Oct 10 00:17:32 2006: DEBUG: Reading users file /etc/radiator/db/showcase-gu est-users Tue Oct 10 00:17:32 2006: DEBUG: Radius::AuthFILE looks for match with Klaas.Wie renga@guest.showcase.surfnet.nl [Klaas.Wierenga@guest.showcase.surfnet.nl] Tue Oct 10 00:17:32 2006: DEBUG: Radius::AuthFILE ACCEPT: : Klaas.Wierenga@guest .showcase.surfnet.nl [Klaas.Wierenga@guest.showcase.surfnet.nl] Tue Oct 10 00:17:32 2006: DEBUG: AuthBy FILE result: ACCEPT, Tue Oct 10 00:17:32 2006: DEBUG: Access accepted for Klaas.Wierenga@guest.showca se.surfnet.nl Tue Oct 10 00:17:32 2006: DEBUG: Returned TTLS tunnelled Diameter Packet dump: Code: Access-Accept RADIUS + TLS Channel(s) RADIUS@visited RADIUS@home Resource (AP) Id Repository

  9. Connect. Communicate. Collaborate (virtual) eduroam root . . . . European root APAN root (America’s root) .nl .au .edu . . . .ac.uk . . . . . . .cn .us .dk .hr . . . .es eduroam Hierarchy

  10. eduroam confederations • Regions have their own stage of development and pace • Regions have their own regional policies (with delegation to national federations) • Policies will be aligned as much as possible

  11. The European eduroam policy • Mutual access • Home institutions are/remain responsible for their users abroad • Members are European NRENs • Members guarantee required security levels by their participants • Members promote eduroam in their countries • European eduroam may peer with other regions

  12. National policies • Mutual access • Members are connected institutions • Home institution is/remains responsible for its users behaviour. • Home institution is responsible for proper user management • Home and visited institution must keep sufficient logdata • Appropriate security levels

  13. Limitations • Authentication = authorisation • Hierarchical trust establishment AND hierarchical routing of access requests • Transitive trust • No dynamic trust establishment • Use of UDP • Use of shared secrets

  14. eduroam-ng • After evaluating Diameter, RadSec and DNSROAM: • Introduction of RadSec • TCP instead of UDP • TLS between RADIUS-servers instead of shared secrets • Possibly at later stage introduction of DNSROAM • Support for direct peer interaction • How about firewalls / access lists? • Eventually Diameter?

  15. The eduGAIN case

  16. The Goal of AAI within GN2 • To build an interoperable authentication and authorisation infrastructure that will be used all over Europe enabling seamless sharing of e-science resources • We started from • Scattered AAI (pilot) implementations in the EU and abroad • The basic idea of federating them, preserving hard-won achievements

  17. 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

  18. Dynamic Trust • Provided through three basic elements • The Metadata Service (MDS) • A Public Key Infrastructure (PKI) • A set of naming policies for the eduGAIN components • Because of their very nature, trust links across eduGAIN are weaker than those inside participating federations

  19. 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)

  20. 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)

  21. 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

  22. 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 |

  23. 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

  24. Connect. Communicate. Collaborate eduGAINCA . . . . eduGAINSCA eduGAIN Fed1 CA eduGAIN FedN CA MDS server(s) BE1 BE1 . . . FPP FedA . . . . . . BEN BEN FPP FedZ LFA FedA . . . LFA FedZ eduGAIN CA Hierarchy

  25. 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

  26. 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

  27. Metadata Service • Based on REST interfaces transporting SAML 2.0 metadata • Metadata are published through POST operations • Metadata are retrieved through GET operations • URLs are built as MDSBaseURL/FederationID/entityID?queryString • Using component names • The queryString transports data intended to locate the appropriate home BE (Home Locators) • Usually, coming from hints provided by the user

  28. Mapping between SAML 2 and eduGAIN • EntitiesDescriptor  List <BEMetaData> • EntityDescriptor BEMetaData: • componentID • contactURL • List <IDPInterface> • componentID • contactURL • List <EGAttribute> • List <AAInterface> • componentID • contactURL • List <EGAttribute> • List <HLPatterns> • hlType (eg. homeDomain, urn, authenticationMethod) • matchingAlgorithm (eg. prefix, postfix, exactMatch) • value

  29. General eduGAIN Operation Mapping • Current version is based on SAML 1.1 • Profiling the standard to fit abstract parameters • Component identifiers play their role again • A SAML 2.0 implementation will be available along the lifetime of the project • The abstract service specification protects components and applications from these changes • Authentication assertions and attribute exchange mechanisms are designed to be Shibboleth 1.3 compatible • And Shibboleth 2 in the future

  30. 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

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

  32. 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)

  33. 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

  34. Connect. Communicate. Collaborate 302 H-BE GET FORM + JavaScript + SAML GET/POST POST (SAML) Web SSO in action R-BE H-BE User’s Browser

  35. Implementing WebSSO through eduGAINBase • Two separate classes to provide access to the eduGAIN abstract model • Translating AuthN requests and responses into WebSSO messages • Two adaptor interfaces to connect local federations to eduGAIN • Translating internal requests and responses into their eduGAIN counterparts • Two components (servlets) implementing the BEs • Fully configurable through servlet deployment • A sample for other possible implementations of BEs

  36. Connect. Communicate. Collaborate WebSSO Implementation Details Web SSO

  37. DAMe

  38. Deploying Authorization Mechanisms for Federated Services in eduroam (DAMe) • DAME is a project that builds upon previous TERENA, Internet2, and University of Murcia work: • eduroam, a result of TERENA Mobility Task Force, which defines an inter-NREN roaming architecture based on AAA servers (RADIUS) and the 802.1X standard, • Shibboleth, a widely deployed federation mechanism. • eduGAIN, the AAI of GN2 • NAS-SAML, a network access control approach for AAA environments, developed by the University of Murcia (Spain), based on the SAML (Security Assertion Markup Language) and the XACML (eXtensible Access Control Markup Language) standards.

  39. Supplicant Authenticator (AP or switch) RADIUS server University A RADIUS server University B User DB User DB SURFnet Central RADIUS Proxy server First goal: Extension of eduroam using NAS-SAML Policy Decision Point Source Attribute Authority XACML Gast piet@university_b.nl • User mobility controlled by assertions and policies expressed in SAML and XACML Signaling data SAML

  40. Second goal: Use of eduGAIN as authn and authz backend • Link between the AAA servers (now acting as Service Providers) and the AAI of eduGAIN or Shibboleth.

  41. Third goal: universal single signon • Users will be authenticated once, during the network access control phase • The eduGAIN authentication would be bootstrapped from the NAS-SAML • New method for delivering authentication credentials and new security middleware

  42. Summary and conclusions

More Related