Hi again, Also adding to this discussion, we must be fair to REST users too, Kaushalye and that makes sense. :)...
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]
