You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Senaka Fernando <se...@wso2.com> on 2008/02/12 11:37:04 UTC
Exposing Transport Headers to a Service
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Exposing Transport Headers to a Service
Posted by Senaka Fernando <se...@wso2.com>.
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: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>
>
>
> --
> http://blog.kaushalye.org/
> http://wso2.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Exposing Transport Headers to a Service
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>
--
http://blog.kaushalye.org/
http://wso2.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org