Page History

Ideally SPs that require a particular assurance level will initiate the assurance flow by including the desired IAQ in the <samlp:AuthnRequest> element.

SPs will receive IAQs (either in response to a specific request, or sent unsolicited) in assertions from IdPs. SPs should use metadata to check that the IdP is authorized to assert the IAQs being asserting.

SPs will rely on local policy to decide how to handle incoming IAQs. For example if the SP requires InCommon Bronze but receives InCommon Silver, that is probably acceptable.

SP Policy Use Cases

Issues

• Some SPs may not be able to use the AuthnRequest mechanism due to software or other limitations. Are they simply out of luck?
  • One option may be to use additional software to generate requests on behalf of the broken SP, although this isn't guaranteed to work with all SPs. Otherwise, such SPs will be forced to rely on OOB configuration of IdPs.
• How is the AuthnRequest configured using the Shib SP? The simpleSAMLphp SP?
  • Shibboleth SPs can rely on the authnContextClassRef setting to control the value requested when particular resources are accessed. To include multiple values in a request, the AuthnRequest "template" mechanism described in the SessionInitiator documentation can be used.
• Boarding process: Since an IAQ in metadata makes a statement about certification (not live service), how does an SP determine that an IdP supports assurance operationally (ala attribute support)? One approach is to include <saml:Attribute> elements in IdP metadata. Other approaches?
  • There is no metadata support for this requirement. SPs should be able to handle errors returned by IdPs that indicate the requested assurance level was not supported. The federation should help establish guidelines for describing such errors, perhaps with a FAQ page that could be linked in.
• Does the Shib SP software support the metadata check? Does the simpleSAMLphp SP?
  • The Shibboleth SP can extract and make available the entity attribute value in a variable along with user attributes, and use the variable in authorization policy. This is described under "metadata attribute extraction".
• What matching rules are recommended, or acceptable?
• How is an SP supposed to "know" that Silver is acceptable in lieu of Bronze? Is there a role for InCommon to provide "advice"?
• How should an SP perform LoA escalation to allow for a need for increased LoA in an application when a user transitions from a context that needs little or no assurance, to a context that requires a higher LoA?

Software-Specific Information

Shibboleth

This example shows how a Shibboleth Service Provider can request a silver-test IAQ from an IdP. First, the SP must consume IdP metadata.

1. Edit the SP's /etc/shibboleth/attribute-map.xml configuration file. Add the following new element to the config:

   Code Block
   xml xml
   <Attribute name="urn:oasis:names:tc:SAML:attribute:assurance-certification" id="assurance-certification"/>

   This corresponds to the <saml:Attribute Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> element in the IdP's metadata.
2. Edit the SP's /etc/shibboleth/shibboleth2.xml configuration file. Add the following attribute to the <ApplicationDefaults> element:

   Code Block
   xml xml
   metadataAttributePrefix="Meta-"

   You will now have an <ApplicationDefaults> element with the following:

   Code Block
   xml xml
   <ApplicationDefaults id="default" policyId="default" entityID="https://example.org/shibboleth" REMOTE_USER="persistent-id targeted-id eppn" signing="false" encryption="false" homeURL="https://example.org/" metadataAttributePrefix="Meta-">

   This will add new Apache server environment variables with prefix HTTP_META_ and allow the SP software to automatically populate the Apache server environment with IAQs from the IdP's metadata. This is useful for the SP to programmatically determine which assurance attributes are valid from the IdP.
3. Restart the SP's shibd process.

One way for the SP to request silver-test IAQ from the IdP is to use the authnContextClassRef query string parameter to create the session.

Location: https://sp.example.org/Shibboleth.sso/Login?
  target=https%3A%2F%2Fsp.example.org%2Fsecure%2Fresource.asp&
  entityID=https%3A%2F%2Fidp.example.org%2Fidp%2Fshibboleth&
  authnContextClassRef=http%3A%2F%2Fid.incommon.org%2Fassurance%2Fsilver-test

Upon successful authentication from the IdP, the secure SP session should contain the following environment variables:

HTTP_SHIB_AUTHENTICATION_METHOD    http://id.incommon.org/assurance/silver-test
HTTP_META_ASSURANCE_CERTIFICATION  http://id.incommon.org/assurance/silver-test;http://id.incommon.org/assurance/bronze-test

Contrast this with the same session initiation without the authnContextClassRef parameter:

HTTP_SHIB_AUTHENTICATION_METHOD    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
HTTP_META_ASSURANCE_CERTIFICATION  http://id.incommon.org/assurance/silver-test;http://id.incommon.org/assurance/bronze-test

Note that if you attempt to pass the authnContextClassRef parameter to an IdP that has not been properly configured, you will most likely receive an opensaml::FatalProfileException error.