Page History

...

Note that all of the above URIs will resolve to actual web pages at some point.

Anchor
IAQs IAQs

IAQs in metadata

The following extension is the immediate child element of the IdP's <md:EntityEescriptor> element in metadata:

...

• 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?

Anchor
SPExample SPExample

Example Use Case

This simple example shows how a Service Provider can request a silver-test assurance from an IdP which has been configured as shown in the IAQs in metadata section above. First, both the IdP and SP must use IdP metadata configured as shown in the "IAQs in metadata" section above. The IdP will also need to release silver-test as a valid <AuthenticationMethod> for the chosen <LoginHandler>, typically done in the IdP's handler.xml configuration.

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

   Code Block
   <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"> tag in the IdP's "IAQs in metadata" configuration section above.
2. Edit the SP's /etc/shibboleth/shibboleth2.xml configuration file. In the <ApplicationDefaults ...> tag, add the following attribute:

   Code Block
   metadataAttributePrefix="Meta-"

   You will now have an <ApplicationDefaults ...> tag that looks like the following:

   Code Block
   <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 of the form HTTP_META_... and allow the SP software to automatically populate the Apache server environment with the IdP's metadata <EntityAttributes>. This is useful for the SP to programatically 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 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 have 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 which has not been configured, you will most likely receive an opensaml::FatalProfileException.

IdP behavior

See Assurance - Identity Provider Behavior.

...