You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Doughty, Michael" <Mi...@bmc.com> on 2010/02/08 09:58:35 UTC

Two questions about security features

I have three questions that I need some information on.  One of them is on Rampart, and one on Axis2, and one on a particular scenario of the first two questions.

(1)  I've noticed that Rampart seems to support the WS-SecurityPolicy 1.0 tokens "SupportingTokens", "SignedSupportingTokens", "EncryptedSupportingTokens", and "SignedEncryptedSupportingTokens". However, if any variation of the "SupportingTokens" element is used to specify a UsernameToken be sent to the service, none of them actually seem to be enforced on the service-side in the same way.  This means if I use "SignedSupportingTokens" to specify UsernameToken, the service does not require that the client actually sign its UsernameToken in the request.  Similarly, "EncryptedSupportingTokens" and "SignedEncryptedSupportingTokens" do not enforce encryption.

When the "EncryptedParts" element is used to specify that the SOAP Body should be encrypted, it returns an error "The signature or decryption is invalid" when a message is sent to it without the SOAP Body encrypted.  However, when I specify the UsernameToken with the Name and Namespace fields of the "EncryptedParts" element, the same sort of enforcement doesn't happen.

Is there any way at all to enforce UsernameToken encryption in Rampart outside of writing my own module to do the enforcing?

(2) We use UsernameToken in PasswordText encoding to send credentials to pass to the underlying application.  However, we also add Nonce and Created.  We realize this is not required by PasswordText encoding, but it isn't disallowed by the standard (the word "SHOULD" is used to describe the addition of these values when using PasswordText encoding).  What we could like to do is enforce the uniqueness of the combination of Nonce and Created values when they are passed in.

Now I realize that this is not something Rampart will do automatically, so I'd like to retrieve the decrypted message at runtime, perhaps from the password callback class, retrieve those values from that message and enforce their uniqueness there.  Is it possible to retrieve the decrypted SOAP header so that I could look for the proper values inside of the implementation of the password callback class?  If not, is it possible to do from the implementation of each Web service?

I guess if those are not possible, I could write a module to do this.  We were trying to avoid having to do this though because I perceive it would add more processing time.

(3) If I have to write modules for 1 and 2, then I would likely have to position the first one to be executed before the rampart module is executed and the message decrypted, and the latter one to be executed after the rampart module does this decryption.  How would I modify the configuration to allow one module to be executed before Rampart and one to be executed after?

Any help you could give me would be greatly appreciated at this point.  I've looked as hard as possible for answers to these things on the net and through two Axis2 books I purchased, but I can't seem to find complete information.