...
Each member of the LSC is assigned an albert.einstein identity and they manage this account and their credentials via the my.ligo.org application. This pilot aims to investigate the infrastructure and organisational changes required to support the increased use of federated institutional entities alongside existing internal credentials. In particular it will identify technological components and deploy a pilot service to be used for evaluation. It will also work to understand the current limitations of federated identities as applied to the LSC, and recommend alternative approaches where relevant.
SAML proxies are increasingly being used to easily connect all of resources within a collaboration 's resources into the eduGAIN network federation and this would demonstrate it's success application for a large, established collaboration.
...
The goal of this AARC project is design and deploy a pilot SAML proxy instance so that LSC users can make better use of would allow users to use their Institutional Identities in a federated manner. SAML proxies are increasingly being used to easily connect all of a collaboration's resources into the eduGAIN network and this would demonstrate it's success for a large, established collaboration. It It will also investigate the limitations of a SAML proxy and recommend alternatives alternative solutions to these issues. Finally, we will look at other areas where the SAML proxy can be utilised.
Description
Following discussions within the LSC it was decided that the pilot will would deploy SATOSA and pyFF to create a SAML proxy between the eduGAIN institutional identity providers and the LSC's service providers. This would allow LSC and Virgo members to use their institutional credentials to access LSC resources directly. Institutional identies identifies would be mapped to a user's albert.einstein identity via an a internal account linking, and LIGO specific information; in particular group and identity information would be used to annotate the account. SATOSA will act as the central SAML Proxy of the project, while pyFF will be used to aggregate SAML metadata from Edugain EduGAIN and the LSC, and also provide the discovery service interface.
Components
| Component | Description | Technology |
|---|
- Metadata Aggregator: PyFF
- Discovery Service: PyFF
- Account Linking: COManage
Architecture
SATOSA
| Why did we choose it | |||
|---|---|---|---|
| SAML Proxy | SAML IdP to SAML SP Proxy | SATOSA | Popular Python based package that includes services for adding attributes from external source |
| Metadata aggregation | Aggregate and process SAML metadata from multiple sources | PyFF | Popular Python based package that allows you to customise SAML metadata processing and also supports Metadata Query Service |
| Discovery Service | Present list of IdPs to user | PyFF | PyFF already used to aggregate metadata, and includes a good, theme-able discovery service interface |
| Attribute Store | Source of additional user attributes and group membership | Grouper + LDAP | LSC user group membership and extended attributes already managed and stored in Grouper |
| Account Linking Service | Link institutional IdP identity to LSC user identity | COManage | COManage provides workflows for linking accounts and is already used with the GW Astronomy community for collaboration management. |
Architecture
Use Cases
Successful
...
PyFF Discovery Service
Use Cases
Federated Identity Login
| Step | Action | Screenshot |
|---|---|---|
| 1 | Visit SP Website and select Satosa SAML Proxy from the list of IdPs |
|
| 2 | Select Home IdP from DS |
|
| 3 | Login at Instituional Institutional IdP |
|
| 4 | Access SP |
|
This section should explain how this pilot works through use cases (at least 2).
Link Federated Identity
| Step | Action | Screenshot |
|---|---|---|
| 1 | Visit SP Website and select Satosa SAML Proxy from the list of IdPs |
|
| 2 | Select Home IdP from DS |
|
| 3 | Login at Institutional IdP |
|
| 4 | Account Linking |
|
| 5 | Access SP |
|
Results
A pilot instance was deployed
Use cases can be represented in the form of a table, where:- The title is the use case
- Each line is a step
- 2 columns available, first with text and description, second with a screenshot
(Here's a valid example LINK)
Results
A Pilot instance has been deployed and has been registered in the eduGAIN metadata and is undergoing testing.
Further information
Provide some description related to BPA. Was BPA useful to achieve this results? how?
About sustainability:
- will this pilot survive after AARC?
- If yes, how?
- if no, why?
Last part contain a list of information, link or anything related to the pilot that was not mentioned in ahead seciton.
underwent extensive testing using a number of existing LSC resources. Within the pilot, account linking between institutional identities and a user LSC identity was performed using a manual administration step.
Limitations
There are two areas where the use of federated identities is limited. Firstly, the the LIGO detectors are situated in remote locations loss of access to the internet are common and it would be impossible for anybody working thereto connect to their home IdPs. Therefore, people working at or visiting the detectors will need to continue to use their LSC credentials and the local IdP replicas. Secondly, the LSC rely on X509 certificates to access compute clusters and other resources. Most users obtain their certificates from the CILogon service using the ligo-proxy-init command line tool which uses SAML ECP to obtain a certificate without a web browser. Although some institutional IdPs support ECP this is severely limited, and not expected to improve. Therefore, for users who require this they will still require a dedicated password to access this resource via the LIGO IdP.
Sustainability
Going forward an instance of COManage will be deployed to handle the account linking workflow, and as well as more aspects of user management. To move the pilot into production the SATOSA and PyFF services must be deployed in a fault tolerant manner. The LSC has recently deployed a fault tolerant instance of the main Identity Provider, and we will be take a similar approach to deploy thisLast part contain a list of information, link or anything related to the pilot that was not mentioned in ahead seciton.