Community Review
This consultation on the SAML V2.0 Interoperability Deployment Profile V1.0 is open from Monday, April 9, 2018 to Monday, May 7, 2018
Background
While updating SAML2int, the working group chose to tackle some of the bigger issues that challenge federations today. To help the reader understand some of the group's decisions, here is a summary of a few of the issues and our rationale behind the requirements for these issues. Feedback on the requirements for these items, as well as on anything else in the document, is of course encouraged.
Identifiers and NameIDs
This section eliminates the use of any NameID format other than transient. In addition, the complex, confusing, and in some cases poorly adopted set of attribute identifiers used today has been replaced with two clear identifiers for communicating the subject. This model leverages the new OASIS identifiers profile: https://www.oasis-open.org/committees/download.php/62438/saml-subject-id-attr-v1.0-wd04.pdf. While the identifiers profile is still in process, it continues to move toward adoption. We believe this will make the adoption of identifiers much clearer and easier and the choice of identifiers by service providers more straightforward.
Cryptography
Several major vulnerabilities over the past few years have underscored the importance of modern cryptographic algorithms. Cryptography requirements in this document attempt to set a firm line for what's needed to securely sign and encrypt. At the same time, the working group tried to make the requirements relatively future proof.
Deep linking
This is an issue that can cause significant frustration to those using federated services that lose track of the intended destination during the login process, and the working group saw this as one that needs to be fixed. The requirements for this aren't complex but serve to remind deployers of something that often gets overlooked, especially when federated authentication is tacked on later.
Support for multiple IdPs
This issue works together with deep linking in most cases. Other profiles and earlier versions of SAML2int mention the importance of IdP discovery. This section stresses that any federated application needs to be prepared to work with multiple IdPs, a limitation of many applications today.
Logout recommendations
Federated logout is a long-standing debate in the community. The working group, after much debate, created requirements to establish clear guidance. IdPs need to accept a logout request from an SP and need to publish a logout endpoint. What they do with the logout request is somewhat flexible: there's not a one size fits all. The profile also touches on the danger of an SP performing an automatic federated logout as a result of user inactivity. SP support of single logout requests from IdPs is included, but we chose to leave this optional. We feel that our approach will meet the needs of deployers while leaving room for institutional policy.
Logos
Firm requirements around logos have been needed for a long time. Requirements today even differ from one federation to another -- a problem in the era of Edugain. The InCommon baseline expectations provide further necessity for logos. The profile makes some clear guidance for format and size along with suggestions for appearance. The working group tried to be specific while leaving room for artistic interpretation.
Document for review/consultation
Document After Consultation: (to be published after consultation/with changes included)
Number | Current Text | Proposed Text / Query / Suggestion | Proposer | +1 (add your name here if you agree with the proposal) | Action (please leave this column blank) |
|---|---|---|---|---|---|
| 1 | Logo 60 x 80 | suggestion: high-res Favicon, Android home screen icons, Apple touch icons and Windows metros icons all use square images to represent websites. As such institutions are more likely to have existing, reasonable looking square logos to represent them. It will make adoption more straightforward if IdP operators can simply upload their schools existing high-res favicon/touch icons rather than creating their own, non-square icon. This site has more information on what existing systems are using https://sympli.io/blog/2017/02/15/heres-everything-you-need-to-know-about-favicons-in-2017/ The handful of schools I spot checked either had hi-res favicon or published hi-res Apple touch icons. | Patrick Radtke | Ken Papai | |
| 2 | |||||
| 3 | |||||
| ... |
See Also