SocialIDCockpitPanel

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/

Users will need to access the openstack dashboard - ARAC instance at EGI ; They will be re-directed to the WAYF offering different IDPs; They will select on of the social ones ( e.g. Google ), and be then faced with their Google login page. 

Once logged in, they will be displayed a message stating their request for subscription to the COMANAGE- collaboration requires approval by the VO Sponsor (and be informed of this also via email ).

 Once approved, they will be notified via email - Once approved they will be able to access the dashboard

User Workflow for interested users:

1. 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 )
2. He opens the web page for horizon at  https://am02.pilots.aarc-project.eu/horizon .
3. User selects either HO IdP (trivial use case in this pilot) or a Social Link page - Social IDPs : ( FB, Linkedin, Google, ORCID)
4. User select Social IDPs or ORCID
5. User is redirected to the Sign In page of the IDP :   Google Login for example
6. IDP proxy sends information to COMANAGE (SP) inside a SAML assertion
7. According to the LoA user is faced to 2 options:
8. The workflows implements 2 operational options, then : 
   1.  LoA is enough  ---->   Registration SELF-SERVICE Registration inside COMANAGE  ( Self Service Flow in COMANAGE - when user coming from eduGAIN IDP  - i.e. if the  upstream IDP supports R & S  --> automatic attribute exchange  )
   2. If the upstream IDP cannot provide all attributes, or if the IDP is social (  = Affiliation Attribute is missing) --> user asked to provide himself the affiliation ( --> user asserted)
9. The Registration process will therefore in this second case  also inform the Sponsor of the VO :  " user John Smith asked for registration  on the COMANAGE collaboration " )
10. The Sponsor user has to approve the request via  https://am03.pilots.aarc-project.eu/registry/  ( thus triggering a specific enrolloment process - approval based registration within COMANAGE)
11. The user email shows up inside COMANAGE -  Subject Identifier retained by Google - Unique, Persistent, non-Reassignable (not the email address of google)
12. 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.
13. When the user tries to login on the SP - openstack dashboard -   URL of EGI pilot openstack  - https://am02.pilots.aarc-project.eu/horizon .
14. he logs in with his google account :
    1. Mapped to keystone:  Mapping is based on eduPersonEntitlement or  MemberOf().   We also add the membership to specific collaborations inside COMANAGE in the mapping.
    2. In the pilot we mapped user afiflitation to a keystone Group ; next experiment:  map Entitlement to a Group.  What if a user does not have nor Entitlement or Affiliation
    3. --->   no registration finished ==> no service for him
15. It the registration is succesfull,  " a Social Guest keystone project/tenant" available for him.   [  later on will structure this into admin and user roles in keystone]   -