HANDS ON FOR INTERESTED USERS
The Social Identities pilots aims at demonstrating possible mechanisms to include Social Identities ( FB, Google, Linkedin..) in the Authentication and Authorization process for consuming federated services (SAML SPs), exploiting mechanisms to enhance the LoA of the users.
The architecture implemented by the pilot provides an IDP/SP proxy which bridges the external ID providers through the usage of an Attribute Authority (COMANAGE).
At this purpose we have set up a specific collaboration inside COMANAGE, which acts as Attribute Authority, integrating the basic attributes
A VO sponsor is the admin of that Collaboration : identities are managed by the admin in the COMANGE admin interface at https://am03.pilots.aarc-project.eu/registry/
User Workflow for interested users:
User accesses the Openstack Dashboard to use the Openstack cluster configured as a SAML SP: ( User lands to the Sign up page, either directly or indirectly )
He opens the web page
WAYF page: user selects either HO IdP (boring for us) or a Social Link page - Social IDPs -
User select Social IDPs or ORCID
User is redirected to the Sign In page of the IDP : Google Login for example
IDP proxy sends information to COMANAGE (SP) inside a SAML assertion
We have now 2 choices: LoA is enough ----> Registoration SELF-SERVICE Registration inside COMANAGE ( Self Service FLow in COMANAGE - when user coming from eduGAIN IDP )
--> IF upstream IDP supports R & S --> automatic attribute exchange
If the upstrad IDP cannot provide all attributes, or if the IDP is social ( = Affiliation Attribute is missing) --> user asked to provide himself the affiliation ( --> user asserted)
The Registration process will therefore also inform the Sponsor of the VO : " user John Smith asked for registration on the COMANAGE collaboration " )
The Sponsor user has to approve the request ( specific enrolloment process - Approval based registration within COMANAGE)
The user email shows up inside comanage - Subject Identifier retained by Google - Unique, Persistent, non-Reassignable (not the email address of google)
The connector passes this IDP to the IDP/SP proxy
The PX generated an opaque ID in Google --> Sent to COMANAGE SP the EGI-ID (proxy generated one)
COMANAGE does not store the Google ID , but the EGI SP generated one. This acts as primary key.
When the user try to login on the SP - openstack dashboard - URL of EGI pilot openstack - am02 --> sign up page
he logs in with his google account
Mapped to keystone: Mapping is based on eduPersonEntitlement or MemberOf(). We also add the membership to specific collaborations inside COMANAGE in the mapping.
=================================================== WF is done ==========================================================
===========================================================================
Invitation based flow
===========================================================================
Account link
=======================================================================================================================