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 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 2013

17

Social Identity Working Group

• Info available at:

– https://spaces.internet2.edu/display/socialid/Home

• Email 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 acampus 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