Federated Shibboleth, OpenID, oauth, and Multifactor

Transcription

1 Federated Shibboleth, OpenID, oauth, and Multifactor Russell Beall Senior Programmer/Analyst University of Southern California Federated Shibboleth, OpenID, oauth, and Multifactor 1

2 University of Southern California Private research university, founded 1880 Budget: $2.9 billion annually $560.9 million sponsored research LocaGons: two major LA campuses six addigonal US locagons four internagonal offices Federated Shibboleth, OpenID, oauth, and Multifactor 2

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

4 Problems solved Faculty/Staff/Student/Guest access systems of record automated account creagon sponsorship and vexng mature access control infrastructure Federated Shibboleth, OpenID, oauth, and Multifactor 4

5 Problems solved Federated Shibboleth access self- registragon no USC account to maintain limited sponsorship/vexng works within mature access control infrastructure Federated Shibboleth, OpenID, oauth, and Multifactor 5

6 New InteresGng Problems oauth OpenID MulGfactor Federated Shibboleth, OpenID, oauth, and Multifactor 6

7 oauth and OpenID 101 authengcagon from external websites social networking interacgon OpenID simple authengcagon single basic idengfier response oauth in- depth API interacgon capabiliges post to Twiaer or Facebook pull contacts/friends from Google, Facebook, etc. Federated Shibboleth, OpenID, oauth, and Multifactor 7

8 oauth and OpenID AlternaGve to Shibboleth Federated login useful for: non- pargcipants strict access IdPs replacement of ProtectNetwork Federated Shibboleth, OpenID, oauth, and Multifactor 8

9 oauth and OpenID OpenID insecure (untrustworthy) Easy to set up and use, but No trust relagonship 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 9

10 oauth and OpenID oauth secure Data retrieved on backend server- to- server communicagon 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 definigon of applicagon at each provider API differences between providers however, open source libraries are available Federated Shibboleth, OpenID, oauth, and Multifactor 10

11 MulGfactor 101 AuthenGcaGon which requires more than one type of assurance ExisGng authengcagon 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 paaerns MulGple factors are harder to compromise than a single Federated Shibboleth, OpenID, oauth, and Multifactor 11

12 MulGfactor 101 Why bother? Add addigonal layer(s) of protecgon for crigcal 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 Federated Shibboleth, OpenID, oauth, and Multifactor 12

13 MulGfactor several quality levels: lightweight version local credengal plus oauth local credengal plus federated Shibboleth unfortunately, both layers are something the user knows full- fledged opgons Gqr Duo Security RSA others Federated Shibboleth, OpenID, oauth, and Multifactor 13

14 MulGfactor Two types possible with Shib: decided by applicagon app chooses other factor(s) and requests as needed authengcagon contexts coordinated by SP config IdP- based IdP uses mulgple factors within a single context Federated Shibboleth, OpenID, oauth, and Multifactor 14

15 Trust What is the trust model? How do we trust: a hardware token? an oauth authengcagon event? a FederaGon member authengcagon event? Federated Shibboleth, OpenID, oauth, and Multifactor 15

16 Trust Trust is established with: vexng token management pracgces Applies equally to hard or son tokens Either must be registered Federated Shibboleth, OpenID, oauth, and Multifactor 16

17 MulGfactor RegistraGon requires hardware token linking phone keyfob oauth/federated authengcagon good = veaed registragon under supervision sufficient(?) = telephone/ communicagon of idengfier to be trusted If nobody controls registragon, neither can be trusted Federated Shibboleth, OpenID, oauth, and Multifactor 17

18 Two- factor RegistraGon Federated Shibboleth, OpenID, oauth, and Multifactor 18

19 Two- factor RegistraGon Install mobile app Federated Shibboleth, OpenID, oauth, and Multifactor 19

20 Two- factor RegistraGon Federated Shibboleth, OpenID, oauth, and Multifactor 20

21 Two- factor RegistraGon Mobile app push Federated Shibboleth, OpenID, oauth, and Multifactor 21

22 Federated Guest RegistraGon oauth providers to be added here Federated Shibboleth, OpenID, oauth, and Multifactor 22

23 Federated Guest RegistraGon Federated Shibboleth, OpenID, oauth, and Multifactor 23

24 Enrichment RegistraGon of oauth or FederaGon guest creates simple LDAP account No password RegistraGon enables enrichment with access engtlements 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 24

25 Enrichment Federated Shibboleth, OpenID, oauth, and Multifactor 25

26 Demo Federated Shibboleth, OpenID, oauth, and Multifactor 26

27 For Future Pondering With sufficient vexng, could a sonware token as a second factor authengcagon be acceptable? Plus points: low budget hacking one account is easy, hacking two and knowing the linkage is not NegaGves: duplicated passwords depends on free APIs with no service contract technically, both methods are something the user knows Federated Shibboleth, OpenID, oauth, and Multifactor 27

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