Versions Compared

Old Version 5

changes.mady.by.user Mario Reale

Saved on

compared with

New Version Current

changes.mady.by.user user-e06a9

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Introduction

This pilot

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)providing federated access to resources within a given research collaboration, exploiting mechanisms to enhance the LoA of the users. The idea is to be able to support individual researchers that are not affiliated with any of the traditional home organisations, as well as those users whose Identity Providers are not part of any of the eduGAIN participating federations.  

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

...

pilot showcases how to cater for these cases by enabling a research collaboration, namely the AARC Pilot User Community, to use social networks as third party Identity Providers. The key factors in enabling such Guest Identity services is to be able to support multiple technologies and flexible policies in a scalable and trustworthy manner. In this context, the pilot is based on an SP-IdP proxy architecture (see also AARC Blueprint Architecture) through which users are able to authenticate with the credentials provided by the IdP of their Home Organisation (e.g. via eduGAIN), as well as using Social Identity providers, or other selected external identity providers. Specifically, the proxy has built-in support for SAML, OpenID Connect and OAuth2 providers and enables user logins through Facebook, Google, LinkedIn, and ORCID. The proxy is then responsible for enriching the identity information that comes from these external IdPs with additional attributes, including the following:

  • a unique, persistent, non-reassignable user identifier (namely AARC ID, expressed as an eduPersonUniqueId attribute scoped at "@aarc-project.eu");
  • assurance level (expressed as an eduPersonAssurance attribute);
  • community membership roles and groups (expressed through eduPersonEntitlement attribute values). 

Note that a user cannot access federated resources until they obtain an AARC ID through enrollment in the AARC Pilot User Community. In addition, we have defined a minimum set of attributes required for registering for an AARC ID. The SP-IdP proxy will attempt to retrieve these attributes from the user’s Home Organisation. If this is not possible, then the user will be asked to provide the missing attribute values and the request to join the collaboration will need to go through a verification process by the collaboration's Sponsors.

Detailed description

A detailed description of the aim and approach of this pilot and how it maps to the AARC Blueprint Architecture is available here

Demonstration portal

For the purpose of this pilot, we have enabled federated access to the dashboard of a demo OpenStack Cloud deployment. Specifically, the pilot IdP proxy has been configured to authenticate users and communicate the result of the authentication to OpenStack's Identity service (Keystone) using SAML assertions. The SAML assertions are then mapped to keystone user groups, based on which, the authenticating user can access cloud resources using their federated AARC ID.

Registration/Login Workflow

1.Access OpenStack's Dashboard (Horizon) at https://am02

...

.pilots.aarc-project.eu/

...

horizon
Image Added
2.

Click Connect and select your Identity Provider from the discovery page (WAYF). You may select any of the following options:

  • Institutional IdP: AARC DIY Identity Provider (considered an institutional IdP for demo purposes only)
  • Social IdPs: Facebook, Google, LinkedIn
  • ORCID
Image Added
3.Enter your login credentials to authenticate yourself with the IdP of your Home Organisation (e.g. Google)
Image Added
4.After successful authentication, you may be prompted by your Home Organisation to consent to the release of personal information to the EGI AAI Service Provider Proxy 
5.On the EGI AAI Consent about releasing personal information page, click Yes, continue to consent to the release of personal information to the EGI User Account Registry. If you select the Remember option, your browser will remember your choice unless you clear your cookies or restart the browser.
Image Added
6.

If this is your first time logging in, you will be redirected to the AARC Pilot User Community Sign Up page after successful authentication. Alternatively, you may access the sign up page directly by visiting:

https://aai-dev.egi.eu/join-aarc

Image Added
7.

Depending on the LoA and/or attributes released by your Home IdP, there are two sign up workflows:

  1. If the LoA is substantial and all required attributes are released: Self-service Sign Up (typically for users coming from eduGAIN IdPs, or the AARC DIY Identity Provider for the purpose of this demo)
  2. If the upstream IdP cannot provide all attributes, or the LoA is low: Approval-based Sign Up. For example, in the case of Social IdPs the Affiliation Attribute will be missing; thus, you will be asked to provide any missing attribute values yourself.

Image Added

Image Added

8.On the registration form, click Review Terms and Conditions 
9.If you agree to the Terms of Use, select the I Agree option. Important: You will not be able to agree to the terms until you review them! 
10.Finally, click Submit to submit your request. Important: You will not be able to submit your request until you agree to the terms!
Image Added
11.After submitting your request, you will receive an email with a verification link in it. After you click that link, you'll be taken to the request confirmation page.
Image Added
12.After reviewing your request, click Confirm and re-authenticate yourself using the Identity Provider you selected in Step 2.
Image Added
13.

If your sign up request requires approval (see Step 7), the Sponsor(s) of the VO will be notified via email. You will need to wait for a Sponsor to approve your request to join the AARC Pilot User Community. Upon approval, you will receive a notification email.

Image Added
14.

After your registration has been completed, you can manage your profile through the Account Registry portal at https://aai-dev.egi.eu/registry

Image Added

15.

Relogin to OpenStack's dashboard at https://am02.pilots.aarc-project.eu/horizon. You will be mapped to a Keystone user group based on the values of the eduPersonEntitlement attribute

Image Added

Identity Linking Workflow

Identity linking allows users to access federated resources with their existing personal AARC ID, using any of the login credentials they have linked to their account. To link a new organisational or social identity to your AARC account:

1.Enter the following URL in a browser: https://aai-dev.egi.eu/registry
Image Added
2.Click Login and authenticate using any of the login credentials already linked to your AARC account
Image Added
3.Navigate to My AARC Pilot User Community Account page in any of the following ways:
  • hover over your display name next to the gear icon on the top right corner of the page;

    or, alternatively,

  • select AARC Pilot User Community from the list of available Collaborations and then click My AARC Pilot User Community Account from the People menu
Image Added
4.Under the Organisational Identities section of your profile page, click Link New Identity.
Image Added
5.On the introductory page for Identity Linking, click Begin
Image Added
6.On the Link New Identity form, click Review Terms and Conditions
Image Added
7.After reviewing the Terms and Conditions, click OK
Image Added
8.If you agree to the Terms and Conditions, select the I Agree option. Important: You will not be able to agree to the terms until you review them.
 Image Added
9.Finally, click Submit to submit your request. Important: You will not be able to submit your request until you agree to the terms. 
10.After submitting your request, you will receive an email with a link in it. After you click that link, you'll be taken to the Link New Identity confirmation page.

Image Added

Image Added

11.On the Link New Identity confirmation page, click Confirm
Image Added
12.After confirmation, you will need to sign in using the login credentials from the Institutional/Social Identity Provider you want to link to your account
Image Added
13.After successful authentication, you'll be able to access federated resources with your existing personal AARC ID using the login credentials of the Identity Provider you selected in the previous step
Image Added

Components

 

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 

 

 

 

 

 

 

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

 

...