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]
