eduroam und andere Themen in GN2-JRA5 - DFN · eduroam und andere Themen in GN2-JRA5 DFNRoaming Workshop Stuttgart 30 November 2006 Jürgen Rauschenbach, DFN-Verein, [email protected]

Connect. Communicate. Collaborate

eduroam und andere Themen inGN2-JRA5

DFNRoaming WorkshopStuttgart30 November 2006Jürgen Rauschenbach, DFN-Verein, [email protected]

Connect. Communicate. CollaborateInhalt• Das GÉANT2 Projekt• JRA5 Visionen• Was sind Föderationen?• eduroam• eduGAIN• uSSO/DAMe

Connect. Communicate. CollaborateGÉANT2 Bestandteile• Die Infrastruktur: www.geant.2.net (Mediacenter, maps)• Das Management: Policy Committee (30 NRENs, Dante, TERENA);

Executive Committee (6 NREN Direktoren); Projektleiter RobertoSabatini (Dante); Technical Committee (AL Leiter, RS, MK)

• Network Activities (1-8)• Service Activities (1-3)• Joint Research Activities

JRA1 – Performance monitoring (perfSONAR)JRA2 – SecurityJRA3 – Bandwidth on DemandJRA4 – Testbed and CBFJRA5 – Roaming and Authorisation


Connect. Communicate. CollaborateProblem and JRA5 vision• How to organise access to resources in the research and

education area (networks, digital documents, computerpower etc) in a sufficiently safe and easy to handle way?

• JRA5 Vision:• To build a roaming infrastructure enabling full mobility of members

of the scientific community in Europe across institutionalcampuses. “open your laptop and be online”

• To build an interoperable authentication and authorisationinfrastructure that will be used all over Europe enabling seamlesssharing of e-science resources.

• To develop and pilot a single sign-on system enabling a log inonce experience for network and application access, even beyondorganisational boundaries.

Connect. Communicate. CollaborateJRA5 participants• Number of partners is 16 (NRENs), Number of participants has grown

to 111 (mailing list), with contributions from around 30 active persons

• Partners are ARNES, CARNet/Srce, CESNET, Dante, DFN, FCCN,GRNET, HEANET, HUNGARNET, ISTF, NORDUnet (CSC, UNI-C,UNINETT, University of Umea), RedIRIS, RESTENA, SURFnet,SWITCH (different involvement in project parts)

• Collaboration/liaison with– many groups: TF-Mobility, TF-EMC2, GN2 activities (JRA1, SA3,

JRA3), international groups like eduroam gwg, SALSA FWNA(Internet2), MACE, TF-NGN, DICE, GGF, eConcertation

– and projects: Akogrimo, EGEE2, Lobster


Connect. Communicate. CollaborateFederations – why?• Federated access to resources is one of the drivers• Synergy effects, joining a federation instead of many

bilateral agreements, purpose based

• Different communities, different needs– Not even talking about international collaboration– Different technical and organisational solutions– Digital libraries, e-learning, Grids as current examples– More to come: Governments, professional associations,

commercial operators,…

• Don’t hold your breath waiting for the Real And Only GlobalFederation

Connect. Communicate. CollaborateFederation ingredients

• Identity management is key!• Agreeing on trust mechanisms (PK technologies,

component Ids)• Aligning on schemas (eduPerson, SCHAC, …)• Reaching applications• Coordinating metadata• SAML for identity data exchange (moving to SAML2)• Policy


Confederations:Federate Federations• Same federating principles applied to federations themselves

– Own policies and technologies applied locally

• Independent management– Identity management, authentication/authorization must be properly

handled by the participating federations and federation participants

• Confederation policy– Linking individual federation policies– Coarser than the linked federation policies

• Trust fabric entangling participants– Through each federation’s fabric– P2P trust must be built dynamically


Connect. Communicate. CollaborateJRA5 current work• eduroam.:

– Preparation of the eduroam service (organisational)– Technical enhancement of the current infrastructure

• eduGAIN:– Implementation of the components of the AAI architecture

according to the specification and creation of test cases– Development of a profile for the specific requirements of GN2

activities (JRA1 based right now)

• uSSO:– Definition of uSSO requirements and provision of SSO concepts

that match these requirements


European eduroamconfederation principles

• Mutual access – no fees

• Authentication at home - Authorisation at visited institution

• 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 (confederation level)

Connect. Communicate. CollaborateNational 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

Connect. Communicate. Collaborateeduroam Hierarchy Connect. Communicate. Collaborate

(virtual) eduroam root

APAN rootEuropean root (America’s root). . . .

.nl

.ac.uk

.dk

. . .

.au

.cn

. . ..edu

.us

. . .

.hr

.es

. . .

Connect. Communicate. CollaborateLimitations• Authentication = authorisation• Hierarchical trust establishment AND hierarchical routing of

access requests• Transitive trust• No dynamic trust establishment• Use of UDP• Use of shared secrets

Connect. Communicate. Collaborateeduroam-ng

• After evaluating Diameter, RadSec and DNSROAM:

• Introduction of RadSec (if possible)– 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?


European eduroamparticipants Connect. Communicate. Collaborate

Connect. Communicate. CollaborateJRA5 Transition to Service

• First JRA5 service: European eduroam confederation service(eduGAIN is planned to follow later on)

• Roadmap: service will start in April 2007; the eduroam confederationpolicy document is ready for signing by the NRENs

• “Users” will be the NREN based eduroam federations, providing theservice to end users associated with their member institutions

• The service will be conducted by the eduroamSA, that will establish theeduroam operational team (3-4 persons) for daily service handling.

Connect. Communicate. CollaborateEduroam RADIUS hierarchy Connect. Communicate. Collaborate

.DK .PT

inst-1 inst-2 inst-3 inst-4

[email protected]

confederation level servers(resilient)

federation (NREN) levelservers

institutional levelservers


Connect. Communicate. CollaborateeduGAIN related work done• AAI achievements – exercising the confederation concepts

– Specification of the AAI architecture (DJ5.2.2) – new version end ofNovember

– Implementation of the AAI basic components– Start of implementation of bridging elements (Shibboleth, Liberty

Alliance/FEIDE, PAPI)– Development of the initial 2 profiles (web services, automated

clients)– Support of the GÉANT Identity Provider (GIdP) project– Guidelines for connecting to eduGAIN document “AAI cookbook”

DJ5.2.3,1 available http://www.geant2.net• JRA5 currently focuses on the following AA systems : Shibboleth,

Liberty Alliance, PAPI, A-Select

Connect. Communicate. CollaborateThe 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)– Centralised metadata storage, distributed publishing and trust– Publishing interface (for FPPs and authorised BEs)– Querying interface (for BEs)


��

The eduGAIN Model Connect. Communicate. Collaborate

Id Repository(ies)Resource(s)

MDS

R-FPP

MetadataPublish

R-BE

MetadataQuery

AAInteraction

H-FPP

MetadataPublish

H-BE

AAInteraction

AA Interaction

Connect. Communicate. CollaborateComponent Identifiers

• eduGAIN operations strongly depend on havingunique, structured and well-defined componentidentifiers

• Based on URNs delegated by the eduGAINregistry to the participating federation

• Identifiers establish the kind of component theyapply to by means of normalized prefixes

• Identifiers follow the hierarchy of the trustestablishing process

Connect. Communicate. CollaborateThe (X.509) Trust Fabric• 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


A general model foreduGAIN interactions Connect. Communicate. Collaborate

Requester Responder

Id RepositoryResource

TLS Channel(s)

MDS

TLS Channel

https://mds.geant.net/ ?cid=someURN <EntityDescriptor . . .

entityID= ”urn:geant2:..:responder">. . .<SingleSignOnService . . . Location= “https://responder.dom/” /> . . .

<samlp:Request . . . RequestID=”e70c3e9e6…” IssueInstant=“2006-06…”> . . .</samlp:Request>

<samlp:Response . . . ResponseID=”092e50a08…” InResponseTo=“e70c3e9e…”> . . .</samlp:Response>

←urn:geant2:...:responder

urn:geant2:...:requester→

Connect. Communicate. CollaborateOperation Mapping• Maps the abstract service definition into actual protocols

• Current version is based on SAML 1.1– Profiling the standard to fit abstract parameters

• A SAML 2.0 implementation will be available along thelifetime of the project– The abstract service specification protects components and

applications from these changes

• Authentication assertions and attribute exchangemechanisms are designed to be Shibboleth 1.3 compatible(and Shibboleth 2 in the future)

Connect. Communicate. CollaborateMetadata 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 query string transports data intended to locate the appropriate

home BE (Home Locators)• Hints provided by the user• Contents of certificate extensions

(SubjectInformationAccess)

Connect. Communicate. CollaborateeduGAIN Profiles• Three profiles defined so far

– Web SSO (Shibboleth compatible)– Automated client (no human interaction)– Non-web client (use of SASL-CA)

• Others envisaged– Extended Web SSO (allowing the send of POST data)– eduGAIN usage from roaming clients (DAMe)

• Based on SAML 1.1– Mapping to SAML 2.0 profiles along the transition period


Connect. Communicate. Collaborateeduroam-ng• After evaluating Diameter, RadSec and DNSROAM:

• Introduction of RadSec (if possible)– TCP instead of UDP– TLS between RADIUS-servers instead of shared

secrets– I-D IETF radext wg planned

• Possibly at later stage introduction of DNSROAM– Support for direct peer interaction– How about firewalls / access lists?

• Eventually Diameter?

Connect. Communicate. CollaborateFirst Goal: extNAFirst Goal: Extension ofeduroam Using NAS-SAML Connect. Communicate. Collaborate

Gast

piet@university_b.nl

RADIUS server

University B

RADIUS server

University A

SURFnet

Central RADIUS

Proxy server

Authenticator

(AP or switch) UserDB

UserDB

Supplicant

data

• User mobility controlled byassertions and policies expressedin SAML and XACML

XACML

Policy Decision Point

SAML

Source Attribute Authority

Signaling

Connect. Communicate. CollaborateFirst Goal: extNASecond Goal: eduGAIN asAuthN and AuthR Backend Connect. Communicate. Collaborate

• Link between the AAA servers (now acting as Service Providers) and eduGAIN

Connect. Communicate. CollaborateConclusions/Summary

• eduroam transition to service progressing

• Rollout needs support by participating NRENs

• AAI component implementation almost complete (eduGAIN)

• Initial profiles defined

• Tests with real federations soon

• Forming an eduGAIN confederation by adding a policy to theinfrastructure is on our agenda

• SSO requirements and model under discussion

Documents

eduroam und andere Themen in GN2-JRA5 - DFN · eduroam und andere Themen in GN2-JRA5 DFNRoaming Workshop Stuttgart 30 November 2006 Jürgen Rauschenbach, DFN-Verein, [email protected]