You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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.

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
--->   no registration finished ==> no service for him
It the registration is succesfull,  " a Social Guest keystone project/tenant" available for him.   [  later on will structure this ]   - 
===> Performances issues

===================================================  WF is done ==========================================================

 

 

 

===========================================================================

Invitation based flow

===========================================================================

Account link 

 

 

 

 

 

 

=======================================================================================================================

 

 

  • No labels