resolving wsu:Id, id and other references in WSS4J

[ro...@nokia.com]

Hi!

I mailed the message below a week ago to the members of the WSS4J project. The email addresses that I found on the web pages for WSS4J are probably old as I never got a reply or acknolwdgement, and as I noticed that other addresses are used on the list. So I now resent the message as is to the list.

Robert

----------------------------------------------------------------------------------------------
 From: 	Aarts Robert (Nokia-TP/Espoo)  
 Sent:	22 September, 2004 00:17
 To:	'dims@yahoo.com'; 'werner@apache.org'
 Cc:	Kemp John (Nokia-TP/Boston); Greg Whitehead (E-mail);  Scott Cantor (E-mail)
 Subject:	resolving wsu:Id, id and other references in WSS4J

You are probably well aware of the use of "wsu:Id" in WS-Security for referencing signed elements. There is a bit of controversy about the proposal for the upcoming WS-I Basic Security Profile to essentially restrict the names of ID-type attributes to "wsu:Id" for all but a few cases (where "id" is allowed). Nevertheless there are standards, and probably propietory specifications, out there that use other attribute names, the best example is saml:Assertion that has an AssertionID attribute, as you know.
I wanted to check if I could verify some soap messages that were created by an implementation of the Liberty Alliance ID-WSF 1.0 specifications (www.projectliberty.org). In these messages various headers and the soap body can be signed "by" a saml token. As I sort of expected (as some people who tried this a little while ago reported problems) this didn't work out-of- the-box. Now I'm not at all familiar with WSS4J, and actually not very familiar with WS-Sec and XMLSig either, but I am worried about that proposal in WS-I BSP. So I did some debugging and analyzing the WSS4J code. 
It's quite a piece of work, and it's quite an achievement of the coders/designers that I actually was able to understand what was going on in only 2 evenings.
My investigations resulted in essentially 3 issues:

1) In the SecurityTokenReference.getTokenElement() method there is dedicated code to dig out a saml:Assertion. However this code is only executed if the wsse:Reference has a ValueType attribute AND that attribute has the right value. Now when I look at the SAML Token profile **draft** spec (and I looked only at the committee draft version, 15) it seems to suggest to use a KeyIdentifier and then indeed the ValueType MUST be present. But the profile doesn't seem to exclude URI referencing, the language about this is vague (lines 272-273). Anyway there are (ID-WSF) implementations out there (admittedly often based on the June 2003 drafts, IDWSF has been out for almost a year) that use URI references. 
So I added a few lines of code in this like this:
// Robert Aarts: added next couple of lines to see if we can find the token by some know id-type attribute
  if (tokElement == null) {
    	tokElement = WSSecurityUtil.getElementByGenId(doc, uri);
     	//TODO: Robert Aarts: now we may have to ensure that we indeed got a token
  }
to me it seems that this would make the code a bit more lenient. I'm sure the folks on CC here (who are participants in the SSTC) can raise an issue about those lines containing vague text in the SAML token profile, if needed.

2) With the saml:Assertion as an example, there is the issue about ID-type attributes that may have another name than "wsu:Id", or even "id". I can see that it would be convenient if one could be sure that the name was always the same, but the reality is that we cannot. The situation will of course improve over time, especially if/when the "xml:id" will become widely used. (see http://www.w3.org/TR/xml-id/ that also provides good background).
Now I think that we can easily solve the problem as in practically all cases there are only a limited number of QName => ID-type-attrinbute-name mappings of interest. I suggest that we would allow for a list, in e.g. a properties file, of those mappings and this would get loaded at startup. To test this approach I added a bit of code to the WSSecurityUtil.findElementById() method. In here I created a Map to hold such QName => ID-type-attrinbute-name mappings (I'm aware that this is not the best place to create or load such a map, but only wanted to verify the approach) and populated it with the saml:Assertion information. I actually for this experiment left out the namespace too!. By stepping through with the debugger I verified that this is indeed sufficient to find an Assertion, e.g./i.e when the new code in SecurityTokenReference.getTokenElement()  gets executed. I strongly recommend for WSSE4J to include something along this approach but I'm not familiar enough with the overall design of WSS4J that I feel confident on suggesting how this would best be achieved. I attach the source files that I changed for this experiment.

3) I noticed that the WSSecurityUtil.findElementById() only finds elements that have "Id" named attributes, with a capital "I". As lowercase "id" is very common (see e.g "xml:id") I added support for that too. Again I don't think it is very useful to require that all specification or schema that define something that goes into a soap message have to be redefined just in order to use WS-Security to secure a message.

Anyway the conclusion, and really good news!, was that with this minimal changes WSS4J could now succesfully verify my example message! I believe that incorporating changes along those would make WSS4J much more lenient. Availability of a nice open source implementation like WSS4J certainly helps to gain adoption of the WS-Security specification, and hence to increase the level of security of web services. I'd would be inclined to believe (but I'm biased) that nowhere is WS-Security used as much as in ID-WSF implementations and deployments, and people have tried to use WSS4J in their ID-WSF implementations, suggesting that it would be beneficial for all if WSS4J would support this slightly different, more lenient, interpretation of the WS-Security specification.
The second, and for me personally more important, conclusion is that there indeed isn't such a very strong need for a "MUST" on "wsu:Id". On the contrary I believe that such a requirement will only needlessly hinder adoption of WS-Security.

Attached are: 
- the changed WSSecurityUtil.java  <<WSSecurityUtil.java>> 
- the changed SecurityTokenReference.java <<SecurityTokenReference.java>> 
- new test code that I used: TestWSSecurityVAlts.java that takes a file name as argument. The file is supposed to contain a soap message. <<TestWSSecurityVAlts.java>> 
- an example of an ID-WSF message that I used for the testing: samltokex2.xml (courtesy of Greg Whitehead, Trustgenix). <<samltokex2.xml>> 

yours sincerely,

	Robert Aarts

P.S. Could there be a bug in saml Assertion verification ? The "notOnOrAfter" condition on this example should have triggered an exception according to my expectations....

P.P.S. I obviously didn't study at all what would be needed (if anything) to support construction of a Security header like the one in my example. I.e. when elements that do not have a "wsu:Id" need to be signed.

Re: resolving wsu:Id, id and other references in WSS4J

[Davanum Srinivas <da...@gmail.com>]

Robert,

Let's please treat this as a bug, please create a new bug in JIRA
(http://issues.apache.org/) and upload just the diff (run "cvs diff
-u" from the ws-fx/wss4j directory) after you create the bug.

Thanks,
dims


On Thu, 7 Oct 2004 15:06:21 +0300, robert.aarts@nokia.com
<ro...@nokia.com> wrote:
> Hi!
> 
> I mailed the message below a week ago to the members of the WSS4J project. The email addresses that I found on the web pages for WSS4J are probably old as I never got a reply or acknolwdgement, and as I noticed that other addresses are used on the list. So I now resent the message as is to the list.
> 
> Robert
> 
> ----------------------------------------------------------------------------------------------
>  From:  Aarts Robert (Nokia-TP/Espoo)
>  Sent:  22 September, 2004 00:17
>  To:    'dims@yahoo.com'; 'werner@apache.org'
>  Cc:    Kemp John (Nokia-TP/Boston); Greg Whitehead (E-mail);  Scott Cantor (E-mail)
>  Subject:       resolving wsu:Id, id and other references in WSS4J
> 
> You are probably well aware of the use of "wsu:Id" in WS-Security for referencing signed elements. There is a bit of controversy about the proposal for the upcoming WS-I Basic Security Profile to essentially restrict the names of ID-type attributes to "wsu:Id" for all but a few cases (where "id" is allowed). Nevertheless there are standards, and probably propietory specifications, out there that use other attribute names, the best example is saml:Assertion that has an AssertionID attribute, as you know.
> I wanted to check if I could verify some soap messages that were created by an implementation of the Liberty Alliance ID-WSF 1.0 specifications (www.projectliberty.org). In these messages various headers and the soap body can be signed "by" a saml token. As I sort of expected (as some people who tried this a little while ago reported problems) this didn't work out-of- the-box. Now I'm not at all familiar with WSS4J, and actually not very familiar with WS-Sec and XMLSig either, but I am worried about that proposal in WS-I BSP. So I did some debugging and analyzing the WSS4J code.
> It's quite a piece of work, and it's quite an achievement of the coders/designers that I actually was able to understand what was going on in only 2 evenings.
> My investigations resulted in essentially 3 issues:
> 
> 1) In the SecurityTokenReference.getTokenElement() method there is dedicated code to dig out a saml:Assertion. However this code is only executed if the wsse:Reference has a ValueType attribute AND that attribute has the right value. Now when I look at the SAML Token profile **draft** spec (and I looked only at the committee draft version, 15) it seems to suggest to use a KeyIdentifier and then indeed the ValueType MUST be present. But the profile doesn't seem to exclude URI referencing, the language about this is vague (lines 272-273). Anyway there are (ID-WSF) implementations out there (admittedly often based on the June 2003 drafts, IDWSF has been out for almost a year) that use URI references.
> So I added a few lines of code in this like this:
> // Robert Aarts: added next couple of lines to see if we can find the token by some know id-type attribute
>   if (tokElement == null) {
>         tokElement = WSSecurityUtil.getElementByGenId(doc, uri);
>         //TODO: Robert Aarts: now we may have to ensure that we indeed got a token
>   }
> to me it seems that this would make the code a bit more lenient. I'm sure the folks on CC here (who are participants in the SSTC) can raise an issue about those lines containing vague text in the SAML token profile, if needed.
> 
> 2) With the saml:Assertion as an example, there is the issue about ID-type attributes that may have another name than "wsu:Id", or even "id". I can see that it would be convenient if one could be sure that the name was always the same, but the reality is that we cannot. The situation will of course improve over time, especially if/when the "xml:id" will become widely used. (see http://www.w3.org/TR/xml-id/ that also provides good background).
> Now I think that we can easily solve the problem as in practically all cases there are only a limited number of QName => ID-type-attrinbute-name mappings of interest. I suggest that we would allow for a list, in e.g. a properties file, of those mappings and this would get loaded at startup. To test this approach I added a bit of code to the WSSecurityUtil.findElementById() method. In here I created a Map to hold such QName => ID-type-attrinbute-name mappings (I'm aware that this is not the best place to create or load such a map, but only wanted to verify the approach) and populated it with the saml:Assertion information. I actually for this experiment left out the namespace too!. By stepping through with the debugger I verified that this is indeed sufficient to find an Assertion, e.g./i.e when the new code in SecurityTokenReference.getTokenElement()  gets executed. I strongly recommend for WSSE4J to include something along this approach but I'm not familiar enough with the overall design of WSS4J that I feel confident on suggesting how this would best be achieved. I attach the source files that I changed for this experiment.
> 
> 3) I noticed that the WSSecurityUtil.findElementById() only finds elements that have "Id" named attributes, with a capital "I". As lowercase "id" is very common (see e.g "xml:id") I added support for that too. Again I don't think it is very useful to require that all specification or schema that define something that goes into a soap message have to be redefined just in order to use WS-Security to secure a message.
> 
> Anyway the conclusion, and really good news!, was that with this minimal changes WSS4J could now succesfully verify my example message! I believe that incorporating changes along those would make WSS4J much more lenient. Availability of a nice open source implementation like WSS4J certainly helps to gain adoption of the WS-Security specification, and hence to increase the level of security of web services. I'd would be inclined to believe (but I'm biased) that nowhere is WS-Security used as much as in ID-WSF implementations and deployments, and people have tried to use WSS4J in their ID-WSF implementations, suggesting that it would be beneficial for all if WSS4J would support this slightly different, more lenient, interpretation of the WS-Security specification.
> The second, and for me personally more important, conclusion is that there indeed isn't such a very strong need for a "MUST" on "wsu:Id". On the contrary I believe that such a requirement will only needlessly hinder adoption of WS-Security.
> 
> Attached are:
> - the changed WSSecurityUtil.java  <<WSSecurityUtil.java>>
> - the changed SecurityTokenReference.java <<SecurityTokenReference.java>>
> - new test code that I used: TestWSSecurityVAlts.java that takes a file name as argument. The file is supposed to contain a soap message. <<TestWSSecurityVAlts.java>>
> - an example of an ID-WSF message that I used for the testing: samltokex2.xml (courtesy of Greg Whitehead, Trustgenix). <<samltokex2.xml>>
> 
> yours sincerely,
> 
>         Robert Aarts
> 
> P.S. Could there be a bug in saml Assertion verification ? The "notOnOrAfter" condition on this example should have triggered an exception according to my expectations....
> 
> P.P.S. I obviously didn't study at all what would be needed (if anything) to support construction of a Security header like the one in my example. I.e. when elements that do not have a "wsu:Id" need to be signed.
> 
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/