1. Federated Shibboleth, OpenID, oAuth, and Multifactor | 1 Federated Shibboleth, OpenID, oAuth, and Multifactor Russell Beall Senior Programmer/Analyst University of Southern California beall@usc.edu

2. Federated Shibboleth, OpenID, oAuth, and Multifactor | 2 University of Southern California  Private research university, founded 1880  Budget:  $2.9 billion annually  $560.9 million sponsored research  Locations:  two major LA campuses  six additional US locations  four international offices  http://about.usc.edu/facts

3. Federated Shibboleth, OpenID, oAuth, and Multifactor | 3 University of Southern California  298,000+ affiliated individuals  17,500 undergraduate students  20,500 graduate and professional students  3,400 full-time faculty  11,800 staff  240,000 alumni  5200 sponsored affiliates with active services  157 self-registered guest accounts (so far)

4. Federated Shibboleth, OpenID, oAuth, and Multifactor | 4 Problems solved  Faculty/Staff/Student/Guest access  systems of record  automated account creation  sponsorship and vetting  mature access control infrastructure

5. Federated Shibboleth, OpenID, oAuth, and Multifactor | 5 Problems solved  Federated Shibboleth access  self-registration  no USC account to maintain  limited sponsorship/vetting  works within mature access control infrastructure

6. Federated Shibboleth, OpenID, oAuth, and Multifactor | 6 New Interesting Problems  oAuth  OpenID  Multifactor

7. Federated Shibboleth, OpenID, oAuth, and Multifactor | 7 oAuth and OpenID 101  authentication from external websites  social networking interaction  OpenID  simple authentication  single basic identifier response  oAuth  in-depth API interaction capabilities  post to Twitter or Facebook  pull contacts/friends from Google, Facebook, etc.

8. Federated Shibboleth, OpenID, oAuth, and Multifactor | 8 oAuth and OpenID  Alternative to Shibboleth Federated login  useful for:  non-participants  strict access IdPs  replacement of ProtectNetwork

9. Federated Shibboleth, OpenID, oAuth, and Multifactor | 9 oAuth and OpenID  OpenID – insecure (untrustworthy)  Easy to set up and use, but…  No trust relationship with provider  Data returned in HTTP GET parameter  Easily spoofed using proxy server ♦ Haven’t run a spoof test, so I may be proven wrong…

10. Federated Shibboleth, OpenID, oAuth, and Multifactor | 10 oAuth and OpenID  oAuth – secure  Data retrieved on backend  server-to-server communication  trust token exchange  secret key/token signing of requests  Not subject to spoofing  More difficult than OpenID by several degrees  two versions – 1.0a and 2.0  requires definition of application at each provider  API differences between providers  however, open source libraries are available

11. Federated Shibboleth, OpenID, oAuth, and Multifactor | 11 Multifactor 101  Authentication which requires more than one type of assurance  Existing authentication methodologies use one or more of three basic factors:  Something the user knows  e.g., password, PIN  Something the user has  e.g., ATM card, smart card  Something the user is  e.g., biometric such as eye, voice or fingerprint patterns  Multiple factors are harder to compromise than a single

12. Federated Shibboleth, OpenID, oAuth, and Multifactor | 12 Multifactor 101  Why bother?  Add additional layer(s) of protection for critical resources.  Helps strengthen the assurance that the user is the true owner of the account  not a hacker  not using shared passwords  e.g. coworker, friend, parent

13. Federated Shibboleth, OpenID, oAuth, and Multifactor | 13 Multifactor  several quality levels:  lightweight version  local credential plus oAuth  local credential plus federated Shibboleth  unfortunately, both layers are “something the user knows”  full-fledged options  tiqr  Duo Security  RSA  others

14. Federated Shibboleth, OpenID, oAuth, and Multifactor | 14 Multifactor  Two types possible with Shib:  decided by application  app chooses other factor(s) and requests as needed  authentication contexts coordinated by SP config  IdP-based  IdP uses multiple factors within a single context

15. Federated Shibboleth, OpenID, oAuth, and Multifactor | 15 Trust  What is the trust model?  How do we trust:  a hardware token?  an oAuth authentication event?  a Federation member authentication event?

16. Federated Shibboleth, OpenID, oAuth, and Multifactor | 16 Trust  Trust is established with:  vetting  token management practices  Applies equally to hard or soft tokens  Either must be registered

17. Federated Shibboleth, OpenID, oAuth, and Multifactor | 17 Registration  Multifactor  requires hardware token linking  phone  keyfob  oAuth/Federated authentication  good = vetted registration under supervision  sufficient(?) = telephone/email communication of identifier to be trusted  If nobody controls registration, neither can be trusted

18. Federated Shibboleth, OpenID, oAuth, and Multifactor | 18 Two-factor Registration

19. Federated Shibboleth, OpenID, oAuth, and Multifactor | 19 Two-factor Registration Install mobile app

20. Federated Shibboleth, OpenID, oAuth, and Multifactor | 20 Two-factor Registration

21. Federated Shibboleth, OpenID, oAuth, and Multifactor | 21 Two-factor Registration Mobile app push

22. Federated Shibboleth, OpenID, oAuth, and Multifactor | 22 Federated Guest Registration oAuth providers to be added here

23. Federated Shibboleth, OpenID, oAuth, and Multifactor | 23 Federated Guest Registration

24. Federated Shibboleth, OpenID, oAuth, and Multifactor | 24 Enrichment  Registration of oAuth or Federation guest creates simple LDAP account  No password  Registration enables enrichment with access entitlements and other data  Targeted enrichment creates a layer of trust  Layer is thinner than hardware but could be considered workable

25. Federated Shibboleth, OpenID, oAuth, and Multifactor | 25 Enrichment

26. Federated Shibboleth, OpenID, oAuth, and Multifactor | 26 Demo

27. Federated Shibboleth, OpenID, oAuth, and Multifactor | 27 For Future Pondering  With sufficient vetting, could a software token as a second factor authentication be acceptable?  Plus points:  low budget  hacking one account is easy, hacking two and knowing the linkage is not  Negatives:  duplicated passwords  depends on free APIs with no service contract  technically, both methods are “something the user knows”

28. Federated Shibboleth, OpenID, oAuth, and Multifactor | 28 Summary  With federated access deeply embedded at the enterprise level, a layer of trust can be added.  With this additional trust, oAuth can be used for privileged access to resources or even as a pseudo-second-factor.