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. FWIW, for SPs that also want to make use of social logins Facebook, LinkedIn and Google all use square logos for OAuth clients | Patrick Radtke | Ken Papai | |
| 2 | Re logo transparency | Nonnormative text may include a hint about a black or white border around the logo before the transparency if the background is a critical need of the logo. | Via IIW (Judith Bush) | ||
| 3 | SP certificate requirements | Section SDP-SP45 says that an SP's metadata must contain certificate(s) that can be used for signing. But section SDP-MD10 mentions only encryption certificates for SPs. First of all, this a bit confusing: must an SP's metadata contain a certificate suitable for signing or not? Secondly, if, in fact, an SP's metadata must contain a certificate suitable for signing, why? | Scott Cantor | ||
| 4 | Requirement numbering | Just to head off a bunch of comments, the final renumbering of the requirement blocks isn't done yet pending more tweaks to ordering or updates. | Scott Cantor | ||
| 5 | Reduce scope of document | The SAML-world already has many pages of documents. In order to be effective, the profile should be as concise as possible and contain the essential points needed for interoperation. And not be a wishlist or best-practice document. I propose to remove the entire section on Logo requirements, on MDUI-requirements and the section on deep linking. Not that these are invalid points, they are just not essential and more of a best practice. Whether or not an IdP has a good logo is, to be frank, not one of our top concerns. | Thijs Kinkhorst | ||
| 6 | Key hashing algorithm | [SDP-MD09] "Certificates used MUST NOT be signed with an MD5-based signature algorithm and SHOULD NOT be signed with a SHA1-based signature algorithm." This is a confusing requirement. X.509 certificates are used as a container for the key, not as a PKI. A few paragraphs above it is stated that the certificate should be self-signed. Talking about these signing algoritms for the key is not necessary and can confuse the deployers. Propose to drop the entire requirement. | Thijs Kinkhorst | ||
| 7 | Response signing | [SDP-IDP09] requires that response is signed. We are working with signed assertions (not responses) for many years now and I do not recollect this giving rise to any serious interop problem. So I'm not sure that this is an essential property for interoperability. | Thijs Kinkhorst | ||
| 8 | Encryption of assertions | SDP-IDP11 requires assertion to be encrypted. Although I understand that there can certainly be benefits, I don't think it's essential for interop to make it a hard requirement. There are in my experiences many cases that work fine and in which encryption is not necessary per se. Propose to make it a "should". | Thijs Kinkhorst | ||
| 9 | Subject-id | The document obsoletes the NameID and requires the new subject-id attribute. This new identifier is however still very much in its infancy. I believe that an interop profile is not the place to be pushing new things. It should document existing practices and list proven and established technology that is already in wide use. An interop profile should be about "if you follow these requiements, it will work". Any deployer picking up this document now will quickly find out that many federations cannot currently deliver this attribute at all. So the promise of interoperability by following it then quickly fails. The subject-id is a fine idea but not established technology. I propose to remove anything related to the subject-id. It could of course be codified in a version 2.0 when it has been widely adopted. | Thijs Kinkhorst |
See Also