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