Federated Shibboleth, OpenID, oAuth, and Multifactor | 1
Federated Shibboleth, OpenID, oAuth, and Multifactor
Russell Beall
Senior Programmer/Analyst
University of Southern California
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
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)
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
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
Federated Shibboleth, OpenID, oAuth, and Multifactor | 6
New Interesting Problems
oAuth OpenID Multifactor
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 Facebookpull contacts/friends from Google, Facebook, etc.
Federated Shibboleth, OpenID, oAuth, and Multifactor | 8
oAuth and OpenID
Alternative to Shibboleth Federated login useful for:
non-participantsstrict access IdPsreplacement of ProtectNetwork
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…
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
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
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 accountnot a hackernot using shared passwords
e.g. coworker, friend, parent
Federated Shibboleth, OpenID, oAuth, and Multifactor | 13
Multifactor
several quality levels: lightweight version
local credential plus oAuth local credential plus federated Shibbolethunfortunately, both layers are “something the user knows”
full-fledged optionstiqrDuo SecurityRSAothers
Federated Shibboleth, OpenID, oAuth, and Multifactor | 14
Multifactor
Two types possible with Shib: decided by application
app chooses other factor(s) and requests as neededauthentication contexts coordinated by SP config
IdP-basedIdP uses multiple factors within a single context
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?
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
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
Federated Shibboleth, OpenID, oAuth, and Multifactor | 18
Two-factor Registration
Federated Shibboleth, OpenID, oAuth, and Multifactor | 19
Two-factor Registration
Install mobile app
Federated Shibboleth, OpenID, oAuth, and Multifactor | 20
Two-factor Registration
Federated Shibboleth, OpenID, oAuth, and Multifactor | 21
Two-factor Registration
Mobile app push
Federated Shibboleth, OpenID, oAuth, and Multifactor | 22
Federated Guest Registration
oAuth providers to be added here
Federated Shibboleth, OpenID, oAuth, and Multifactor | 23
Federated Guest Registration
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
Federated Shibboleth, OpenID, oAuth, and Multifactor | 25
Enrichment
Federated Shibboleth, OpenID, oAuth, and Multifactor | 26
Demo
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 budgethacking one account is easy, hacking two and knowing the linkage
is not Negatives:
duplicated passwordsdepends on free APIs with no service contracttechnically, both methods are “something the user knows”
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.