...
The SP requires InCommon Silver LOA.
The SP includes http://id.incommon.org/assurance/silver in the SAML RequestedAuthnContext element. It accepts assertions that contain http://id.incommon.org/assurance/silver in the AuthnContext from IdPs with http://id.incommon.org/assurance/silver in InCommon metadata.
Commentary:
As usual, the The SP should intelligently handle errors. In particular, the SP should be prepared to handle the case that not all users at a particular IdP may be eligible for Silver LOA (for example, users not vetted at Silver), so even if the IdP is tagged with http://id.incommon.org/assurance/silver in InCommon metadata, authentication for some users may result in an "AuthnFailed" response.
As an optimization, the SP may avoid issuing requests to IdPs that are not accredited at certified Silver, since these requests would always be rejected later anyway. The SP may locally block ("short-circuit") requests of this type. The SP may provide a local discovery interface that lists only IdPs with http://id.incommon.org/assurance/silver in InCommon metadata to constrain users to only choose Silver accredited IdPscertified IdPs. Errors must be anticipated in any event.
Examples:
- NSC Meteor Access for Financial AId
...
The SP requires InCommon Bronze LOA (or higher).
The SP includes http://id.incommon.org/assurance/silverbronze and http://id.incommon.org/assurance/bronzesilver in the SAML RequestedAuthnContext element. It The SP accepts either:
- Assertions assertions that contain http://id.incommon.org/assurance/silverbronze in the
AuthnContextfrom IdPs with http://id.incommon.org/assurance/silverbronze in InCommon metadata, orAssertions - assertions that contain http://id.incommon.org/assurance/bronzesilver in the
AuthnContextfrom IdPs with http://id.incommon.org/assurance/bronzesilver in InCommon metadata.
Commentary:
As usual, the SP should intelligently handle errors. In particular, the SP should be prepared to handle the case that not all users at a particular IdP may be eligible for Silver or Bronze (for example, users not vetted at the Silver or passwords too weak for Bronze)Bronze or Silver, so even if the IdP is tagged with http://id.incommon.org/assurance/silver and/or http://id.incommon.org/assurance/bronze in InCommon metadata, authentication for some users may result in an "AuthnFailed" response.
As an optimization, the SP may avoid issuing requests to IdPs that are not certified Bronze, since these requests would always be rejected later anyway. The SP may locally block ("short-circuit") requests of this type. The SP may provide a local discovery interface that lists only IdPs with http://id.incommon.org/assurance/bronze in metadata to constrain users to only choose Bronze certified IdPs. Errors must be anticipated in any event.
Note:
Since Bronze is a subset of Silver, IdPs with http://id.incommon.org/assurance/silver in metadata will necessarily have http://id.incommon.org/assurance/bronze in metadata as well. Thus the SP may focus on Bronze to build its discovery interface.
Examples:
- The InCommon Federation Manager (FM)
- The InCommon Certificate Manager (CM)
The FM requires Bronze password credentials for delegated administrators. Also, both the FM and the CM recognize require Bronze password credentials as the first factor of a two-factor authentication. The InCommon Operations Identity Provider is authoritative for the second "what you have" factor.
UC2: SP Prefers Silver
Motivation: The SP must operate in a world where not all IdPs can yet provide Silver assertions, and Silver-capable IdPs can't provide Silver assertions for all users/circumstances. In cases where lower LOA assertions are used, the SP restricts access/functionality and/or implements other compensating controls. The SP wants to get Silver assertions whenever possible. The SP can determine which IdPs are Silver-capable from metadata.
SP Strategy A: The SP includes http://id.incommon.org/assurance/silver and urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified in the SAML RequestedAuthnContext element. The If the IdP returns a SAML an assertion containing http://id.incommon.org/assurance/silver in the AuthnContext when possible (i.e., if the user is vetted at Silver and the authentication method is Silver), and otherwise returns a SAML assertion containing another AuthnContextClassRef value in the AuthnContext or returns an error. In other words, the IdP prefers to return Silver assertions when requested over other types of assertions. The SP checks to see if the assertion contains http://id.incommon.org/assurance/silver in the AuthnContext and the SP checks that the IdP has http://id.incommon.org/assurance/silver in its InCommon metadata. If , and if the check passes, the SP considers the authentication to be at the Silver level. If not, the SP considers the authentication to be lower LOA. SP Strategy B: Alternatively, the SP may include only http://id.incommon.org/assurance/silver in the SAML AuthnRequest element, and if the IdP returns an "AuthnFailed" response, possibly indicating the particular user is not Silver qualified, the SP makes a new request without a RequestedAuthnContext element, resulting in for a lower LOA authentication. Ideally the user will not be prompted to authenticate a second time for this second request by the SP, i.e., the IdP has set a cookie in the user's browser.
...