RE: [security-services] FW: [security-services-comment] SAP Comme ntsOn

Subject: RE: [security-services] FW: [security-services-comment] SAP Comme ntsOn SAML Core-27 and Bindings-11

24.

Bindings & Profiles Doc. Line # 210. I am not sure why there must not be more than one request element in the SOAP body. You can send multiple "AssertionIDReference" and "AssertionArtifact" in "Request" but you cant send multiple "AuthenticationQuery" etc in "Request". What it means is using one mechanism ("AssertionIDReference", "AssertionArtifact"), you can get multiple assertions back but using other mechanism "AuthenticationQuery" etc, you can only get one assertion back. Some explanation would be helpful.

[Prateek]

The challenge here is understanding the structure of the responses. If you query against three distinct "AssertionArtifact" elements you get back three assertions (each holding the related artifact value) OR you get back no assertions (e.g., could not find an assertion corresponding to an artifact). In both cases, you will receive a status code of success. So, while we are supporting "aggregate" queries, it is easy to connect all of the components of the request and the response in this case.

One important point to note with any type of query is that you can always receive a plurality of assertions in response. This holds, for example, with "AuthenticationQuery" as well as all other query types. The responder collects all of the assertions that "match" the query and sends them back in a response object.

If we supported multiple authentication queries wrapped within a single request, we would have the challenge of correlating the assertions returned within a single response with the various "Query" elements in the request. This is going to make the response processing a good deal more complicated than it currently is.

I think that "box-carring" or combining several SAML requests into a single SOAP message has a lot of value

(correspondingly also return several responses in a single SOAP message). But I think this should be addressed by the SOAP community in a general way rather than in this forum.

25.

Bindings & Profiles Doc. Line # 339. In the example, there is a "StatusCode" attribute in "Response" element. "StatusCode" is an element in "Response" element. The example should be modified to reflect this.

[Prateek]

Fixed in bindings-12.

26.

Bindings & Profiles Doc. Line # 346. In the example, there should be a closing tag "</samlp:Response>"

[Prateek]

Fixed in bindings-12

27.

Bindings & Profiles Doc. Line # 348. None of the two mentioned web browser SSO profiles, and the SOAP profile seems to make use of the "AssertionSpecifier" element from the Core Document. Assertions are either fully contained in the protocol messages or, in the case of the Browser/Artifact profile, the SAML artifact is used. Some explanatory text why the element "AssertionSpecifier" is not used here would be helpful.

[Prateek]

I am not sure of the exact concern here. AssertionSpecifier is actually used only two places in the schema: as an advice element and as a possible evidence element. Is there some functional behavior that is missing from the profiles? Why should we use the AssertionSpecifier element in a profile?

28.

Bindings & Profiles Doc. Line # 467. When source site is creating the multiple artifacts and relying party gets those artifacts, how does relying party find out which artifact is meant for authentication statement or attribute statement? I am not sure if we use "TypeCode" for this. There is no explanation for this field. Why "0x0001" is mandatory to implement and what does it signify? Some explanation would be useful.

[Prateek]

When a relying party receives an artifact it has no idea what the corresponding assertion contains. It can only query the source site and receive the assertion. In general, an assertion may contain many different statements. If a relying party requires certain statements to be present in an assertion, it can only make this determination after it has received the assertion.

There may be many different SAML artifact formats. How does the relying party understand which type of artifact it has received? This is the function of the "TypeCode" element. For example, on lines 924 we describe an alternative SAML artifact format which has type code "0x0002".

We have made the 0x0001 assertion format mandatory to implement as this ensures interoperability and cross-domain SSO. Every implementor of the SAML web browser artifact profile must be able to generate and process the 0x001 artifact.

29.

Bindings & Profiles Doc. Line # 535. Whereas the SAML artifact type is just "String" in the Core Document, the Bindings & Profiles Document now seems to "overspecify" the artifact format. This "overspecification" results in additional overhead for negotiating and exchanging distinct SourceID values and maintenance of the SourceID to URL mappings at each destination site. Is the URL size problem so severe that these consequences cannot be avoided? Couldn't it be another option to use an "AssertionSpecifier" element with an assertionID as an SAML artifact?

[Prateek]

The web browser profile is a security protocol for communicating assertions from one site to another via the user browser. It has many specific properties and the profile includes a careful analysis of threats and counter-measures.

Hence, making even a small change to it may have significant impact on its security properties and, of course, on interoperability as well.

Vendors are free to design (1) new artifact architectures – hence the "TypeCode" field, or, (2) a completely new profile that better fits their needs. However, when making such a design it is very important to consider the security properties of all the structures and flows involved.

Each enterprise (not necessarily each web site) does need to choose a distinct SourceID value. Well, how should it do so? Our recommendation is that the enterprise pick a URL whose domain name it controls (lines 567-569), say for example:

http://www.example.com/source_id_url

and take the SHA-1 hash. As no other entity also "controls" the domain name we are guaranteed that the hash is unique to the enterprise. This is now the "SourceID" component of the artifact and can be used by the enterprise with all of its partners. Each partner will have to maintain a table of SourceIDs and corresponding artifact lookup service addresses.

URL size restrictions are a serious issue. Section 7 includes product notices from Microsoft describing the various restrictions on URL size in IE. In our deployments we have found difficulties with URLs of even somewhat smaller size (1K+). Many page generation and search engines utilize a large piece of the URL for maintaining state or providing arguments to downstream processes. This leaves little room for other applications.

I would strongly advise against using the AssertionID itself as the AssertionHandle component. As AssertionID’s are usually generated in a predictable fashion this would mean that an attacker could quite easily "guess" a valid AssertionID (4.1.1.9.4 – Forged SAML artifact).

The alternative artifact format described in Section 8 may also be of interest to you. It does not require use of the SourceID concept, instead it directly holds the URL of the artifact-to-assertion lookup service. One problem with the format in Section 8 is that depends upon the lookup service URL being of small size. If that is guaranteed in your deployments, it is also a good choice. This is not mandatory to implement, so you would need to make sure all parties had implemented this format.

30.

Bindings & Profiles Doc. If the assertion is created at the time of artifact creation and the request for this assertion comes after the assertion has expired, will the source site return the expired assertion or an error response or a successful response with no assertion?

[Prateek]

Any one of the following responses is conformant: (1) no assertion is returned with SUCCESS status code, (2) the expired assertion is returned with SUCCESS status code.

security-services message