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.
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:
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:
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.
Overall the work carried out within the pilot consisted of :
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:
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.
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.
In this way, all previously existing CTA users have their identity in COmanage and 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:
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.
CTA Pilot use different components to achieve its goal:
| Name | Link | Description | Why |
|---|---|---|---|
| Grouper | https://www.internet2.edu/products-services/trust-identity/grouper/ | Grouper is an enterprise access management system designed for the highly distributed management environment and heterogeneous information technology environment common to universities. Operating a central access management system that supports both central and distributed IT reduces risk. | |
| COmanage | |||
| SaToSa |
| 1. | Access to CTA Science Gateway to perform scientific analysis of CTA DATA |
|
| 2. | The user is redirected to the Discovery Service embedded into the SAtoSA proxy |
|
| 3. | User select an IdP and login with his own credential |
|
| 4. | User submit a petition to CTA Administrator to enroll to the collaboration |
|
| 5. | The user should wait for the approval from the CTA Administrator |
|
| 1. | Access to CTA Science Gateway to perform scientific analysis of CTA DATA |
|
| 2. | The user is redirected to the Discovery Service embedded into the SAtoSA proxy |
|
| 3. | User select an IdP and login with his own credential |
|
| 4. | Overview of attributes being shared (to authenticate and perhaps authorize). |
|
| 5. | The user is successful redirected to CTA Analysis tools |
|
| 1. | CTA Administrator access to COmanage registry to approve CO petition |
|
| 2. | CTA Administrator view CO Petition and click "Approve" to confirm user self-signup to the collaboration |
|
| 4. | CTA Administrator add the user to the proper Groups |
|
| 1. | User ask to CTA Administrator to link a CTA identity with a non CTA identities | |
| 2. | CTA Administrator access to COmanage registry |
|
| 3. | CTA Administrator select to relink the non CTA Organizational Identities |
|
| 4. | CTA Administrator select the User CTA Identity to link with |
|
| 5. | Now the 2 Oranizational Identities are linked in the same CO Person |
|
Given the positive result of the pilot, CTA is evaluating the possibility of moving this pilot from the experimental phase to production, maintaining it and offering this service to the whole community.
