Embedded Files
Frequently Asked Questions (FAQ)
Frequently Asked Questions (FAQ)
When I log on at https://cilogon.org/, why do I see "Level of Assurance: Basic" rather than "Level of Assurance: Silver"?
Users will see "Level of Assurance: Basic" if their authentication attributes from their identity provider do not meet the CILogon Silver CA's policy requirements. To check, visit https://test.cilogon.org/testidp/ and Log On. In the list of SAML Attributes shown, 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, look in the list of Metadata Attributes for the Support Contact for your identity provider and contact them for assistance.
How do I configure my IdP so that my users can obtain CILogon Silver certificates?
Set an eduPersonAssurance attribute containing the value https://refeds.org/assurance/profile/cappuccino in the SAML authentication assertion to indicate that the assertion has been issued under the conditions of the Cappuccino profile defined in the REFEDS Assurance Framework.
Set the SAML AuthnContextClassRef value to https://refeds.org/profile/sfa or https://refeds.org/profile/mfa in the SAML authentication assertion to indicate that the assertion has been issued under the conditions of either the REFEDS Single Factor Authentication Profile or the REFEDS Multi Factor Authentication Profile.
What if only a subset of my IdP's users meet the REFEDS Cappuccino level of assurance?
It is not necessary for all your users to meet the REFEDS Cappuccino requirements. Set the eduPersonAssurance and AuthnContextClassRef values for the users that do, and they will be able to obtain CILogon Silver certificates. Your other users may obtain CILogon Basic CA certificates instead.
Where can I find more information about REFEDS Cappuccino?
While https://refeds.org/assurance/profile/cappuccino is the attribute value for indicating compliance with the Cappuccino profile in the REFEDS Assurance Framework, there is no web page at that location. Please visit https://refeds.org/assurance for information about the REFEDS Assurance Framework including the Cappuccino profile.
How does REFEDS Assurance relate to IGTF Assurance?
The REFEDS Assurance Framework contains explicit mappings to IGTF Assurance for identity proofing. REFEDS "low" maps to IGTF DOGWOOD and IGTF ASPEN, and REFEDS "medium" maps to IGTF BIRCH and IGTF CEDAR. Since the CILogon Silver CA is an IGTF MICS CA, it requires the IGTF BIRCH level of assurance, corresponding to REFEDS "medium" which is part of the Cappuccino profile defined in the REFEDS Assurance Framework.
Do I need to change my system configuration to accept CILogon Silver certificates?
The CILogon Silver CA is already included in the 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/”.
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 becomes eligible for a CILogon Silver certificate, then later is only eligible for a CILogon Basic, the user’s DN will remain the same even though the CA (and Issuer DN) changes.
How do I configure my system to require CILogon Silver certificates?
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
Revision History
Revision History
1.3.6.1.4.1.34998.1.1.14 (Mar 16 2021): Modifications to Section 5.1 (Physical Controls) to allow cloud operation of the CILogon web front-end.
1.3.6.1.4.1.34998.1.1.13 (Nov 6 2018): Updates to address TAGPMA review: add support for standard IGTF Robot DNs (Section 3.1.1), require REFEDS SFA/MFA authentication profile in combination with Cappuccino (Section 3.2), and archive snapshots of InCommon/eduGAIN metadata (Section 5.4.1).
1.3.6.1.4.1.34998.1.1.12 (Oct 15 2018): Replaced references to InCommon Silver Identity Assurance Profile with references to REFEDS Assurance Framework’s Cappuccino Profile (Section 3.2). Allow identification and authentication of certificate applicants via eduGAIN (Section 3.2.2). Support Robot certificates (Section 3.1.1). Document use of OAuth for grid portals (Section 4.1.2). Add E-mail Protection to X509v3 Extended Key Usage certificate extension (Section 7.1.2).
1.3.6.1.4.1.34998.1.1.11 (Dec 3 2014): Minor updates for InCommon Silver Identity Assurance Profile v1.1. Increase CRL validity period from two weeks to 30 days (Section 2.3). Added ORNL site information (Section 5.1).
1.3.6.1.4.1.34998.1.1.10 (Feb 3 2011): Further clarify process for CA generation of subscriber private keys.
1.3.6.1.4.1.34998.1.1.9 (Jan 12 2011): Allow CA generation of private keys (for TAGPMA discussion).
1.3.6.1.4.1.34998.1.1.8 (Dec 14 2010): Added SHA-2 hash functions per NIST Policy.
1.3.6.1.4.1.34998.1.1.7 (Oct 6 2010): Approved under the IGTF MICS Profile by TAGPMA vote on Oct 6 2010 in Lubbock, Texas.
1.3.6.1.4.1.34998.1.1.6 (Oct 5 2010): Submitted to TAGPMA reviewers on Oct 5 2010. Modified to comply with MICS Profile instead of SLCS Profile (i.e., reverted to Version 4 content).
1.3.6.1.4.1.34998.1.1.5 (Sep 28 2010): Submitted to TAGPMA reviewers on Sep 28 2010. Modified to comply with SLCS Profile instead of MICS Profile.
1.3.6.1.4.1.34998.1.1.4 (Sep 13 2010): Submitted to TAGPMA reviewers on Sep 13 2010, addressing review comments received to-date.
1.3.6.1.4.1.34998.1.1.3 (Jul 28 2010): Submitted to TAGPMA reviewers on Jul 28 2010, addressing review comments received to-date.
1.3.6.1.4.1.34998.1.1.2 (Apr 2 2010): Submitted to TAGPMA reviewers on Apr 2 2010, addressing review comments received to-date.
1.3.6.1.4.1.34998.1.1.1 (Jan 15 2010): Submitted to TAGPMA reviewers on Jan 15 2010.
Report abuse