ID Management Discussion #1: CILogon and COManage

Federated Identity Authorization and Management in Large Cyberinfrastructure Facilities

As part of a new Community of Practice feature, we will be posting a brief overview of various technologies designed to help large CI facilities manage various aspects of their operations. For the next few months we will be focusing on Identity Management. The first such platform we will be looking at is CILogin and its management platform, COManage.

CILogin and COManage

CILogin

CILogin is an integrated open source and idenity access management platform designed for research collaboration. Together with COManage it enables researchers to offload IAM to a third party. Both CILogin and COManage are a part of Internet2’s InCommon Initiative, partnering with InCommon and Shibboleth to provide federated identity management at scale for higher education and research.

CILogon leverages both the federated identity management of Incommon and Shibboleth, with collaborative organization management to allow collaborative organizations to share resources across institutions using single sign on (SSO). CILogon currently supports over 2500 identity providers, including campus providers, GitHub, Google and ORCID.

CILogon is built using the ARCC Blueprint Architecture which separates services into five component layers by function.

  1. User Identity Services - these are services which provide electronic identification to users (e.g. X.509, OAuth2 (OIDC), eGov, ORCID, Globus, etc.)
  2. Community Attribute Services - an additional layer for managing and sharing attributes attached to electronic identities, in addition to what is provided by the layer 1 services. (e.g. Reputation services, AUP, and other attribute authorities such as Oauth2, SAML, etc.)
  3. Access Protocol Translation Services - defines the administrative, policy, and technical boundaries between internal and external services and providers/resources. (e.g. discovery services, tokens, X.509 certificates, JSON Web Tokens, etc.)
  4. Authorization Services - community maintained repositories for policies.
  5. End-Services - where the resources and other external services interact with the other four layers.

CILogon is operated by XSEDE and is funded via a non-profit subscription model, to learn more please visit https://www.cilogon.org/subscribe, and https://www.cilogon.org/faq.

COManage

COManage combines an identity management registry and a suite of API/interface tools for connecting with the CAS resources maintained in the registry to allow participating organizations to share resources with other organizations or individuals using Virtual Organizations (VOs).

Virtual Organizations are collections of defined organizations or individuals collaborating on specific resources with authorization requirements. Once a collaborative organization(CO) or VO has been defined, they may create an enrollment process to gather identity attributes for the registry to grant access to shared resources among the members. This is done using their library of API tools or other ID tokens, such as X.509 or JWT. COManage also allows COs/VOs to store attribute information in an LDAP directory.

COManage can collect audit information and usage data, as well as provide service notifications to their COs/VOs. COManage also allows for the revocation and expiration of federated identity tokens and attributes. COManage provides information to its members via a dashboard, and maintains a community wiki for the development and support of their interfaces. For a list of example use cases of COManage and CILogon see the Use Case Library on the COManage Wiki.

Discussion

Please reply and let us know what you are using for identity management on your platforms. What are some of the problems you are facing or have solved in IAM in the past year?

Please feel free to share and ask questions, and check back on Dec 4th for our next post on Oauth2 and OIDC!

At OSC we are using Keycloak as an identity provider for OSC LDAP and an identity broker to let the user choose between CILogon or OSC LDAP credentials when they log into OnDemand. If they choose CILogon, the first login flow requires a one time second login with their HPC credentials in order to map CILogon distinguished name to the HPC account.

A drawback is that Keycloak currently only allows storing 1 mapping per user between CILogon and the HPC account, so once a user logs in through CILogon with one institution, they cannot then login through another institution. We catch this error and also enable users to delete their mapping if they want to change this. I’m happy to share more details if anyone is interested.

3 Likes