Pilot Description

The goal of this pilot is to onboard the CTA community on federated identity in a larger, broader meaning - moving from a stand-alone solution based on IdP to a fully federated one as a possible long term goal. In the meanwhile, short terms goals for the pilot are the implmentation of the TIER-like components ( COMANAGE, GROUPER) and a IDP/SP proxy to work in a synergic way for the CTA AAI.

Identity linking between the IDs of the current standalone CTA IDP and the eduGAIN ones are a relevant goal for this pilot.

Pilot goals

Some questions to answer:

• What are the goals of this pilot?

• Why is it in AARC project?

• How this pilot will improve AARC community?

• Why should I use this pilot instead of other solutions?

Description

Main objective of this section is to report detailed informations about pilot. 

Some questions:

• How this pilot works

• Reason to prefer this pilot instead of other existing tool

• Detailed Scope

• others

Components

This section will contain a lists of components used for this pilot.

It is not required to add a detailed description for each component, but 2 important parts are:

1. Add Link to component web page
2. Add a short description to explain its function (not more than 1 raw)

An example:

• Component A - Service provider
• Component B - Bring order to chaos
• Component C - Hide my precious treasure

Architecture

Image Removed

This section will provide 2 important parts:

• Graphic representations of pilot architecture

• Graphic representations of workflow

• Lists of all components of related pilot

Use Cases

This section should explain how this pilot works through use cases (at least 2).

The goal of this pilot is to provide a non-invasive solution to simplify access to CTA services from eduGAIN and CTA community.

CTA pilot should provide a solution to CTA administrator that does not upset the mechanisms in use, because they are well know.

With this pilot, new features will be introduce: 

• Self service registration under administrator approval
• Account linking solution, under administrator approval
• simple integration and transparency to any future CTA services.

Identity linking between the IDs of the current standalone CTA IDP and the eduGAIN ones are a relevant goal for this pilot.

A long term goal of this pilot is to moving CTA community from a stand-alone solution based on IdP to a fully federated one.

This pilot perfectly fit with AARC goals:

• It help to solve issue related to authentication from different IdP but logically related to the same scientific community
• The proposed solution uses only existing technologies, without creating new ones
• It does not change background of CTA community

Even if this pilot propose a solution for CTA community, its components high flexibility allow to change configuration, so every scientific reality that needs this solution can adapt it to their community, to fit their needs of authentication and authorization.

Description

Overall the work carried out within the pilot consisted of :

1. Defininig clear user management processes to enable eduGAIN onboarding of all existing and new CTA users - This process defines steps to interface and integrate COmanage and Grouper (whose support was a clear request by the CTA community) , provisioing process of users inside COmanage,  account linking for users owning both ( CTA local and eduGAIN ) identities
2. Setting up all required infrastructural components required to implement the BPA compliant architecture: COmanage,  SATOSA IdP/SP proxy
3. Actual piloting all the forseen steps for users to exploit all provider Authentication and Authorization scenarios according to their needs 

The final goal of the pilot is to demonstrate the solutions designed and implemented to ensure full onboarding on eduGAIN of the CTA user community.   For this reason, we have piloted and demonstrated the whole set of different flows foreseen for the users.

We have identified, joinlty with the CTA community, the following categories of users:

1. Existing users on the CTA catch-all IdP
2. Brand new users for CTA ( users in eduGAIN but not in the CTA catch-all IdP - not existing in both: COmanage and Grouper)
3. Users in CTA owning and eduGAIN identity  (willing to link his identity between eduGAIN and CTA )

For each of these category of users we have identify and implemented the required workflow to ensure we can grant access to CTA resources via the newly deployed AAI infrastructure and benefit from the right authentication and authorization model being in place.

1. User already existing in the CTA IdP

First of all , a procudure has been identified to migrate current CTA user on the new infrastructure, and, in particular to create their identities inside  the newly setup COmanage instance and in Grouper.  These are users who existed already inside the CTA LDAP and the CTA IdP.

To achieve this, one option is to populate directly the COmanage CTA collaboration identities starting from the proper branches of the CTA LDAP,  and the same could be done for   the Grouper instance, in a specific Grouper stem for each of the user-accessed Service Providers ( In this way all required authorization attributes  for the user on a specifc SP would  be  stored in Grouper).

In older times, both COmanage and Grouper could thus be populated directly by the LDAP branches of the CTA LDAP.

Today we decided to adopt  a simplified and more consistent  approach in which COmanage is populated by the CTA LDAP and Grouper is consistenlty populated by the Grouper COmanage plugin, provisioning the IDs from COmanage to Grouper.  Authorization will be determined by the Attribute aggregation done at the Proxy level.

Image Added

In this way, all previously existing CTA users have their identity in COmanage and Grouper.

2. Brand new users for CTA ( users in eduGAIN but not in the CTA catch-all IdP - not existing in both: COmanage nor Grouper)

Users not in CTA IdP owning and eduGAIN identity will have to go through the COmanage email invitation based enrollment flow.  

These users will try to login to one of the CTA Service Providers, then be redirected to the SATOSA proxy. On the proxy a specific micro service is called to categorize the user, and, in particular, to find out if the user belongs to this category, i.e., if the user is new in CTA ( ePPN or ePTID).

If this is the case (user new to CTA) two main options are available:

• an email is sent to the user ( containing a registration link) as part of the email invitation COmanage user  enrollment flow. Once approved, the user is allowed to register in COmanage by  ( Acceptance of the user is based on the verification of his/her entitlements). Registration is moderated by the CO admin.
• A user can be registering directly via COmanage and WAYF to select his/her Identity Provider. This way he can subscribe to the COmanage collaboration and get approved.
  
  

3. Users in CTA owning and eduGAIN identity  (willing to link his identity between eduGAIN and CTA )

Users owning both identities, CTA ID and eduGAIN ID ( see workflow above) might decide to link them via account linking, which is a supported feature by COmanage, manually performed by the COmanage collaboration manager once requested by the user. In fact, the administrator manually links both Org identities for the user in a single COPerson inside COmanage. This, however, does not represent the end of the story, given the fact that account linking information is not transferred by COmange by Grouper. And Grouper, is in the end, the main responsible entity to authorize CTA user on the Service Providers they need to reach.  Therefore the global AAI workflow will be as follows:

User willing to connect to a Service Provider, as already mentioned, will then be redirected to the SATOSA proxy . There he/she chooses his/her IdP while being presented to a list of eduGAIN IdPs or CTA IdP by the Discovery Service on the proxy.

There an eduGAIN user (or a CTA IdP one) will trigger the execution of a microservice which will be able to tell whether the user is already existing in CTA or not.

The SATOSA microservice queries COmanage (using API) in order to discover if the user have multiple identities : if this is the case, the microservice will translate  the eduGAIN eppn into the CTA eppn.

( Another option to perform this is to add an additional Database layer on board of the proxy, keeping track of both user identities provided at user Authentication on the proxy itself).

He/she authenticates on the IdP and the  IdP asserts succesful authentication to the proxy and ships along a basic set of attributes.

If these attributes are enough to authenticate the user  on the SP,  the proxy forwards to the Service Provider a  successful Authentication response. 

in this way the user manages to login onto the CTA SP.

If the attributes are not enough to fully authorize the user on the SP, the proxy will be configured to pull from COmanage all additionally required attributes for a given Service Provider, so to enable successful authentication on the Service Provider, plus possible additional required authorization attributes.

If the user is connecting via her/his eduGAIN IdP and the user is also found to exist in CTA [ using ePPN ] .

A detailed description can be found in this wiki page.

1. The intended AARC AAI setup consists of:
2.  eduGAIN IDPs and CTA IDP
3. SATOSA central proxy component
4. Microservice running on the SATOSA proxy to query COmanage via API
5. As an alternative to component 4, a user DB on board of the proxy can be used ( option to be evaluated)

Components

CTA Pilot use different components to achieve its goal:

Architecture

Image Added

Use Cases

First access to a CTA Science Gateway SP

Access to CTA SP with an approved CO person

CTA Administrator approve user petition 

CTA Administrator links identities