I don't see this as a dangerous practice as long as you can specify to the server what to allow and what not (i.e. a security policy). If the client tries to force the server to communicate insecurely and the server does not accept that I don't really see the problem. SSL cipher negotiations jump to mind as reference.
I am interested too in a way to make the server side a bit more flexible so that it recognizes/understands the security mechanism that has been used to protect the incoming message. The choice of whether the service should be accessible using a certain security mechanism should be left to another "module".
My 2 cents,
Robert.
On 7/1/06, Werner Dittmann <[EMAIL PROTECTED]> wrote:
Well, having the client to decide which way to authenticate would be dangerous and
a big security hole. The server has to be in charge and needs to decide
how to authenticate. If you require different ways of authentication I
would propose to setup different SOAP ports (service ports) with different names.
Regards,
Werner
debest wrote:
> but my prerequisite is that i must allow client to authenticate in the way it
> wants (es. with usernametoken, with certificate, ecc.). therefore i can't
> provide parameter in my WSDD file because in this way i can only set one
> authenticate method and so others are precluded.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
