Talk:SAML 2.0

Computer Security: Computing Low‑importance

This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer SecurityWikipedia:WikiProject Computer SecurityTemplate:WikiProject Computer SecurityComputer Security articles

Low

This article has been rated as Low-importance on the project's importance scale.

This article is supported by WikiProject Computing (assessed as Low-importance).

Things you can help WikiProject Computer Security with:

Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information...

Review importance and quality of existing articles
Identify categories related to Computer Security
Tag related articles
Identify articles for creation (see also: Article requests)
Identify articles for improvement
Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
Find editors who have shown interest in this subject and ask them to take a look here.

What's missing?

'Although this article is already long, it's missing some significant new features of SAML 2.0:'

Single Logout Profile
HTTP Redirect Binding
Attribute Profiles (esp. X.500/LDAP Attribute Profile)
Authentication Context

Also, there is no mention of the Enhanced Client/Proxy Profile, but seriously, I think ECP is too much for this introduction to SAML 2.0. Trscavo 19:16, 26 March 2007 (UTC)[reply]

With hindsight, the example flow illustrating Web Browser SSO should utilize HTTP Redirect (from the SP to the IdP) and HTTP POST (from the IdP to the SP) instead of HTTP POST in both directions since the former is by far the most common flow in use today. (I'm not keen on redoing the flow diagram, however.) Tom Scavo (talk) 19:56, 10 March 2013 (UTC)[reply]

References?

Isn't it a bit crazy to ask for references on an article about an official standard and reject the standard definition as "primary sources"? I know there are all kinds of WP:* on this, now seriously, in this case referencing second parties and leaving out the primary source would considerably devalue the article. Apparently, I'm not alone with that opinion, since the header is from 2008 and no one has bothered so far. How about removing it and accepting that for some topics, primary sources are the best references you can give?

Agreed. Tom Scavo (talk) 18:27, 10 March 2013 (UTC)[reply]

I don't think the standard definitions need to be rejected. The relevant policy page says "Unless restricted by another policy, primary sources that have been reliably published may be used in Wikipedia; but only with care, because it is easy to misuse them. Any interpretation of primary source material requires a reliable secondary source for that interpretation. A primary source may only be used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the source but without further, specialized knowledge." So, where there are references to protocol details, etc. primary sources are fine. I think most of the article is fine on these grounds. It's only when you get into sections like "SAML 2.0 Metadata" that perhaps secondary sources should be cited. Fool4jesus (talk) 19:27, 21 May 2013 (UTC)[reply]

Implementations

Anyone else think it would add to this article to mention implementations or products that support SAML such as Tivoli or Microsoft or Oracle etc? —Preceding unsigned comment added by 149.176.250.16 (talk) 01:13, 24 February 2011 (UTC)[reply]

No, please use SAML-based products and services instead. Tom Scavo (talk) 18:25, 10 March 2013 (UTC)[reply]

Deflate?

I suppose 'deflating' in this text means to strip the (XML) text of unnecessary whitespace? Deflate in computer science is also used for a particular way of compressing data. mvdhout (talk) 13:24, 12 January 2012 (UTC)[reply]

Deflating (as in compressing data) is appropriate for HTTP Redirect binding (see http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf section 3.4.4.1), but not for HTTP-POST binding. I just removed an incorrect statement saying the AuthnStatement should be URL encoded and deflated before it's base64 encoded and placed in the XHTML form in HTTP-POST. Gpista (talk) 22:27, 21 February 2013 (UTC)[reply]

HTTP Artifact Binding

Correct me if I misunderstood something there, but the description currently states: 'Initially, the service provider transmits an artifact to the identity provider via an HTTP redirect [...] Next the identity provider sends a <samlp:ArtifactResolve> request (such as the ArtifactResolveRequest shown earlier) directly to the service provider via a back channel. Finally, the service provider returns a <samlp:ArtifactResponse> element containing the referenced <samlp:AuthnRequest> message'

In every case I have encountered so far the roles are the other way around. Shouldn't the IdP generate and send the artifact, which is then resolved and sent back by the SP, so the IdP can eventually send a response containing the assertion? Daniel Wild (talk) 13:22, 10 September 2020 (UTC)[reply]

The HTTP Artifact Binding works in either direction. That said, the use case where the IdP issues the artifact is probably more common. Tom Scavo (talk) 14:36, 10 September 2020 (UTC)[reply]

SAML 2.0 Metadata

The section on SAML 2.0 Metadata has been cleaned up and enhanced, so I think the clean-up message can be removed. Tom Scavo (talk) 19:49, 10 March 2013 (UTC)[reply]

SAML 2.0 Assertions

There are numerous examples of SAML assertions in the article, including a holder-of-key assertion in the section on attribute query, so I think the notice at the beginning of the section on SAML 2.0 Assertions can be removed. Moreover, bearer assertions are far and away the most common SAML token type so I think the notice is misguided. Tom Scavo (talk) 20:19, 10 March 2013 (UTC)[reply]