Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The InCommon Deployment Profile working group was chartered by the InCommon Technical Advisory Committee (TAC) in the fall of 2016. The group was charged with creating a deployment profile that could be layered on top of the SAML 2.0 Deployment Profile, SAML2int, which was planned to receive a much-needed update. The working group would make its needs for the research and education (R&E) community known so that some could be incorporated into SAML2int; the remaining requirements would go into an R&E-specific deployment profile.

This work was a follow-on initiative recommended by the Federation Interoperability working group which created a profile for SAML software developers. The Federation Interoperability recommended a second profile for deployers of SAML-based services and identity providers.

The Deployment Profile's charter stated the following:

Operating a broadly compatible SAML-based service or identity provider can be challenging. The standards and profiles that are currently available leave a lot of room for interpretation and customization. While this allows for flexibility, it also results in issues that make interoperating in a federation a lot harder than it should be. While deployment standards exist today, they fall short of solving the whole problem.

Process

The working group began by evaluating the issues list from the Federation Interoperability working group; many of the requirements for developers imply configuration on the part of deployers. In addition, many of the issues from the previous working group's list were considered out of scope for their work but relevant for deployers. The group categorized and clarified the issues and added others from personal experience and community input. The result was a list of recommendations for SAML2int, R&E specific issues, federation operator issues, and those not belonging in a profile at all.

...

  • Clock skew: the implementation profile is vague on this, stating a reasonable value with a recommended three to five minute range. The Deployment Profile requires a maximum three to five minute range.
  • Forced authentication: The deployment profile recommends that the SP test the currency of the AuthnInstant to ensure that reauthentication re-authentication was performed by the IdP. The implementation profile doesntdoesn't require that this value be exposed to make it available for testing.

...

  • Authorization, provisioning and de-provisioning using standard values
  • Identifier mapping from asserted identifier into application-specific identifier
  • Application support for custom authentication context class references such as the REFEDS MFA profile, including use for 'step-up' authentication and possibly forced re-authentication, SPs must check authnInstantAuthnInstant
  • Configuring attribute release/consumption based on available context
  • Adoption of the new SAML subject identifiers
  • Development of a "Ready for Collaboration" entity category

...

First and most obvious, the working group recommends that the TAC support the revised SAML2int being presented to Kantara's Federation Interoperability Working Group (WG-FI) for review and ratification. Once ratified, we recommend that Refeds REFEDS works to integrate the requirements of the revised profile into federation-specific requirements.

...