Social Identities pilot

The Goal for the Social Identities pilot is to demonstrate LoA enhancing mechanisms for Social Identities to allow their inclusion in the Authorization process against SAML Service Providers.

An additional important goal of this pilot is to demonstrate the possibility to deal with Social Guest identities in a unified manner, being able to connect different source of Social Identities at the same time. Moreover, account linking from Social to ORCID aims at demonstrating the possibility to use single, non-reassignable identifiers.

Use Case: Floating users not connected to any of the HOs having a federated IDP but collaborating with Virtual Organizations through the usage of Research Infrastructures need to be authorized on VO resources:

VOs need to have available a mechanism to authorize to SPs non federated users.

LoA enhancing mechanism: in the pilot two main LoA enhancing mechanisms can be exploited:  

  1. Account linking Social ID to ORCID Identity of user

  2. Attribute Enrichment based on the usage of an external Attribute Authority - It is a LoA enhancing mechanisms due to the registration procedures to a specific VO.

         VO-specific LoA enhancement mechanisms - If registration procedures are known, published and shared

Account linking Social ID to ORCID Identity of user

Proposed workflow A:

  • A user logs in on a web portal via OAuth using her/his social credentials

  • portal acts as SAML IDP

  • IDP contacts ORCID via API to get user’s information - being the social user registered in ORCID

  • SAML attributes are set based on user’s ORCID related information

  • SAML assertion on user ID sent to the Openstack Keystone configured as SAML SP

  • User gets mapped to a specific Openstack tenant and gets a specific level of Authorization  related to the LoA associated to her/his identity

Attribute Enrichment based on the usage of an external Attribute Authorities

Proposed workflow B:

  • A user logs in on an web portal via OAuth using her/his social credentials

  • portal acts as SAML IDP (OpenID to SAML proxy)

  • IDP contacts COmanage to get user’s information - being the social user registered in the VO COmanage instance ( ex. Linking identities through email addresses)

  • SAML attributes are set based on user’s COmanage provided information

  • SAML assertion on user ID sent to the Openstack Keystone configured as SAML SP

  • User gets mapped to a specific Openstack tenant and gets a specific level of Authorization related to the LoA associated to her/his identity

Proposed involved components:

 https://aai-dev.egi.eu/linkedin/module.php/core/authenticate.php?as=linkedin

  • COmanage [REF 4]  acting as Attribute Authority

  • ORCID Identifier [REF 5]  / ORCID API access

    • ORCID-to-SAML IdP

  • Openstack Keystone acting as federated SPs to Authorize user on

The pilot aims at demonstrating basic mechanisms to enhance the LoA associated to social identities used within  Virtual Organization to authenticate users as an additional mean of authentication with respect to standard SAML Federated users owning federated credentials.

The idea behind the pilot is that a Virtual Organization manages an Attribute Authority (like COmanage) and reserves a specific collaboration inside it for the benefit of its users. In our case, a collaboration called aarc-social.pilots.aarc-project.eu has been created to host guest users in the COmanage instance at EGI hosted on https://am03.pilots.aarc-project.eu/registry/ .

The federated service which is accessed through an IDP/SP proxy, transparent for users, is the Openstack dashboard ( keystone ), is hosted at EGI and accessible at https://am02.pilots.aarc-project.eu/horizon .

Users are prompted to select their IDP, and they can use the Social ID ones ( for example the Google ID).

Once logged in via Google, users will be notified of the need for the COmanage Collaboration manager (acting as a sponsor) to approve their membership registration.

Once the sponsor approves it, user are notified via email. They get a token via email to access the dashboard, mapped as users in a simple, demo project, allowing them to perform the basic openstack users operations (spawn VMs, create snapshots..).

The self-service COMANAGE enrollment workflow is used, so that users will effectively become part of the Collaboration with their social identity record.

The IDP connector in fact passes the opaque Google ID to the IDP/SP proxy; which, at his turn, passes it to the COmanage SP. COmanage adds the required attributes for the keystone SP to map the user in a domain, group, project and user inside OpenStack.

A hands-on section for interested users has been set up on the AARC wiki and is avalable for interested users to try it out on the public section of the wiki at https://wiki.geant.org/display/AARC/SocialIDCockpitPanel

 

ComanageGuestPilot.gif

Figure 8: Architecture of the Social IDP pilot

  • No labels