220 likes | 360 Views
AAI scenario: How AutoBAHN system will use the eduGAIN federation for Authentication and Authorization. Simon Muyal, simon@renater.fr Victor Reijs, victor.reijs@heanet.ie TNC2007 – TERENA Technical Workshop Lyngby, 20 May 2007. Agenda. AutoBAHN service overview…
E N D
AAI scenario: How AutoBAHN system will use the eduGAIN federation for Authentication and Authorization Simon Muyal, simon@renater.fr Victor Reijs, victor.reijs@heanet.ie TNC2007 – TERENA Technical Workshop Lyngby, 20 May 2007
Agenda • AutoBAHN service overview… • Authentication and Authorization Infrastructure… • Overview • AA Scenario • Home domain’s User AuthNAutomated & Human user • Inter-domain AuthR • Policy module and attributes • Progress…
AutoBAHN service overview • AutoBAHN is a research activity for engineering, automating and streamlining the inter-domain setup of guaranteed capacity (Gbit/s) end-to-end paths • AutoBAHN = Joint Research Activity 3 of the GN2 project • GN2 is an EC-funded Integrated Infrastructure Initiative (I3) project, with all NRENs as partners (DANTE: coordinator) • GN2 includes: • Networking Activities (NAs) (Human networks) • Service Activities (SAs) (deployment of GÉANT2 with focus on services) • Joint Research Activities (JRAs) (applied technological research)
Multi-domain environment • Multi-technology, multi-disciplinary environment • Control and provisioning has to be distributed • Business-layer related interactions include AA, policies, advance reservations, etc. • Security and control of intra-domain resources must be safeguarded
(1) (6) (4) (5) (8) (10) (3) Inter-domain path-finding (2) (7) (9) A distributed approach Linking domain Destination domain Home & Source domain
AutoBAHN processes • Topology updating processA regular update of the inter-domain abstract topology model • BoD requestA path request from an automated or human user • PathfindingFinding a path through the abstract topology model • Resource scheduling processCheck feasibility of the found path in a chained way and if feasible to make path, schedule the resource. • Signaling processAt the right moment signal the domains to make the path
Agenda • AutoBAHN service overview… • AAI in AutoBAHN… • Overview • AA Scenario • Home domain’s User AuthNAutomated & Human user • Inter-domain AuthR • Policy module and attributes • Progress…
Overview • Based on the work made by another GN2 project research activity (GN2-JRA5) • EduGAIN, a federator of already established AAIs all over European countries for inter-domain services • A chained-solution is adopted: • A user is authenticated and his/her BoD request is authorized successively in each domain on the path where bandwidth should be scheduled. • The scheduled resource are enabled in each domain by the Domain Manager (DM) only after AA
AutoBAHN interactions with AAI • Home domain’s user AuthNInteraction with the local AAI to authenticate the user and retrieve his/her/its attributes • WebServices WS communication (e.g. IDMs and DMs)Existing trust between IDMs and between IDM-DMUsing X.509 certificates signed by eduGAIN (using ssl) • Inter module communications; no AAI needed 1 2 2 2 2 2
AAI and the AutoBAHN processes • Topology updating processWS communication (between IDMs and IDM-DM)interaction 2 • BoD requestCommunication with automated or human user: interaction 1 • PathfindingInter module communication (IDM): interaction 3 • Resource scheduling processWS communication (between IDMs and IDM-DM)interaction 2 • Signaling processWS communication (between IDMs and IDM-DM)interaction 2
Home domain’s user AuthN • An eduGAIN filter intercepts the user requests and interact with the local AAI • Two possible user cases: • An automated user makes a BoD request • WebServices are used for communication between the automated user and AutoBAHN application (IDM) • Automated user has certificate: The automated user can directly send the AuthN information (no interaction needed for a login + AuthN information like in human user case) • A human user makes a BoD request via a web portal • The user is redirected to its local AAI using http redirections • AuthR (after AuthN) is common for both user cases.
User Access Module & other modules User Access Module & other modules AAI/policy Module AAI/policy Module JRA3 block eduGAIN block AAI local block Home domain’s user AuthNAutomated user Step 1’ Step 2’ eduGAIN filter eduGAIN filter 1’ User User 5-6: The filter sends the AuthN response and the user replies sending the BoD request to the IDM 5’ 6’ certificate certificate JRA3 DB JRA3 DB 2’ JRA3 IDM JRA3 IDM 4’ The local AAI sends the response with the user attributes associated to AutoBAHN Local AAI: IDP/web SSO Shibboleth, PAPI, etc Local AAI: IDP/web SSO Shibboleth, PAPI, etc User sends the AuthN information eduGAIN filter sends this information to the local AAI to authenticate the user 3’ User info User info … … Attributes store & identity provider Attributes store & identity provider
User Access Module & other modules eduGAIN filter eduGAIN filter User User 1 User Access Module & other modules AAI/policy Module JRA3 DB 2, 3 JRA3 DB AAI/policy Module JRA3 IDM JRA3 IDM 4 5 HTTP Redirect: eduGAIN filter redirects the user to its local AAI Local AAI: IDP/web SSO Shibboleth, PAPI, etc Local AAI: IDP/web SSO Shibboleth, PAPI, etc User AuthN in its local AAI 6 JRA3 block User info eduGAIN block … AAI local block Attributes store & identity provider Home domain’s user AuthNHuman user Step 1 Step 2
User Access Module & other modules User Access Module & other modules AAI/policy Module AAI/policy Module Home domain’s user AuthNHuman user Step 3 Step 4 eduGAIN filter eduGAIN filter User User 8 9 The IDM sends the BoD request and the user fills in the parameters JRA3 DB JRA3 DB JRA3 IDM JRA3 IDM 7 Local AAI: IDP/web SSO Shibboleth, PAPI, etc Local AAI: IDP/web SSO Shibboleth, PAPI, etc The IDP redirects the user to the JRA3 service The user attributes associated to autoBAHN are also sent User info User info … … Attributes store & identity provider Attributes store & identity provider
User Access Module & other modules AAI/policy Module Home domain AuthR Step A Step B eduGAIN filter eduGAIN filter User User Access Module & other modules The policy module retrieves the rules in the JRA3 DB and compare it to the BoD request The BoD request is sent to the policy module and the attributes are retrieved 15,16 18 10 JRA3 DB JRA3 DB AAI/policy Module JRA3 IDM 11 17 14 JRA3 IDM 12 13 Local AAI: IDP/web SSO Shibboleth, PAPI, etc Local AAI: IDP/web SSO Shibboleth, PAPI, etc User info User info … … Attributes store & identity provider Attributes store & identity provider
Inter-domain AuthR Step C eduGAIN module: concatenation BoD params + attributes Existing trust between IDM’s XML X.509 eduGAIN module: extraction of BoD params & attributes eduGAIN filter User BoD Id BoD paramattr User Access Module & other modules User Access Module & other modules 19 20 24 21,22 JRA3 DB JRA3 DB AAI/policy Module AAI/policy Module JRA3 IDM JRA3 IDM 23 Local AAI: IDP/web SSO Shibboleth, PAPI, etc User info … Attributes store & identity provider
User Access Module & other modules User Access Module & other modules 25 31 AAI/policy Module AAI/policy Module 30 26 27,28 JRA3 DB JRA3 DB JRA3 IDM JRA3 IDM 29 JRA3 block eduGAIN block AAI local block Inter-domain AuthR Step D Home & Source domain Linking domain Destination domain eduGAIN filter User User Access Module & other modules 32 JRA3 DB AAI/policy Module JRA3 IDM Local AAI: IDP/web SSO Shibboleth, PAPI, etc User info … Attributes store & identity provider
Policy module and attributes (1/2) • AuthR information is stored in the JRA3 DB • The eduGAIN filter avoids problems of different rule formats stored in local AAIs • Define entries like: jra3.renater.projects.DEISA • Apply rules for these entries: jra3.*.projects.DEISA = 1Gbit/s • Advantages • Granularity and accuracy (if wanted) of rules • Easy maintenance and flexibility • Existing AuthR engines like PERMIS will be used
Policy module and attributes (2/2) • The user attributes which can be used for AuthR are: • Role • Project • Home network domain • NREN • This list can be updated • These attributes are stored in the local AAI • Mapping with BoD information stored in the JRA3 DB to authorize a BoD request • Use of GIdP (GN2 activity) if a local AAI doesn’t exist for the user making the BoD request
Agenda • AutoBAHN service overview… • AAI in AutoBAHN… • Overview • AAI Scenario • Home domain’s User AuthNAutomated & Human user • Inter-domain AuthR • Policy module and attributes • Progress…
Progress • AuthN • Interface: • Automated user: Being implemented by GN2 JRA3. Has to be adapted to eduGAIN filter (certificate). • Human user: Web portal to make BoD request. Implemented by GN2 JRA3 : ~ Q3 2007 • eduGAIN filter for user AuthN: • Automated user: Will be implemented by GN2 JRA5. • Human user: Being implemented by GN2 JRA5. First version ready next month • AuthR • Work started to analyze how to use PERMIS in AutoBAHN