We'll be expanding the list of identity providers (IdPs) at cilogon.org in September 2016 to include an initial set of international (eduGAIN) IdPs and all InCommon IdPs.
One of the goals of the CILogon 2.0 project is to improve CILogon's support for international research collaborations by supporting international IdPs. Following a TAGPMA policy review in July, CILogon is now ready to begin accepting international IdPs that support the REFEDS Research and Scholarship (R&S) category and the REFEDS Security Incident Response Trust Framework for Federated Identity (Sirtfi). The R&S and Sirtfi prerequisites are in place to satisfy IGTF traceability and uniqueness requirements. Initially this will enable CILogon to support the CERN, Nikhef, and Uppsala Universitet IdPs, which are early adopters of Sirtfi, with more to follow soon. InCommon is also beginning a Sirtfi Proof of Concept effort.
Currently cilogon.org lists over 180 InCommon IdPs. This IdP list has grown steadily since the CILogon service began operation in 2010, as illustrated in the following chart.
These InCommon IdPs have declared support for the Research and Scholarship category and/or have used the "Add Your IdP" button at https://cilogon.org/testidp/. This represents a subset of the over 400 IdPs operated by InCommon participants. We originally restricted CILogon's IdP list to this subset in an effort to avoid errors such as missing user attributes (i.e., the user's name and email address). However, restricting the IdP list failed to eliminate the errors for a variety of reasons, including differing attribute management policies/procedures across different user categories (faculty, staff, students, alumni, affiliates, etc.). It also made it more difficult for users from other IdPs to log on to CILogon, since they wouldn't find their IdP on the list and would be unsure about using the "Add Your IdP" button.
Therefore, acting on advice from InCommon and REFEDS participants, we've decided to begin listing all InCommon IdPs at cilogon.org, to make it easier for users to attempt to log on with their home IdP. In case of missing user attributes or other problems, we've updated the CILogon error page to provide a link for users to report the problem directly to their IdP operators:
In many cases, the IdP operators can resolve the problem working directly with the user without requiring CILogon operators in the middle. However, firstname.lastname@example.org is also copied on each message, and we're always glad to help. For CILogon to scale up to hundreds of IdPs, it's important for us to enable self-service troubleshooting by users and IdP operators. The https://cilogon.org/testidp/ page provides additional troubleshooting information.
Any comments or questions? Please contact us at email@example.com.
On February 13, Globus released their new enhanced login method that supports InCommon campus identities via CILogon's OIDC interface. Now Globus users do not need to create a separate Globus username and password for access to Globus services. Instead, Globus users can select their campus identity provider directly from the Globus login screen, taking advantage of CILogon OIDC's new
CILogon's new OpenID Connect (OIDC) interface enables cyberinfrastructure (CI), such as Jetstream (via Globus Auth) and Ocean Observatories Initiative, to support federated authentication with InCommon identity providers via a standard, RESTful API. OIDC is a simple authentication layer built on the OAuth 2.0 standard that enables CI to easily connect to CILogon using standard client software (such as mod_auth_openidc).
CILogon's OIDC interface includes an optional getcert endpoint for cases that require X.509 certificates. Otherwise, CILogon clients can use standard OIDC tokens and the standard OIDC userinfo endpoint for authentication without needing to generate RSA keys and X.509 certificate requests or parse X.509 certificates. We believe this is a significant improvement over CILogon's existing OAuth 1.0 interface, in terms of both performance and simplicity, and we encourage CI operators using CILogon's OAuth 1.0 interface to upgrade to OIDC.
Obtaining user consent prior to release of personal information is an important component of CILogon's OIDC interface. CILogon supports multiple scopes to allow clients to request only the information they need. The CILogon consent screen (example below) informs users about what information is being requested by whom. CILogon staff manually review each client registration to ensure that CILogon's OIDC interface is only used by cyberinfrastructure in support of academic research.
We are pleased to announce that the CILogon 2.0 project officially launched on January 1, 2016. The project integrates and expands on the existing open source CILogon and COmanage software to provide an integrated identity and access management (IAM) platform for cyberinfrastructure. The platform combines the federated identity management capabilities of CILogon with the collaborative organization management capabilities of COmanage, with an emphasis on supporting international research collaborations via eduGAIN. The 3 year project, funded by NSF award number 1547268, is a collaboration between NCSA and Spherical Cow Group.
The project team recently met at NCSA for our project kick-off meeting:
As illustrated in the design diagram below, the CILogon 2.0 platform will integrate multiple identity sources (InCommon, eduGAIN, Google, ORCID) and support multiple IAM interfaces for science applications (X.509 certificates, OpenID Connect claims, SAML assertions, LDAP attributes).
Recently, the InCommon identity providers (IdPs) at Clemson University and University of Utah enabled support for SAML ECP ("Enhanced Client or Proxy"), which allows for the exchange of SAML attributes outside the context of a web browser. ECP support is very useful for non-browser cyberinfrastructure applications, such as shell-based access to campus computing clusters. CILogon staff worked with the Clemson and Utah IdP operators to verify that their IdPs' ECP support successfully enables access to CILogon certificate issuance outside the browser. In our experience, enabling ECP in current Shibboleth IdP deployments is a relatively straightforward process. This collaborative effort around SAML ECP was supported in part by the FeduShare project (NSF award 1440609), which is designing a system architecture supporting self-managed collaboration and federation of services for scientific research.
In addition to Clemson and Utah, the list of ECP-enabled IdPs working with CILogon includes: LIGO Scientific Collaboration, LTER Network, University of Chicago, University of Illinois at Urbana-Champaign, University of Michigan, University of Washington, and University of Wisconsin-Madison. If you'd like to use SAML ECP with CILogon, please contact us at firstname.lastname@example.org.
XSEDE Operations completed acceptance testing of CILogon on January 5 2015 and accepted CILogon for production. Please see http://www.cilogon.org/xsede for details about how XSEDE uses CILogon. CILogon has been in production at NCSA since 2010 and is enabling access to cyberinfrastructure such as Globus, LIGO, and OSG Connect. Acceptance by XSEDE is another milestone in CILogon adoption and operational maturity. The XSEDE engineering process included design and security reviews, functional testing, and the deployment of a backup CILogon instance at NICS for improved reliability. All CILogon users now benefit from the operational improvements to CILogon resulting from this XSEDE effort.
In response to the SSLv3 POODLE vulnerability, we have disabled support for SSLv3 at https://cilogon.org/. TLS is now required for access. We do not see any recent use of SSLv3 in our logs, so we do not expect this change to cause compatibility problems for CILogon users. We have also updated our cipher list according to the latest Mozilla Server Side TLS Guidance and have enabled HTTP Strict Transport Security (HSTS). As always, please contact email@example.com if you experience problems or have questions/comments.
CILogon (https://cilogon.org/) has migrated from OpenID 2.0 to OpenID Connect for the Google identity provider, per Google's recommendations. When CILogon users log on using Google identities, CILogon links existing OpenID 2.0 identities with OpenID Connect subject identifiers to ensure a seamless transition, with no changes to the resulting CILogon certificate subject distinguished names for current CILogon users.
As part of this migration, CILogon has removed support for the remaining OpenID 2.0 identity providers (PayPal and Verisign), which were used (primarily for testing purposes) by a very small number of CILogon users. Removing OpenID 2.0 support from the CILogon code base helps us simplify our operations and software maintenance.
Google is still CILogon's most popular identity provider, but a growing percentage of CILogon users are choosing InCommon identity providers instead. 18% of current CILogon users choose to use Google identities, down from 25% a year ago and 36% two years ago. The number of InCommon identity providers available to CILogon users has more than doubled over the past two years, from under 50 identity providers at the start of 2012 to over 120 identity providers today, thanks in large part to the InCommon research and scholarship program.
As always, please contact firstname.lastname@example.org with any questions or comments.
The CILogon project does not plan to renew its subscription to the ProtectNetwork identity provider (IdP) service in 2015 because of a significant price increase. Users who log on to https://cilogon.org/ using the ProtectNetwork IdP will now see a banner message encouraging them to switch to a different IdP by the end of the year. Thanks in part to the InCommon Research and Scholarship program, CILogon now supports over 130 InCommon IdPs. If your campus IdP doesn't yet work with CILogon, please let us know.
We are very appreciative of the service that the ProtectNetwork IdP has provided to CILogon over the years. ProtectNetwork's support for SAML ECP has been very helpful for developing and demonstrating CILogon's support for federated authentication outside the browser. ProtectNetwork has been a valuable "IdP of Last Resort" (IdPoLR) for users whose campus IdP isn't working with CILogon yet. Now the Google IdP fulfills the IdPoLR role for CILogon.
The importance of having an IdPoLR was highlighted in the 2011 Roadmap for Using NSF Cyberinfrastructure with InCommon, and the next IAM Online (Wednesday August 13) will discuss launching a new InCommon IdPoLR working group. The CILogon project will continue to explore IdPoLR options (in addition to Google) in parallel with our ongoing efforts to support additional InCommon IdPs.
Any questions or comments? Please contact email@example.com.
igtf.net). The CILogon Basic Certification Authority is now an IGTF accredited Identifier-Only Trust Assurance (IOTA) provider. As discussed in a previous news item, this new accreditation enables CILogon to provide IGTF certificates to users from all InCommon identity providers, not just InCommon Silver identity providers. As a result, CILogon certificates can now be used more broadly for access to XSEDE service providers as documented at http://www.cilogon.org/xsede.