Hi Kaushalye and Senaka, For our web services we allow the http basic auth but we tell our customers to use it only within a secure environment, so they are using it within a secure network or they use SSL in addition. It is used for convenience in situations where the user is not worried about outsiders, but doesn't want to leave their userid and password fully exposed. The base64 encoding is easy to decode, but at least hides the details from casual observation.
For the REST case, it becomes more important as WS-SECURITY is not available. For a REST GET call I do not want to require userid and password in the URI or query string, so the http basic auth is a way around that. Thanks, -Dave. -----Original Message----- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 5:52 AM To: Apache AXIS C Developers List Subject: Re: Exposing Transport Headers to a Service Hi Kaushalye, Even the Basic Authentication scheme works with a Challenge response mechanism. And, therefore, if the client is sending authentication information without verifying whether it is required, would be considered as intentional. And, in such a situation, if the service managed to maliciously capture client information, it should not be our problem. The proxy authentication scheme has a similar behaviour except that there is a guarantee that the proxy wont forward authentication information to down stream nodes, according to the specification. The requirement would rather be to use the HTTP Authentication info for application level authentication, which AFAIK is allowed by the HTTP Authentication specification. The vulnerability to spoofing is inherent in the Basic Authentication scheme and the client has the right not to use the Basic Authentication scheme as a means for Authentication. Thus, it would rather be an agreement between the server and the client to exchange such information, and if both parties do agree, we won't mind letting them go ahead. Also, there is no such requirement for a server to stop forwarding authentication info to a delegated resource, but rather, it is being allowed for a server to forward it to the resource according to the HTTP Authentication specification. Obviously the whole idea is not to protect a client, but to protect the service. We do provide client security from the client-side. Regards, Senaka > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
