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

Compare with Current View Page History

« Previous Version 14 Next »

Introduction


The InCommon Deployment Profile working group was chartered by the InCommon Technical Advisory Group (TAG) 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 also apply to 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.
The group then tackled a number of tough issues for which requirements were needed but unclear: federated logout, identifiers, XML encryption, and logos. After several lengthy discussions, the group reached and documented consensus on these areas and formed them into requirements.
At this point, the group produced a second profile specifically dealing with identifiers. The OASIS SAML V2.0 Subject Identifier Attributes Profile reflects the work done in this area. It attempts to clear up confusion and issues with the numerous federated identifiers available to deployers today.
As the work progressed, the working group realized that, if SAML2int was going to be updated in a timely fashion, they would need to be the ones to do it. The group was depending on SAML2int updates to be completed before an R&E specific profile could be created. Thus, the group produced an updated version of SAML2int for community review and adoption.

The R&E community provided feedback during a consultation period in May of 2018. The following September, the group held two community review calls to discuss responses to the feedback. A small number of additional revisions were made as a result of the community review calls. The completed work is being presented to Kantara to supersede the current SAML2int after formal ratification.


Deliverables


Significant accomplishments

  • Identifiers: To address the large number of identifiers available today, most of which have significant issues or have been widely deployed incorrectly, the group created two new identifier attributes and documented them in a separate profile which is being approved by OASIS SSTC.
      • Federated logout: This topic has many options with no guidance. The working group couldn't find a one-size-fits-all solution but instead presented several well-defined options.
  • Encryption: A lot of compatibility issues arise from a relying party's requirements around signing and encrypting SAML messages. Clear requirements were created to help to resolve this problem.
  • Logos in metadata: After much discussion, a consensus couldn't be reached to create definitive requirements for logos. Basic guidance was created, but the group referred readers to federation-specific requirements. We are deferring to Refeds to further establish international consensus.
  • Error handling: The group discovered a lack of consistency and consensus across our community in use of this element. To resolve this, the profile standardizes the usage of error URLs. Error URLs are important, and with guidance around their use and content, they can be even more useful.


Recommendations to federations for implementing

Several items in the profile will require some coordinated effort by federations for broad adoption, similar to work done to aid large changes in the past such as the move to Shibboleth IdP version 3. InCommon may wish to make some of these requirements part of Baseline Expectations in the future. Items of interest include:

  • Changing encryption algorithms
  • Adopting new identifiers
  • Firming up common standards around logos and enforcing them


Noteworthy differences between Implementation and Deployment Profiles

The working group identified a couple of areas where the implementation profile and deployment profile don't completely align. These are worth bringing attention to but, in the opinion of the group, are acceptable differences.

  • 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 was performed by the IdP. The implementation profile doesnt' require that this value be exposed to make it available for testing.


Remaining items for an R&E-specific profile


Next steps and recommendations to InCommon

First and most obvious, the working group recommends that InCommon support the revised SAML2int be presented to Kantara for review and ratification. Once ratified, we recommend that Refeds works to integrate the requirements of the revised profile into federation-specific requirements.

As noted above, there are requirements that were left out of this profile that don't apply globally but benefit an R&E specific application. The working group recommends that InCommon charter an effort to create an R&E specific profile to be layered on top of SAML2int using the above requirements as a starting point.

Many of the requirements in the revised profile need to be widely adopted to be useful. The working group recommends that such items be considered for addition to the InCommon Baseline Expectations. Such candidates might include adoption of new identifiers, upgrading to new encryption algorithms, timely metadata consumption, proper error handling, and compliant logout processes.

The working group recommends that InCommon establish automated tests for requirements where possible. Obviously, many of the requirements can't be tested, but there's benefit to testing and notifying contacts for lack of compliance with those requirements that can be tested.

Finally, the working group recommends some well-planned marketing and insentives to help InCommon participants achieve compliance. This could involve adding items to Baseline Expectations as noted above, but it also could include a badge or signaling in metadata. As with SIRTFI, metadata signaling could be self-asserted. InCommon might also want to consider a Baseline+ certification; participants who don't meet the extra requirements won't be removed from the federation, but those who do will receive additional benefits. Adherence to many items in this profile might fall into that category.

  • No labels