Social Identity Working Group Steve Carmody

Agenda Intro to Using Social Accounts Status and Recent News –Current UT Pilot –Current InCommon Pilot with Cirrus Identity Review, Develop Consensus on Common RequirementsCommon Requirements Next Steps Campuses Working With Cirrus 2

Topics Some History Use Cases Requirements Why How Status 3

Some History Early work in Europe by Andreas Solberg and Roland Hedberg InCommon TAC forms Social Identity Working group Some campuses deploy local solutions (eg CMU) 4

Some History Pilot Gateway available since Fall 2012 –Operated by Paul Caskey, UT –NO SLA! –This Pilot will end! InCommon 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 5

Use Cases We’re used to working with identities vetted and issued by our campus and 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 6

Use Cases Up until now, campuses have been issuing campus identities to of these people However, 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 … there is the same issue for a campus identity issued to someone with only a loose, remote connection to the campus 7

Requirements An SP can be accessed 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 Process for the browser user is uncomplicated 8

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 As easy as possible for users to use and understand 9

How Does it Work ? Web-based authentication gateway Translates authentication responses from popular “social” ID services into regular SAML 2 Assertions (consumable by Shibboleth) Downstream applications receive SAML Assertions (which may have been generated by the S2S Gateway) 10

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

User Experience 12

User Experience 13

14

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

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 want to leverage 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 16

Status Next Phase –Looking to work with campuses to develop use cases and requirements during Summer 2013 –Campus participants being identified (raise your hand if interested! ) –Hope to have service available to InCommon members for Fall

Social Identity Working Group Info available at: – List Bi-weekly conference calls 18

Questions? 19

Cirrus Identity Social Gateway Service May 2013

Overview of Gateway Service

Phase 1 – InCommon/Internet2 SPs Beta gateway service for InCommon Federation Manager app and Internet2 spaces (you can try it now) Limited scope for initial offering – Supports Google OpenID 2.0 – Metadata exchange with the SPs (no decision on social IdPs in InCommon metadata) Cirrus Identity working with InCommon to move beta gateway to a production service for those 2 SPs

Phase 2 – Higher Ed Gateway Offering Cirrus Identity working with a small set of early adopter campuses on common core requirements The gateway service will be built on existing open source software (SimpleSAMLphp) and new open source software developed by Cirrus Identity By sometime this fall, Cirrus Identity hopes to have code and service available InCommon and Cirrus Identity currently evaluating business and support models

Some Key Questions Which social IdPs should be supported in the service? How will Gateway Manager admins be authorized? How are social identities handled in InCommon metadata and what are the options for discovery? What are the requirements for a basic invitation service and how will social identities registered to a specific campus or SP be exposed to a campus IDMS?

Early Adopters The InCommon social identities workgroup has identified a handful of early adopter campuses If you are interested, contact Steven Carmody or Keith Hazelton, chairs of the social identities workgroup