Internet2 is investigating a security incident involving a compromise to a confluence server that affected https://spaces.at.internet2.edu on April 10, 2019, which was successfully mitigated on April 12, 2019. If you did not receive an email from us, it’s unlikely that any of the content you submitted to the Internet2 Spaces Wiki needs to be re-entered. We apologize for any inconvenience this may have caused. Should you have any questions or require further assistance, please email collaboration-support@internet2.edu.
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

DRAFT, with many questions

Technical implementation of assurance requires system changes from InCommon Ops, IdPs, and SPs. There are many different scenarios and choices.

InCommon metadata management

InCommon Ops will add IAQs to the published metadata following notification of certification by InCommon management. These will apply to the relevant IdP entries of the certified IdPOs.  IAQ URIs are:

Silver:  <something>

Bronze:  <something>

SP behavior

Ideally SPs will initiate the assurance flow by including the desired IAQ in the SAML AuthnRequest element.

  • What matching rules are recommended, or acceptable?
  • Some SPs may not be able to use the AuthnRequest mechanism due to software or other limitations.  Are they out of luck?
  • How is this configured using the Shib SP?  simpleSAML SP?

SPs will receive IAQs (either in response to a request, or sent unsolicited) in assertions from IdPs.  SPs should use metadata for the relevant IdPs to check that they are certified to assert the IAQs they're asserting.

  • Does the Shib (or SSP) SP software support the metadata check?

SPs will use local policy to decide how to handle incoming IAQs.  For example if the SP requires InCommon Bronze but receives InCommon Silver that should be acceptable.

IdP behavior

Ideally IdPs will receive a desired IAQ from an SP in an AuthnRequest to initiate the process.  The IdP deals with the requested IAQ and matching rule and interacts with the local IdM system to determine if the user at hand meets the requirements.  If so the appropriate IAQ is returned in the AuthnContext element in the assertion.

  • What matching rules are supported?
  • How does the Shib (or SSP) IdP interact with local IdM?  Is a custom login handler required?

SPs may not put IAQs in AuthnRequests but still want to see IAQs from IdPs.

  • Can the Shib (or SSP) IdP be configured to send IAQs without being requested?
  • If so, are there appropriate policy knobs (per-SP, per-user, whatever)?
  • No labels