Brown University Leveraging Social Identities Steve Carmody CSG, May 15, 2013

2 Topics What Why How Status

3 What Support access by people with either Federated or Social Identities Provide application owners with a single authN/Z Framework for both types of Identities Provide info to the application about the user with a single interface, regardless of Identity type Application owner can choose which Social Identity providers to allow

4 Why We’re used to working with identities vetted and issued by other campuses But, we already work with people from outside those Communities –Applicants –Parents –Continuing Education/MOOCs Other areas showing interest in working with people outside the traditional communities –Courses -- additional speakers form the community –Research - partners at campuses that are not Shibboleth- enabled

5 Why All of those people have identities at one of the social/personal providers Google, Yahoo, FaceBook, etc In some circumstances, this approach may be preferable to issuing campus identities to those people However, there is NO guarantee about who is using a social account

6 How Web-based authentication gateway Translates authentication responses from popular “social” ID services into regular SAML 2 Assertions (consumable by Shibboleth) Allows downstream applications which only understand SAML to easily utilize external services using other protocols

7 How Does it Work ? Looks like an IDP to the SP Looks like a single SP/app to external services Designed to be as simple and transparent as possible for Application Owners to use

8 Maps attributes (if released by service/user) –givenName –Sn –Mail –uid Generated attributes –eduPersonPrincipalName –eduPersonTargetedID (as a SAML 2 NameID) –displayName

9 What We’ve Learned Works great for guest authentication Typical use is “pick and choose” among the external services Very powerful when combined with invitation service (eg MACE Grouper)

10

11

12 Issues Consent screen at Social Providers asks user to release attributes to the Gateway, not the SP Each Social Provider provides different attributes Many applications prefer an invitation service (eg MACE Grouper includes one) Should a locally run Gateway instance integrate with the local Person Registry, and register different providers/accounts for each person

13 Status Pilot Gateway available since Fall 2012 –Operated by Paul Caskey, UT –NO SLA! –This Pilot will end! 2nd Pilot underway –Gateway provided and operated by Cirrus Identity –Can be used to access I2 Spaces Wiki and InCommon Federation Manager App –Currently only supports Google

14 Status, Continued Next Phase –Looking to expand use and use cases –Require definition, testing during Summer 2013 –Campus participants being identified –Hope to have service available to InCommon members for Fall 2013

15 Questions?