There have been a few changes to the OASIS WSS specification since we last reworked its implementation in the WSE 2.0 build for the recent WS-Trust / WS-SecureConversation workshop.
Despite the link on the OASIS WSS home page, the most current document (at the time of writing) is under the "documents" link at the top of the page.
The major changes are to the namespace for WSS and the replacement of all uses of QNames with URI's for well-known values. For example
I personally think the move to URI's from QNames is a good one: serializing, deserializing, parsing and comparing QNames is much more complex and error prone than a URI.
Of course, there are some knock-on effects with this change, some of the affected attributes in the WSS specification have direct equivalents in the WS-Trust, WS-SecureConversation and WS-SecurityPolicy specifications and those have not yet been revised in line with the WSS change.
Overall, we're feeling that we need to make these changes to the WSE 2.0 release to best protect customers chances of interoperability when the OASIS WSS specification goes final (hopefully soon!). Despite the fact that WSE is all about delivering implementations of the latest specifications, even we sometimes wish there was a little less churn...
Posted by herveyw at January 6, 2004 12:13 AM+1 to keep in sync with OASIS spec. One question though, the UsernameToken profile in OASIS spec does not cover any encryption or dsig. the 2.0 tech preview did sign the message with a derived key. What is WSE 2.0 Final going to do by default?
Posted by: Davanum Srinivas at January 7, 2004 04:24 AMWSE 2.0 final will support signing and encrypting with a UsernameToken using a derived key. We will also have some usage recommendations regarding using the UsernameToken, primarily that it is used as a bootstrap token and exchanged for a different token, for example an SCT, as quickly as possible, or that a DerivedKeyToken is used in combination with the UsernameToken for signing / encrypting.
Posted by: Herveyw at January 7, 2004 08:39 AMHervey, you seem to be the perfect person to ask... and I have been desperately looking for someone to ask...
Here's the problem: (Totally ignoring X509 and Kerberos) we want to create a WSE2 conversation that starts by a clients sending a request to the server passing a UsernameToken. Upon this first request, the server will extract the usrnam/passwd and authenticate against an Oracle data provider. (Yes, we're using app-level user and role management.) If authenticated, the server will generate a SecurityContextToken to pass back to the client. Subsequent messages will contain the context token, recognized by the server, so the server won't have to re-authenticate against Oracle.
Of course, this implies TTLs, nonce, sequence values, etc. But the important thing is that the server may not be using ASP Sessions, so we need to embed the Username in the SecurityContextToken so the server can recall a user context for each message.
Is this possible with WSE2? There's zero documentation in the WSE2 docs about custom security tokens, propogation or negotiation.
Any help would be greatly appreciated! And I'll credit you on my own blog.
Best Regards,
\Steven