Senaka Fernando wrote:
Hi again,
Also adding to this discussion, we must be fair to REST users too,
Kaushalye and that makes sense. :)...
:) Yes. But still I do not accept exposing the password even for REST users.
I mean this is transport level authentication. The call come to the
service after the transport layer authentication is done. So let's keep
the authentication logic there.
If somebody needs to authorize(which is a different requirement), in
that case I agree with the fact that we can expose only the username.
Cheers,
Kaushalye
Therefore, if you have a SOAP-only service you are advised to use the SOAP
Header. But, if you use REST, you may read the HTTP headers.
Regards,
Senaka
Hi Kaushalye,
Yes I believe what you say is true. It is a violation of concern. However,
what if someone needs the header itself? We can do that. However, as you
say, it is not advised to use this approach. But, we can always have it.
May be this could go into a #ifdef block, so that it can be disabled by
default. I believe that makes sense.
Regards,
Senaka
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
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]
