Hi Senaka,
The basic authentication is always recommended to use with a
cryptographically secured connection. If not, it's not a difficult task
to crack the username and password pair, which is in the form of base64
encoded text. So if the client/server must agreed upon the kind of
transport they are using.
The authentication is done by the transport level, which can be
encrypted or in plain text. Whatever the form, I do not recommend that
we expose the UN/PW pair to the service. I feel that we are trying to
place some functionalities where it is not belonged to. Correct me if
I'm wrong. If the authentication need to be done in the SOAP layer,
there are other mechanisms such as usernam tokens in the security header.
Cheers,
Kaushalye
Senaka Fernando wrote:
Hi all,
Based on Dave's request, I have added the ability for a service to observe
incoming Transport Headers. I think this is a valid requirement of a
Service Author.
Also, this creates some concern about security of a client-request.
However, I believe that we can answer these issues in this manner.
1. A client must trust a service he/she would like to access
2. Intermediate Transport nodes must be aware that sensitive information
should only reach desired destinations, and if it goes elsewhere that is a
problem of the underlying Transport (the interface between client/server).
3. According to our architecture we do not bother about Transport Level
Security within the client/server interface, with regard to headers.
4. Even if we uphold this fix, the user can still tweak it.
5. This imposes no threat to Service security which is the engine's
primary concern.
6. Also, we do provide functionality on the client side to pre-determine
whether valid requests are made before forwarding sensitive information
such as usernames and passwords.
However, I would like to know your thoughts on this fix, [1].
[1] https://issues.apache.org/jira/browse/AXIS2C-981
Regards,
Senaka
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://blog.kaushalye.org/
http://wso2.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
