axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <>
Subject Re: Exposing Transport Headers to a Service
Date Tue, 12 Feb 2008 11:37:57 GMT
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.


> 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]
>> Regards,
>> Senaka
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message