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

Title: FW: [security-services-comment] SAP Comments On SAML Core-27 and Bindings-11

Responses to Questions on 
Profiles and Bindings:

 

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.