An Infocard-based proposal for unified SSO to eduroam Enrique de la Hoz, Antonio García, Diego López, Samuel Muñoz University of Alcala (Spain), RedIRIS (Spain) TNC2009, Málaga (Spain), June 9 th 2009
Eduroam and SSO Eduroam provides us with wireless connectivity in educational institutions all along Europe and APAN area Just needing your home institution credentials, open your laptop and you are online One question has been posed by previous work (DAMe project): What if we (re)use those credentials to provide other services than wireless access The goal would be to achieve real SSO: just open you laptop and enjoy any service (any of the service you are allowed to employ, of course) Bring together two (con)federations efforts: Eduroam Edugain Add other logos here if needed
Why? What? Where? Once user gets into eduroam, we have that user authenticated As long as she remains in eduroam, we know who she is. First Idea: We could employ that info to avoid further user logins Problem: Eduroam is L2/L3, most of the services we want to work are in upper layers Let s provide the user with some credentials on sucessful eduroam access Second idea: Let Information Cards be that credential
Information Cards Artifact with an unique identifier from an identity provider that users can employ to visualize their digital relationship with the identity provider in user interfaces and request security tokens with claims from the identity provider. An Information Card is a XML document that can be used as an artifact to get security tokens containing the value of the requested claims Token agnostic: OpenID SAML1.1 Claims-based application Build upon WS-* protocols
Information Cards meet eduroam Well, that seems cool, but What does this have to do with eduroam? Proposal: Join both worlds Associate an Information Card with an eduroam session Use case: User opens his laptop Connects to eduroam On sucessful eduroam connection, she receives an Information Card (from now on, eduroam Information Card ) User can browse services and access them employing eduroam Information Card As soon as she leaves eduroam, the Information Card is no longer valid
Eduroam That sounds great, just login to eduroam and you are done! Some caveats: Infocard is not a real SSO technology, each time you want to use the Information Card, you need to authenticate against the STS To get rid of passwords, we could use etiher X.509 certificates or a selfissued Information Card We decided to use self-issued information cards This way, there is no need for any password further than the one used to access eduroam
Proposal We need to add additional info to RADIUS dialogue: We decided to use PEAP (PEAPv0/EAP-MSCHAPv2): User needs to send the cardid of the self-issued card, she wants to employ to back the eduroam Infocard RADIUS response must include the eduroam Information Card Newly defined EAP-TLV: (the SMH TLV) Request: it will contain selfissued card id On sucessful login, it will contain a one-time time-limited URL where the eduroam Information Card can be downloaded
Proposal (II) SMH EAP-TLV: SMH : Samuel Muñoz Hidalgo (developer) Request: it will contain selfissued card id On sucessful login, it will contain a one-time time-limited URL to download the Information Card
Proposal (III) Radius Server SimpleSAMLphp User Infocard User Success Authenticated with Generation AuthenticationInfoCard Infocard Retrieval Access to federated services
Prototype There s Magic everywhere! Some supplicant-identity selector integration is required Supplicant must be able to retrieve information about which selfissued card, the user wants to employ Identity selector must import the card after successful login FreeRADIUS is employed as RADIUS server: A perl module is in charge of most of the work Minor modifications to existing freeradius Code Module for simplesamlphp: STS functionality Card generation RADIUS server dialogue
Demo http://it.aut.uah.es/enrique/research/demo.html
Protocol Flow Step 1: User decides to join eduroam Supplicant-selector integration User chooses a self-issued card Not only user credentials are sent, but also the additional infocard information is sent as an EAP-TLV. Step 2: RADIUS Server verifies user credentials (user/password) as usual Step 3: Once user credential get verified, RADIUS server contacts STS to get an eduroam infocard TLS connection Inside the TLS connection, an Infocard request containing the self-issued card ID, user name and a timestamp is sent ciphered using AES based on a pre-shared key STS sends back an one-time URL
Protocol Flow Step 4: RADIUS Server sends to the client an EAP-TLV containing the onetime URL with the success PEAP message. Step 5: Supplicant recieves the message, and downloads the eduroam Infocard. Eduroam Infocard gets imported into the selector. Step 6: User accesses a service employing the eduroam Infocard As soon as user leaves eduroam, the STS will no longer be issuing tokens.
Acknowledgments Samuel Muñoz Hidalgo The work has been supported by the Spanish Ministry of Education and Science grant TIN2008-06739-C04-04 and RedIRIS
Future work Open1x Moving to Radiator Handling accounting Info