1. Connect. Communicate. Collaborate 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

2. Connect. Communicate. Collaborate Agenda AutoBAHN service overview… Authentication and Authorization Infrastructure… –Overview –AA Scenario Home domain’s User AuthN Automated & Human user Inter-domain AuthR –Policy module and attributes Progress…

3. Connect. Communicate. Collaborate 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)

4. Connect. Communicate. Collaborate 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

5. Connect. Communicate. Collaborate A distributed approach (1) (2) (4) (5) (6) (7) (3) Inter-domain path-finding (8) (9) (10) Home & Source domain Linking domainDestination domain

6. Connect. Communicate. Collaborate AutoBAHN processes Topology updating process A regular update of the inter-domain abstract topology model BoD request A path request from an automated or human user Pathfinding Finding a path through the abstract topology model Resource scheduling process Check feasibility of the found path in a chained way and if feasible to make path, schedule the resource. Signaling process At the right moment signal the domains to make the path

7. Connect. Communicate. Collaborate Agenda AutoBAHN service overview… AAI in AutoBAHN… –Overview –AA Scenario Home domain’s User AuthN Automated & Human user Inter-domain AuthR –Policy module and attributes Progress…

8. Connect. Communicate. Collaborate 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

9. Connect. Communicate. Collaborate AutoBAHN interactions with AAI 1.Home domain’s user AuthN Interaction with the local AAI to authenticate the user and retrieve his/her/its attributes 2.WebServices WS communication (e.g. IDMs and DMs) Existing trust between IDMs and between IDM-DM Using X.509 certificates signed by eduGAIN (using ssl) 3.Inter module communications; no AAI needed 2 2 2 2 2 1

10. Connect. Communicate. Collaborate AAI and the AutoBAHN processes Topology updating process WS communication (between IDMs and IDM-DM) interaction 2 BoD request Communication with automated or human user: interaction 1 Pathfinding Inter module communication (IDM): interaction 3 Resource scheduling process WS communication (between IDMs and IDM-DM) interaction 2 Signaling process WS communication (between IDMs and IDM-DM) interaction 2

11. Connect. Communicate. Collaborate 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.

12. Connect. Communicate. Collaborate JRA3 block eduGAIN block AAI local block Home domain’s user AuthN Automated user Step 1’Step 2’ User Local AAI: IDP/web SSO Shibboleth, PAPI, etc User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB 1’ User sends the AuthN information eduGAIN filter sends this information to the local AAI to authenticate the user JRA3 IDM 2’ User info … Attributes store & identity provider 3’ certificate User info … Local AAI: IDP/web SSO Shibboleth, PAPI, etc Attributes store & identity provider User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB 4’ The local AAI sends the response with the user attributes associated to AutoBAHN JRA3 IDM User certificate 5’ 6’ 5-6: The filter sends the AuthN response and the user replies sending the BoD request to the IDM

13. Connect. Communicate. Collaborate JRA3 block eduGAIN block AAI local block User Local AAI: IDP/web SSO Shibboleth, PAPI, etc User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB 1 2, 3 HTTP Redirect: eduGAIN filter redirects the user to its local AAI JRA3 IDM User User info … Local AAI: IDP/web SSO Shibboleth, PAPI, etc Attributes store & identity provider User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB 5 6 User AuthN in its local AAI 4 JRA3 IDM Home domain’s user AuthN Human user Step 1Step 2

14. Connect. Communicate. Collaborate User User info … Local AAI: IDP/web SSO Shibboleth, PAPI, etc Attributes store & identity provider User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB 7 The IDP redirects the user to the JRA3 service The user attributes associated to autoBAHN are also sent JRA3 IDM User User info … Local AAI: IDP/web SSO Shibboleth, PAPI, etc Attributes store & identity provider User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB The IDM sends the BoD request and the user fills in the parameters 8 9 JRA3 IDM Home domain’s user AuthN Human user Step 3Step 4

15. Connect. Communicate. Collaborate User User info … Local AAI: IDP/web SSO Shibboleth, PAPI, etc Attributes store & identity provider JRA3 IDM User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB 10 11 1213 14 The BoD request is sent to the policy module and the attributes are retrieved User info … Local AAI: IDP/web SSO Shibboleth, PAPI, etc Attributes store & identity provider JRA3 IDM User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB 15,16 17 The policy module retrieves the rules in the JRA3 DB and compare it to the BoD request 18 Home domain AuthR Step AStep B

16. Connect. Communicate. Collaborate User User info … Local AAI: IDP/web SSO Shibboleth, PAPI, etc Attributes store & identity provider Existing trust between IDM’s XML X.509 User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB eduGAIN module: concatenation BoD params + attributes User Access Module & other modules AAI/policy Module JRA3 DB 19 21,22 20 BoD Id BoD param attr eduGAIN module: extraction of BoD params & attributes 23 JRA3 IDM 24 Inter-domain AuthR Step C

17. Connect. Communicate. Collaborate User User info … Local AAI: IDP/web SSO Shibboleth, PAPI, etc Attributes store & identity provider User Access Module & other modules AAI/policy Module eduGAIN filter JRA3 DB 32 JRA3 IDM User Access Module & other modules AAI/policy Module JRA3 DB 25 31 JRA3 IDM User Access Module & other modules AAI/policy Module JRA3 DB 27,28 26 JRA3 IDM 30 29 Home & Source domain Linking domainDestination domain Inter-domain AuthR Step D JRA3 block eduGAIN block AAI local block

18. Connect. Communicate. Collaborate 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

19. Connect. Communicate. Collaborate 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

20. Connect. Communicate. Collaborate Agenda AutoBAHN service overview… AAI in AutoBAHN… –Overview –AAI Scenario Home domain’s User AuthN Automated & Human user Inter-domain AuthR –Policy module and attributes Progress…

21. Connect. Communicate. Collaborate 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

22. Connect. Communicate. Collaborate Questions?