1. USC’s OAuth Recipe: OAuth + Enriched Identity Data + Central Authorization Brendan Bellina Mgr, Identity and Access Management University of Southern California brendan.bellina@usc.edu

2. Discussion Points  Benefits and Challenges of OAuth  Techniques to Address Major Challenges  Self-Registration into Institutional Identity Store using Shibboleth  Enriched Identity Data  Account Linking and Unlinking  External Authorization using Groups  Live Demonstration 2

3. Benefits of Using OAuth (Social Providers)  Extend USC Services to greater populations using existing credentials stored elsewhere  Password related issues addressed by OAuth provider  Social providers being commonplace reduces barrier to adoption 3

4. Challenges With Using OAuth  Different versions of OAuth with different capabilities  Inconsistent and unpredictable attribute release  Attributes required for applications may be missing  Identity is self-asserted – potential risk to applications  User may use multiple OAuth providers, leads to login confusion and multiple identifiers  OAuth providers come and go, leading to potential loss of identifier persistence  How to Revoke an OAuth Login  Authentication without Authorization 4

5. What Is Needed  Allow multiple OAuth providers per identity and the provider should be transparent to the service  Addresses problem of user using multiple OAuth providers  Addresses problem of deprecated OAuth providers  Deliver a standard attribute set regardless of OAuth provider or version for compatibility with applications  Provide consistent user attribute values to services  Externalize authorization to apps to reduce risk and allow revocation  Support for both Just-in-Time provisioning and ETL provisioning 5

6. Benefits of Self-Registration  Registry provides single place for maintenance of user attributes  Opportunity to enrich data released by OAuth providers to meet requirements and provide consistency  Allows creation of persistent identifiers for use across institutional services  Opportunity to provide linking to multiple OAuth providers to address continuity  Ability for user to unlink an OAuth Provider or credential  Registry entries can be used for ETL Provisioning  Registry entries can be used for authorization 6

7. Workflow for External Guest at USC 7 Contacts group managers, providing registered id Grou p mana ger uses MyGr oups to submi t partici pant to group s GDS Grou ps Sync proce ss initiat ed every 10 minut es Enriched Packet consisting of registered id (eppn), standard attribute set, and scoped group memberships from USC IdP provided to application End User ActionsAdministrator ActionsAutomated Processes Register using OAuth Provider at USC Guestreg site, select user ID GDS Grou ps Sync proce ss initiat ed every 10 minut es Receive Email with registered id (eppn) Guest goes to app and selects OAuth provider and logs in Wait < 10 minutes 5 - 10 min

8. Guest Self-Registration 8

9. Live Demonstration 9

10. Oh great gods of the Demo, we beseech thee, bless us with bandwidth and stability in these times of interactivity. Let not browser bugs hamper us in our clicking. Credit to Jim Phelps, UW Madison

11. 11 Directed to Guest Registration Site (www.usc.edu/guestreg)

12. 12 Select Your OAuth Provider

13. 13 Login to the OAuth Provider (Facebook in this case)

14. 14 Allow Release of Attributes from OAuth Provider

15. 15 Select Persistent ID

16. 16 Self-assert Enriched Data

17. 17

18. 18 Display/Maintenance of Current Registration

19. 19 Notification of Registered ID / ePPN

20. Linking An Additional OAuth Provider 20

21. 21 Use “Link social account” Option

22. 22 Select OAuth Provider to Link

23. 23 Login to the OAuth Provider (Google in this case)

24. 24 Presto Chango…

25. External Authorization 25

26. 26 But… An Account Alone Isn’t Authorization

27. 27 Application Administrator Authorizes Guest

28. 28 Authorized Guest Accesses Application

29. 29 Selects OAuth Provider

30. 30 Login to OAuth Provider (Facebook this time)

31. 31 Personalized Access to the Application

32. 32 Select a Linked OAuth Provider

33. 33 Login to OAuth Provider (Google this time)

34. 34 Identical Personalized Access to the Application

35. 35 Some Technical Decision Points  Session Lifetime of OAuth Login Credential – We decided on short  Avoiding Potential ID conflicts – We decided to put all guest IDs in the unique domain guest.usc.edu  Using the same OAuth login with multiple registrations – We do not allow this as it would not be evident which registered ID and attributes to use  Bypassing registration for an app – We are not requiring registration for all applications but encourage it because of the significant benefits of registering  Lifetime of Registered Guest Accounts – We are not terminating them at this time

36. 36 Questions…

37. 37 Links  USC: http://www.usc.eduhttp://www.usc.edu  USC IAM Website: http://www.usc.edu/iamhttp://www.usc.edu/iam  USC Guest Registration: http://www.usc.edu/guestreghttp://www.usc.edu/guestreg  USC MyGroups: http://www.usc.edu/mygroupshttp://www.usc.edu/mygroups