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:45:43 GMT
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.


> 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]
>>> 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:

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

View raw message