AUSTRALIAN ACCESS FEDERATION
Introduction
The AAF, with several Australian research communities, is piloting a capability to manage and enable cross-organisational collaborations. To assist these research communities, the AAF has partnered with CILogon (https://www.cilogon.org/) to support the CILogon platform. CILogon is an integrated open source identity and access management platform for research collaborations, combining federated identity management (Shibboleth, InCommon) with collaborative organisation management (COmanage). Federated identity management enables researchers to use their home organisation identities to access research applications, rather than requiring yet another username and password to log on. Collaborative organisation management enables research projects to define authorisation groups for access to collaboration platforms (e.g., wikis, mailing lists, web and domain applications). CILogon implements the AARC Blueprint Architecture.
To assist Australian research organisations to become familiar with the federated identity management capability, the AAF is publishing this Q&A. The responses have been written in collaboration with the CILogon developers team.
Background
CILogon is an identity management service that can integrate with upstream and downstream identity management systems for managing cross-organisational identities. One approach to onboard users to CILogon is via a registration or invitation process that allocates roles during the enrollment process. These enrollment processes can automatically onboard new community members or can be configured to require review and approval by an administrator.
CILogon can also provision accounts directly to downstream services and can receive identity data on a periodic basis (either manually or via a scheduled job) from upstream Systems Of Record (SOR). Data objects used to create new Organisational Identities from the SOR and are known as Organizational Identity Sources (OIS).
https://spaces.at.internet2.edu/display/COmanage/Organizational+Identity+Sources
COmanage Registry includes plugins for the following OIS:
- LDAP directory
- REST API
- CSV files
- netFORUM
- Novi
- ORCID
- Salesforce
Usually the OIS is configured to use a Pipeline: https://spaces.at.internet2.edu/display/COmanage/Registry+Pipelines
The Pipeline creates the CO Person record from the Organisational Identity via the OIS. See the link above for a diagram explaining the process. Both onboarding and import processes can allocate additional identifiers and attributes to the user identities. The Identifiers are created when the new CO Person is created, at the end of the Pipeline.
CILogon extends the COmanage service https://spaces.at.internet2.edu/display/COmanage/Home, and can integrate with the InCommon platform Grouper if necessary. Grouper is available with full service subscriptions.
Q&A
Last updated 6 June 2022
- Are the pilot projects using AAF's subscription to CILogon, or do they have their own subscription?
- Each community has a separate full-service subscription (https://www.cilogon.org/subscribe) to CILogon. AAF has entered into the contracts with CILogon to aggregate the demand and pass the costs through with separate contracts. In effect, each project is paying for a full service subscription.
All projects are currently in development or pilot phase but all subscriptions include separate Test and Production instances.
- Each community has a separate full-service subscription (https://www.cilogon.org/subscribe) to CILogon. AAF has entered into the contracts with CILogon to aggregate the demand and pass the costs through with separate contracts. In effect, each project is paying for a full service subscription.
- The service is hosted by a third-party, is the user/group info going off-shore as a result, until a national instance is in place?
- During these pilot projects, the service is hosted on a dedicated instance within a US AWS region. AAF is working toward contract terms to deliver CILogon via AWS Sydney for Australian customers. This partially depends on achieving a large enough customer base to justify the investment.
- During these pilot projects, the service is hosted on a dedicated instance within a US AWS region. AAF is working toward contract terms to deliver CILogon via AWS Sydney for Australian customers. This partially depends on achieving a large enough customer base to justify the investment.
- Is there a timeframe that the AAF would like to have something in place … sometime in 2023 or beyond?
- Variables outside of our control make this impossible to predict but 2023 is not out of the question.
- Variables outside of our control make this impossible to predict but 2023 is not out of the question.
- Does the User login to CILogon’s dashboard to then launch a service with the attributes flowing through to the service about who is invoking the service, OR does the service redirect someone to CILogon (to login) and then gets all the attributes to make authorisation decisions as a result of a successful logon?
- CILogon is integrated with an OIDC proxy and discovery service (for access from AAF and eduGAIN federations) that enables browser redirects to home org for user authentication and back to CILogon to collect claims (that include user identifiers) that can support on demand user provisioning at a target service. CILogon can also be queried on a schedule to retrieve information for pre-provisioning user accounts to a service using a REST API or an LDAP query or an intermediate database.
COmanage Registry also includes a "dashboard" capability in order to offer a limited "portal" experience.
See https://spaces.at.internet2.edu/display/COmanage/Registry+Dashboards
and https://spaces.at.internet2.edu/display/COmanage/Services+Widget+Plugin
A Collaborative Org (CO) admin can set up a dashboard to include the services widget and for each service, usually an icon and a clickable link. The link takes the user to the service. Note that authentication is NOT pushed as part of that link. The application/service still needs to begin the OIDC (or SAML) flow, however since the user has already authenticated to access the COmanage Registry dashboard, SSO is active.
User registration can be made fairly transparent and seamless during the initial user login to onboard a new user on first access, if necessary.
- CILogon is integrated with an OIDC proxy and discovery service (for access from AAF and eduGAIN federations) that enables browser redirects to home org for user authentication and back to CILogon to collect claims (that include user identifiers) that can support on demand user provisioning at a target service. CILogon can also be queried on a schedule to retrieve information for pre-provisioning user accounts to a service using a REST API or an LDAP query or an intermediate database.
- Are Roles customisable for a service?
- Yes, roles are customisable for a service and supports more than one role per account. CILogon can also integrate with InCommon's Grouper service (https://incommon.org/software/grouper/) to further extend CILogon's group and role capability and provide an alternate admin and user dashboard UI.
- Yes, roles are customisable for a service and supports more than one role per account. CILogon can also integrate with InCommon's Grouper service (https://incommon.org/software/grouper/) to further extend CILogon's group and role capability and provide an alternate admin and user dashboard UI.
- If a User can have more than one Role for a project (Group) is there a way to identify which Role they want their persona to be for a session, or does the service need to determine that a user on a project has more than one role, and then get them to choose which one they are acting in for the session?
- A: Roles are aggregated for a persona/identity on a per service basis. User access to a different administrative end-point URL could be the basis for allocating an admin role for managing a service. If there is a need to implement this "separation of duties" approach, then I'd need a better understanding of your requirements and any constraints on the user experience to discuss with Scott and the CILogon team, to provide an answer to this question.
However, another option available in this situation is for a user to register two different identities (from two organisations or identity providers) into CILogon and each would be allocated a specific role. For more info, refer to the COmanage Registry Data Model https://spaces.at.internet2.edu/display/COmanage/Registry+Data+Model
- A: Roles are aggregated for a persona/identity on a per service basis. User access to a different administrative end-point URL could be the basis for allocating an admin role for managing a service. If there is a need to implement this "separation of duties" approach, then I'd need a better understanding of your requirements and any constraints on the user experience to discuss with Scott and the CILogon team, to provide an answer to this question.
- Will the service be able to get assertions on identity and whether MFA was used during the login process from the CILogin attributes, or is it obfuscating that? E.g. I can link a second identity to my “user” CILogon account that does not have MFA enforced, and use that to login rather than an MFA-enforced account to access a service. If the service needs to ensure MFA was used, will it be able to tell and take appropriate action if it was not.
- CILogon does not store MFA signaling information. CILogon asserts its own identifiers and forwards those and the attributes and assertions that the user's login identity provider asserts during the login flow. If REFEDs MFA (https://wiki.refeds.org/display/PRO/Introducing+the+REFEDS+MFA+Profile) is signaled by the upstream SAML IdP then CILogon will pass it through in either the SAML assertion or OIDC claims it sends to the service. Note that the social providers (Google, GitHub, Azure/Microsoft) do NOT signal MFA and consequently CILogon cannot forward a signal.
The target service would then be responsible for determining if MFA was signaled and whether or not to allow access based on the presence or absence of the signal.
The AAF is working towards enabling REFEDs MFA signaling in the federation and passing that through to services. We expect to implement support in the second half of 2022 but AAF subscribers will need to implement changes to their IdP before this data can flow to service providers / relying parties.
Not ideal and an implementation of last resort - a target service could manage its own MFA user registrations for access to itself.
- CILogon does not store MFA signaling information. CILogon asserts its own identifiers and forwards those and the attributes and assertions that the user's login identity provider asserts during the login flow. If REFEDs MFA (https://wiki.refeds.org/display/PRO/Introducing+the+REFEDS+MFA+Profile) is signaled by the upstream SAML IdP then CILogon will pass it through in either the SAML assertion or OIDC claims it sends to the service. Note that the social providers (Google, GitHub, Azure/Microsoft) do NOT signal MFA and consequently CILogon cannot forward a signal.
- I note there is an API to push users/groups etc. into CILogon via the REST API from external services. So we could have a management platform that scribbles things into a local DB as the source of truth and syncs the config reflection to CILogon via the API. Is that right?
- That's correct. CILogon can use the REST API to read/write into a service/database that supports that method.
- That's correct. CILogon can use the REST API to read/write into a service/database that supports that method.
- How would an Active Directory environment leverage CILogon?
- A: CILogon can update an external database or an LDAP repository. An intermediate service can query these datastores to retrieve and transform this info to feed an AD user/group provisioning process. As noted above, there is an LDAP OIS, so an existing Active Directory service could theoretically also be able to act as an upstream SOR.
To enable CILogon to write directly to AD would require a custom LDAP Schema Plugin https://spaces.at.internet2.edu/display/COmanage/LDAP+Schema+Plugins and changes to the AD service, since the CILogon LDAP Provisioner assumes some standard objectClasses that are not available within a standard AD deployment. Probably not worth the effort if the existing AD user management tools source user info from an existing datastore.
- A: CILogon can update an external database or an LDAP repository. An intermediate service can query these datastores to retrieve and transform this info to feed an AD user/group provisioning process. As noted above, there is an LDAP OIS, so an existing Active Directory service could theoretically also be able to act as an upstream SOR.