What are the software and service requirements for SPs to support authorization policy definition, configuration, operation/enforcement, logging, etc., to implement policies that differentiate among credentials presented to GSI(?) or other services?
© ACCESS All Rights Reserved.
ACCESS is an advanced computing and data resource supported by the
National Science Foundation
and made possible through these lead institutions and their partners:
Carnegie Mellon University,
University of Colorado Boulder,
University of Illinois at Urbana-Champaign, and
State University of New York at Buffalo .
Hi Derek,
Thanks for the question. I'll be sure to answer it in the Design document when I write it.
-Jim
Unless I missed it, the design document doesn't address Derek's question. On the other hand, the design doc seems limited to covering the changes in the CILogon Silver service itself, and doesn't say anything about: (a) changing any authentication services to use the CILogon Silver CA, (b) telling users how to get certs from the CILogon Silver CA, or (b) changing any applications to require certs from the CILogon Silver CA. In other words, the design doc doesn't seem to be scoped to cover this topic.
Personally, I think it's reasonable for this activity to limit itself to the changes to CILogon. If it makes sense to, we can definitely have a separate activity that builds on this one to tighten the security requirements in X.509 services. (Just to be clear, I think the services that could use this would be GridFTP and SSH, right?)
I am also thinking of other web services that may wish to require CILogon Silver for (federated?) authentication.
Thanks Lee for the reminder and sorry Derek I neglected to address this in the design doc as I had promised to do.
I think I'll document it in the "Interface Design" section. I'll post an update here when I've drafted it.
Here's the text I've added to v1.1 of the design doc (Section G):
G. Interface Design
CILogon Silver interfaces are documented at https://www.cilogon.org/faq and https://ca.cilogon.org/policy/silver, and CILogon’s OIDC “acr” support is documented at https://www.cilogon.org/oidc.
G.1 User Interface
To obtain a certificate from the CILogon Silver CA, users log on at https://cilogon.org/ using the XSEDE identity provider (or another identity provider that supports the required higher level of assurance). After logging on, they will see "Level of Assurance: Silver" indicated at the top of the page. They can then enter a password for protecting their private key and click the "Get New Certificate" button. This will provide a link to the certificate, which they can select with their right mouse button to download to their computer.
Users will see "Level of Assurance: Basic" if their authentication attributes from their identity provider do not meet the Silver Policy requirements. To check their attributes, they can visit https://test.cilogon.org/testidp/ and Log On. In the list of SAML Attributes shown, they should confirm that Level of Assurance contains https://refeds.org/assurance/profile/cappuccino and AuthnContextClassRef contains https://refeds.org/profile/sfa or https://refeds.org/profile/mfa. If it doesn't, they should look in the list of Metadata Attributes for the Support Contact for your identity provider and contact them for assistance. In the case of the XSEDE IdP, Level of Assurance will contain https://refeds.org/assurance/profile/cappuccino only if the user is on an active allocation as shown at https://portal.xsede.org/allocations/usage.
G.2 Admin Interface
Administrators making custom configurations for the CILogon Silver CA should be familiar with the Grid Security Infrastructure (GSI) configuration options for the software in question.
G.2.1 Default Configuration
The CILogon Silver CA is already included in the XSEDE and IGTF certificate packages, so for resource providers that have installed one of these packages, no configuration update is needed to accept CILogon Silver certificates. Certificates from the CILogon Silver CA will contain the following Issuer DN:
/DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Silver CA 1
For comparison, certificates from the CILogon Basic CA will contain the following Issuer DN:
/DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Basic CA 1
Certificate subject DNs for both CAs have a prefix of “/DC=org/DC=cilogon/”. For example, certificates for XSEDE users have subject DNs of the following form:
/DC=org/DC=cilogon/C=US/O=XSEDE/CN=EndEntityName UniqueSerialNumber
For example:
/DC=org/DC=cilogon/C=US/O=XSEDE/CN=Jim Basney C47983
A user’s Subject DN does not change when migrating between the CILogon Silver and CILogon Basic CAs, so if a user is added to an XSEDE allocation and thus becomes eligible for a CILogon Silver certificate, then the allocation ends and thus the user is only eligible for a CILogon Basic, the user’s DN will remain the same even though the CA (and Issuer DN) changes.
G.2.2 Requiring a Higher LOA
Services requiring a higher level of assurance may choose to accept certificates from the CILogon Silver CA (IGTF MICS) but not the CILogon Basic CA (IGTF IOTA) by only including the CA certificate of the former but not the latter in /etc/grid-security/certificates.
For example, to install only Classic, MICS, and SLCS CAs from IGTF Debian packages (https://dist.igtf.net/distribution/igtf/current) do:
apt-get install ca-policy-igtf-classic ca-policy-igtf-mics ca-policy-igtf-slcs
apt-get remove ca-policy-igtf-iota
Or to only install the CILogon Silver CA do:
apt-get install ca-cilogon-silver
On CentOS, to install only Classic, MICS, and SLCS CAs from IGTF packages (https://dist.igtf.net/distribution/current/) do:
yum install ca_policy_igtf-classic ca_policy_igtf-slcs ca_policy_igtf-mics
yum remove ca_policy_igtf-iota
Or to install only the CILogon Silver CA do:
yum install ca_cilogon-silver