Transcript ppt

USC’s OAuth Recipe:
OAuth + Enriched Identity Data +
Central Authorization
Brendan Bellina
Mgr, Identity and Access Management
University of Southern California
[email protected]
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
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
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
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
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
Workflow for
Register using
OAuth Provider
at USC
Guestreg site,
select user ID
5 - 10 min
Receive Email
with registered
id (eppn)
Contacts
group
managers,
providing
registered id
Wait < 10 minutes
Guest goes
to app and
selects
OAuth
provider and
logs in
End User Actions
ps
External
Guest
Sync
at
USC
Grou
proce
p
GDS
ss
mana
initiat
Grou
ger
ed
ps
uses
every
Sync
MyGr
proce
10
oups
minut
ss
to
initiat
es
submi
ed
t
Enriched
Packet
every
consisting of registered id
partici
(eppn), standard attribute
10 group
set, and scoped
memberships from USC
pant
IdP provided
to application
minut
to
es Processes
Administrator Actions
Automated
group
s
7
Guest Self-Registration
8
Live Demonstration
9
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
Directed to Guest Registration Site (www.usc.edu/guestreg)
11
Select Your OAuth Provider
12
Login to the OAuth Provider (Facebook in this case)
13
Allow Release of Attributes from OAuth Provider
14
Select Persistent ID
15
Self-assert Enriched Data
16
17
Display/Maintenance of Current Registration
18
Notification of Registered ID / ePPN
19
Linking An Additional OAuth Provider
20
Use “Link social account” Option
21
Select OAuth Provider to Link
22
Login to the OAuth Provider (Google in this case)
23
Presto Chango…
24
External Authorization
25
But… An Account Alone Isn’t Authorization
26
Application Administrator Authorizes Guest
27
Authorized Guest Accesses Application
28
Selects OAuth Provider
29
Login to OAuth Provider (Facebook this time)
30
Personalized Access to the Application
31
Select a Linked OAuth Provider
32
Login to OAuth Provider (Google this time)
33
Identical Personalized Access to the Application
34
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
35
Questions…
36
Links

USC: http://www.usc.edu

USC IAM Website: http://www.usc.edu/iam

USC Guest Registration: http://www.usc.edu/guestreg

USC MyGroups: http://www.usc.edu/mygroups
37