Date: Fri, 29 Mar 2024 14:22:21 +0000 (UTC) Message-ID: <1556812814.8089.1711722141291@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8088_393596400.1711722141291" ------=_Part_8088_393596400.1711722141291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
DRAFT
The Service Provider Assurance policy requirements can be expressed in s= everal use cases. Below is a list of the tested cases requested by SPs inte= nding to request qualifiers in 2012.
The SP requires InCommon Silver.
The SP includes http://id.incommon.org/assurance/silver in the SAML=
RequestedAuthnContext
element. It accepts assertions that con=
tain http://id.incommon.org/assurance/silver in the AuthnContext=
from IdPs with http://id.incommon.org/assurance/silver in InCo=
mmon metadata.
Commentary:
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= , so even if the IdP is tagged with http://id.incommon.org/assurance/silve= r in metadata, authentication for some users may result in an "AuthnFai= led" response.
As an optimization, the SP may avoid issuing requests to IdPs that are n= ot certified Silver, since these requests would always be rejected later an= yway. 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 metadata to constrain users to o= nly choose Silver certified IdPs. Errors must be anticipated in any event.<= /p>
Examples:
The SP requires InCommon Bronze (or higher).
The SP includes http://id.incommon.org/assurance/bronze and=
http://id.incommon.org/assurance/silver in the SAML Re=
questedAuthnContext
element. The SP accepts either:
AuthnContext
from IdPs with http://id.incommon.org/assur=
ance/bronze in InCommon metadata, orAuthnContext
from IdPs with http://id.incommon.org/assur=
ance/silver 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 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= a> in metadata, authentication for some users may result in an "AuthnFailed= " response.
As an optimization, the SP may avoid issuing requests to IdPs that are n= ot certified Bronze, since these requests would always be rejected later an= yway. 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 o= nly choose Bronze certified IdPs. Errors must be anticipated in any event.<= /p>
Note:
Since Bronze is a subset of Silver, IdPs with http://id.incommon.org/as= surance/silver in metadata will necessarily have http://id.incommon.or= g/assurance/bronze in metadata as well. Thus the SP may focus on Bronze= to build its discovery interface.
Examples:
The FM requires Bronze password credentials for delegated administrators. Also, bot= h the FM and the CM 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.
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 al= l users/circumstances. In cases where lower LOA assertions are used, the SP= restricts access/functionality and/or implements other compensating contro= ls. The SP wants to get Silver assertions whenever possible. The SP can det= ermine which IdPs are Silver-capable from metadata.
SP includes http://id.incommon.org/assurance/silver in the SAML Req= uestedAuthnContext element. If the IdP returns an assertion containing htt= p://id.incommon.org/assurance/silver in the AuthnContext, the SP checks= that the IdP has http://id.incommon.org/assurance/silver in its InCom= mon metadata, and if the check passes, the SP considers the authentication = to be at the Silver level. Alternatively, if the IdP returns an "AuthnFaile= d" response, possibly indicating the particular user is not Silver qualifie= d, the SP makes a new request without a RequestedAuthnContext element, for = a lower LOA authentication. Ideally the user will not be prompted to authen= ticate a second time for this second request by the SP, i.e., the IdP has s= et a cookie in the user's browser.
As an optimization, the SP may choose to look in InCommon metadata and n= ot include a SAML RequestedAuthnContext element in requests to IdPs that ar= e not Silver accredited.
Examples: