Connect. Communicate. Collaborate Universität Stuttgart A Client Middleware for Token- Based...

Connect. Communicate. Collaborate

Universität Stuttgart

A Client Middleware for Token-Based Unified Single Sign On to eduGAINSascha Neinert, University of Stuttgart

TNC 2008, Bruges, 20.05.2008



Overview

• Single Sign On• unified Single Sign On• eduToken• Token-based uSSO Profile• Conclusion



Single Sign On

• Single Sign On (SSO): authenticate once for access to multiple (web) resources

• SSO in a federated AAI: only one pair of credentials is needed (this is no automated password-entering)

• SSO with eduGAIN: SSO becomes possible in a heterogeneous environment, by building a confederation



Single Sign On

• Advantages:– User friendly, saves time

• Esp. with more secure authentication methods– Higher security: password transmitted only once– Higher security: one password can be remembered, dozens of

them hardly – Phishing protection: the Identity Provider is “known” (URL,

certificate)

• Disadvantages:– Higher risk: one stolen password gives access to many resources



unified Single Sign On

• NEW unified Single Sign On (uSSO): authenticate once for access to network and application resources

• (this) uSSO is built on:– eduroam: federated, secure access to network

resources– eduGAIN: (con-)federated, secure access to web

resources (and other applications “Grid”)



unified Single Sign On Connect. Communicate. Collaborate

eduroam confederation

eduGAIN confederation

Home Domain

Service Domain

Visited Domain

User’s Device(Supplicant +Token Client)

Authentication Authority(RADIUS)

Attribute Authority(Shibboleth,

PAPI, ...)

eduroam

eduGAIN

Network AccessServer (RADIUS)

Access Point(802.1X)

Service Provider(Shibboleth, PAPI, ...)

Network Authentication (RADIUS/EAP/SAML)

Web Authentication and Authorization (HTTPS/SOAP/SAML)




• Advantages of uSSO:– SSO advantages, but extended to the network– WAYF problem can be solved– Usable for non-web resources and services (Grid)– Usable with eduGAIN several web AAI middlewares

(Shibboleth, PAPI – Spain, A-Select – Netherlands, …)

• Disadvantages of uSSO:– Additional (client) middleware needed– Requires eduroam and some AAI




Six steps:

1. Authentication at layer 2 with 802.1x, using eduroam

2. Transport a token over eduroam

3. Put into secure token store on user’s device

4. Get network access (get IP address)

5. Authentication at the application layer, using eduGAIN

6. Use the token as prove of authentication



eduToken

• The uSSO token is called eduToken

• It must express:– Who has been authenticated,– When,– By whom,– Using which method– How long the eduToken is valid



eduToken

• SAML 1 Assertion– Issuer– Issue Instant– Condition: Not On Or After– Authentication Statement

• Authentication Instant + Method• Subject – Name Identifier

• It is digitally signed + by a trusted entity• eduToken = SAML Assertion + Authentication Statement



Token-based uSSO Profile

User’s Device:• Browser: with Java-Plugin• uSSO Client: Token Manager, Java application

Service Domain:• SP: Service Provider, e.g. Shibboleth, unmodified• Token Fetcher Applet• R-BE: remote eduGAIN Bridging Element, modified



Token-based uSSO Profile Connect. Communicate. Collaborate

User’s Device

SP Domain

Request Access

SP R-BEuSSOClient

Browser

Redirect

Token Fetcher Applet

Fetch eduToken

Decrypt eduToken

Return eduToken

POST eduTokenValidate eduTokenCreate Assertion

Grant Access

Send

Assertion




eduGAIN Bridging Element (BE):• Map local federation language to eduGAIN language• Central - per federation, or distributed - per institution• Part of the eduGAIN circle of trust

Remote BE (R-BE):• Towards the SP: act like an IdP of the local federation• Towards eduGAIN: talk to the Home BE




Token-enabled R-BE:• Towards the SP: as usual• Towards eduGAIN: not necessary (except attribute-pull)• NEW Towards the client: request the eduToken, receive it

(validation as usual – eduToken is in native eduGAIN language)– Token Request = an active component able to reach

“outside” the browser– Implemented here as a signed Java Applet




Token-enabled R-BE (continued):• Implementation, Deployment:

– 1 Tomcat– 1 Java Servlet– 1 Java Keystore– 1 Applet



Conclusion

The implementation provides:• unified Single Sign On:

“open your laptop and be signed on”

The concept also enables:• Simplified Where Are You From• No IdP interaction ( privacy)• SSO for non-web applications / for local applications



Questions?

Any questions or comments?

DAMe website: http://dame.inf.um.es/

DAMe mailing list: [email protected]

GÉANT2-JRA5 website: http://www.geant2.net/jra5

Connect. Communicate. Collaborate Universität Stuttgart A Client Middleware for Token- Based...

Documents

Transcript of Connect. Communicate. Collaborate Universität Stuttgart A Client Middleware for Token- Based...