[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services-comment] SAP Comments On SAML Core-27 andBindings-11
Hi, I have been following SAML v1 activities for some time. Currently I am participating in JSR 155 Expert Group. I have reviewed the core-27 and bindings-11 documents with security developers in SAP. Please find the collected comments on these two documents. 1. Core Document. Line # 331. Why "Indeterminate" DecisionType is required? "Permit" and "Deny" are enough. When making an authorization decision statement, what extra information PDP (Policy Decision Point) is providing by setting "DecisionType" to "Indeterminate"? Some explanation would be useful why "Indeterminate" is required. 2. Core Document. Line # 350. Elements "AssertionIDReference" and "Assertion" do not the expressive enough names. "AssertionID" is already a reference to the underlying assertion. Why can't we have something simpler like "AssertionByRef" and "AssertionByVal"? 3. Core Document. Line # 366. Element "AssertionID" should be "AssertionIDReference". 4. Core Document. Line # 371. On lines Line 231 and 1074, there is a usage of term "authentication assertion". Then "Assertion" element has "AuthenticationStatement" as a child element. I would say this causes confusion. I think there is nothing like authentication assertion at least if you look at the schema. I would suggest that terms like "authentication assertion", "attribute assertion" should be removed. 5. Core Document. Line # 493. What is the difference and relationship between "Audience" and "Target"? Both are "anyURI" type. Both talk about "party". There should be some explanation about the difference between these two elements. I think the difference lies in the usage of these two elements. 6. Core Document. Line # 541. "saml:Target" has "minOccurs" as 1. It is inconsistent with the rest of document for handling the default values. In the rest of document, if "minOccurs" and "maxOccurs" are supposed to have default values, it is not mentioned in the schema. 7. Core Document. Line # 639. Inconsistency in the attribute schema definition. "SecurityDomain" attribute definition, which is "optional", does not have the attribute "use" as "optional" whereas on line #714, "IPAddress" attribute definition has "use" as "optional". I think it should be consistent through out the document. 8. Core Document. Line # 678. Element "AuthenticationLocality" seems confusing. "AuthenticatedPrincipalLocality" (or something like this) makes more sense. "AuthenticationLocality" seems to provide the information about where the authentication was done especially when you look at this attribute at the same place, where you see attributes like "AuthenticationMethod" and "AuthenticationInstant". 9. Core Document. Line # 829. With the current "Action" schema, we can't authorize a subject for a range. In other words, PDP can't set two related Action items. A specific implementation might interpret two actions as if they are related. For example, you need to authorize a subject for his "SpendingLimit" from $1000 to $2000. You can't do that? In SAP applications (as everywhere else!), supporting authorizations in some ranges, responsibilities is often required. 10. Core Document. Line # 863/865. "AttributeNamespace" and "AttributeName' are optional and in the schema definition, on lines 871/872, these attributes are required. 11. Core Document. Line # 877. "AttributeValue" is not "Any Number" as minOccurs=1 (default value). 12. Issue DS-4-11. Core Document. Line # 969. Why can't we take "RespondWith" zero statement resulting into a response with "StatusCode" as "Success"? This can be useful where client wants to test SAML Processor (without requesting any assertion information) if it accepts SAML requests or not. 13. Core Document. Line # 1020. When relying party gets multiple artifacts, it needs to get the corresponding assertions. It sends a single SAML request with all the artifacts, lets say there are errors in some assertions retrieval and some are retrieved correctly at source site. What kind of respond is returned by source site? 14. Core Document. Line # 1078. What is the difference between "ConfirmationMethod" element in "AuthenticationQuery" and "AuthenticationMethod" attribute in "AuthenticationStatement"? There should be some explanation. What is the difference between "ConfirmationMethod" in "AuthenticationQuery" and "ConfirmationMethod" in "SubjectConfirmation"? Some explicit differences or similarities would be helpful. 15. Core Document. Line # 1081. It says that there can be multiple assertions with multiple authentication statements for a given AuthenticationQuery. I think the responder should return a single assertion element (as defined in section 2.3.3) with multiple authentication statements. Then it says that the subject element of returned assertions MUST be identical to the subject element of the query. First of all, I think statement should say that "subject element of authentication statements". Second, if the subject elements are identical in all the returned authentication statements, and then "AuthenticationInstant", "AuthenticationLocality" and "AuthorityBinding" are also identical, it means that all the authentication statements are identical except for "AuthenticationMethod". So why do we need multiple authentication statements? Am I missing something here? 16. Core Document. Line # 1109. Does the value "Error.Reciver.ResourceNotRecognized" belong to "StatusCode" value or is it the recommended value for the "StatusMessage"? 17. Issue DS-12-06. Core Document. Line # 1112. In "AttributeQuery", if no attribute is specified, the list of desired attributes is implementation specific. It makes more sense to return all the attributes. This can be very useful in the case where a subject might have large number of attributes (say 100) and you need to get all the attributes. With the current mechanism, you need to write all the attributes, which is a tedious job. 18. Core Document. Line # 1244/1246. "Receiver" and "Sender" seem inappropriate. These are the values for "StatusCode" element, which is a part of "Response". Please notice that there are two messages, "Request" and "Response". Something like "ProcessorError" and "RequesterError" makes more sense, which explicitly shows an error and its location. 19. Core Document. Line # 1312. Why this section is not valid for AuthrizationQuery? How do you match a subject in the case of authorization decision query? 20. Core Document. Line # 1381. "Message Integrity" should be changed to "Assertion Integrity". 21. Core Document. Line # 1433. Statement should be "An assertion ..........................., if the super signature applies "to" all the elements......" 22. Core Document. Line # 1438. "SAML message" should be changed to "SAML structure" (or something like this) as SAML assertion is not an SAML message. 23. Core Document. Line # 1622. "ActionNamespace" should be changed to "Action Namespace" 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. 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. 26. Bindings & Profiles Doc. Line # 346. In the example, there should be a closing tag "</samlp:Response>" 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. 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. 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? 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? Regards, Dipak Chopra Technology Architecture Group, SAP
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC