You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Ruwan Yatawara <ru...@wso2.com> on 2013/06/28 11:18:37 UTC
Introducing transport level (HTTPs etc.) access restriction to APIs
Hi All,
We have a requirement to introduce access restrictions to APIs based
transport type. As it is done for proxy services, we wish to introduce a
"transport" attribute based on which, access to the API will be deflected
or approved.
>From what i observed, we may introduce a condition in canProcess() method
of API class, to validate the inTransport of message context against the
configured list of transports. But is it the correct way to achieve this?
Pls. find attached sample API xml.
Your advise on this regard would be highly appreciated.
Thanks and Regards,
Ruwan Yatawara
Re: Introducing transport level (HTTPs etc.) access restriction to APIs
Posted by Ruwan Yatawara <ru...@wso2.com>.
On Tue, Jul 2, 2013 at 9:46 AM, Udayanga Wickramasinghe <
mastershield2007@gmail.com> wrote:
> converting
Thanks for the response Udayanga! I was indeed able to handle this without
meddling with the axis2 code.
This is how i did it.
1) Introduced a new transports property to api configuration xml (If a
transport is not listed in the api, it will be assumed, the API is
accessible via both HTTP and HTTPs)
2) Introduced a validation in the canProcess method to see if the transport
with which the api is accessed is listed in the transports section of said
api.
3) If its a restricted transport and canProcess returns false, a warning
will be listed on console and a property will be set in the synapse context
to indicate transport was rejected.
4) Message will be directed to main sequence as usual, the user may include
a filter mediator in the main sequence to display a custom error message
using the variables added to synapse/axis2 context. Pls. refer below
example.
E.g.
<!-- Filter for handling Rest-API access via unauthorized transports -->
<filter source="$ctx:TRANSPORT_DENIED" regex="true">
<payloadFactory>
<format>
<fault>
<code>403</code>
<type>Status report</type>
<message>Forbidden</message>
<description>Unsupported Transport $2. The
requested resource (/$1) is not available.</description>
</fault>
</format>
<args>
<arg expression="$axis2:REST_URL_POSTFIX"/>
<arg expression="$ctx:IN_TRANSPORT"/>
</args>
</payloadFactory>
<property name="HTTP_SC" value="403" scope="axis2"/>
<property name="RESPONSE" value="true"/>
<header name="To" action="remove"/>
<property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>
<property name="ContentType" scope="axis2" action="remove"/>
<property name="Authorization" scope="transport"
action="remove"/>
<property name="Host" scope="transport" action="remove"/>
<property name="Accept" scope="transport" action="remove"/>
<send/>
</filter>
Thanks,
Ruwan Yatawara
Re: Introducing transport level (HTTPs etc.) access restriction to APIs
Posted by Udayanga Wickramasinghe <ma...@gmail.com>.
Please find my comments in line..
On Mon, Jul 1, 2013 at 1:57 PM, Ruwan Yatawara <ru...@wso2.com> wrote:
> Thanks Udayanga!
>
> However, when looking through the Syanpse+Axis code, i came to the
> understanding that, transport validation is done via axis2 code (It's the
> same block of code) for both Proxy Services and APIs. Before dispatching a
> call to Axis2, Synapse will verify whether the message context includes a
> service. When it comes to APIs, in which
>
True transport validation always happens at axis level. However for a
typical incoming request, Axis2 is what responsible for dispatching request
to Synapse mediation layer , NOT the other way around.. Problem is each
proxy service has a unique axis2 service instance at runtime , but APIs and
main sequence do not (they have one service instance '__SynapseService' ie:-
n:1 mapping ).
> case there isn't an attached service, Synapse will specify the default
> "__SynapseService" as the service.
>
> Because of this, when it comes down to the Axis level, Proxy Service and
> Rest API calls will both be treated as services (since both have services
> assign to them). When Service#getExposedTransports method is called, whilst
> the proxy service will relay back transports configured for that "specific"
> service, Rest APIs would always return the exposed transports for the
> "default" service (which are always HTTP & HTTPS).
>
For reasons above which i mentioned ,we can't consider APIs as a pure
service in axis2 terms, rather an extension of 'main'. For instance calling
#setExposedTransports,etc will affect 'main' sequence as well as all APIs
equally.
>
> As a workaround for this I was thinking, maybe we can constitute some sort
> of "Pseudo-Service" (Since it is anyhow being treated at Axis level as a
> Service) out of each Rest API, and maintain a Deployer that will set/update
> parameters like "ExposedTransports" that may in turn be accessed via Axis.
>
> I'm not entirely sure if this is the right thing to do. But if it is, I
> can achieve my desired outcome in Syanpse level itself, without having to
> do any changes to Axis.
>
> You don't have to modify Axis2 layer anyway. Also converting Synapse APIs
into proper axis services may also defeat the purpose of Restful API's (of
which it was first envisioned to skip axis2 layer entirely to give more
leverage).
Regards
Udayanga
Please feel free to weigh in your thoughts.
>
> Cheers,
> Ruwan Yatawara
>
>
> On Fri, Jun 28, 2013 at 7:36 PM, Udayanga Wickramasinghe <
> mastershield2007@gmail.com> wrote:
>
>> Hi,
>> This would work ok but i think there is a slight problem. Each time
>> a message is received by a non-allowed transport of an API , it will arrive
>> until the synapse mediation layer and will endup in the 'main' sequence
>> (because respective API has rejected it) . Because such request is intended
>> for a proper API ( But just not passing through allowed transport channel)
>> user might not want it to go through the 'main' sequence. Hence you may
>> need to handle 'dropping' off the message gracefully from the API .
>> However APIs are not Axis services ,therefore i think this runtime
>> checking is not as effective as using AxisService#setExposedTransports
>> method (used in ProxyServices)...
>>
>> Regards
>> Udayanga
>>
>>
>>
>> On Fri, Jun 28, 2013 at 5:18 AM, Ruwan Yatawara <ru...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> We have a requirement to introduce access restrictions to APIs based
>>> transport type. As it is done for proxy services, we wish to introduce a
>>> "transport" attribute based on which, access to the API will be deflected
>>> or approved.
>>>
>>> From what i observed, we may introduce a condition in canProcess()
>>> method of API class, to validate the inTransport of message context against
>>> the configured list of transports. But is it the correct way to achieve
>>> this?
>>>
>>> Pls. find attached sample API xml.
>>>
>>> Your advise on this regard would be highly appreciated.
>>>
>>>
>>>
>>> Thanks and Regards,
>>>
>>> Ruwan Yatawara
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>
>>
>>
>> --
>> http://www.udayangawiki.blogspot.com
>>
>
>
--
http://www.udayangawiki.blogspot.com
Re: Introducing transport level (HTTPs etc.) access restriction to APIs
Posted by Ruwan Yatawara <ru...@wso2.com>.
Thanks Udayanga!
However, when looking through the Syanpse+Axis code, i came to the
understanding that, transport validation is done via axis2 code (It's the
same block of code) for both Proxy Services and APIs. Before dispatching a
call to Axis2, Synapse will verify whether the message context includes a
service. When it comes to APIs, in which case there isn't an attached
service, Synapse will specify the default "__SynapseService" as the
service.
Because of this, when it comes down to the Axis level, Proxy Service and
Rest API calls will both be treated as services (since both have services
assign to them). When Service#getExposedTransports method is called, whilst
the proxy service will relay back transports configured for that "specific"
service, Rest APIs would always return the exposed transports for the
"default" service (which are always HTTP & HTTPS).
As a workaround for this I was thinking, maybe we can constitute some sort
of "Pseudo-Service" (Since it is anyhow being treated at Axis level as a
Service) out of each Rest API, and maintain a Deployer that will set/update
parameters like "ExposedTransports" that may in turn be accessed via Axis.
I'm not entirely sure if this is the right thing to do. But if it is, I can
achieve my desired outcome in Syanpse level itself, without having to do
any changes to Axis.
Please feel free to weigh in your thoughts.
Cheers,
Ruwan Yatawara
On Fri, Jun 28, 2013 at 7:36 PM, Udayanga Wickramasinghe <
mastershield2007@gmail.com> wrote:
> Hi,
> This would work ok but i think there is a slight problem. Each time
> a message is received by a non-allowed transport of an API , it will arrive
> until the synapse mediation layer and will endup in the 'main' sequence
> (because respective API has rejected it) . Because such request is intended
> for a proper API ( But just not passing through allowed transport channel)
> user might not want it to go through the 'main' sequence. Hence you may
> need to handle 'dropping' off the message gracefully from the API .
> However APIs are not Axis services ,therefore i think this runtime
> checking is not as effective as using AxisService#setExposedTransports
> method (used in ProxyServices)...
>
> Regards
> Udayanga
>
>
>
> On Fri, Jun 28, 2013 at 5:18 AM, Ruwan Yatawara <ru...@wso2.com> wrote:
>
>> Hi All,
>>
>> We have a requirement to introduce access restrictions to APIs based
>> transport type. As it is done for proxy services, we wish to introduce a
>> "transport" attribute based on which, access to the API will be deflected
>> or approved.
>>
>> From what i observed, we may introduce a condition in canProcess() method
>> of API class, to validate the inTransport of message context against the
>> configured list of transports. But is it the correct way to achieve this?
>>
>> Pls. find attached sample API xml.
>>
>> Your advise on this regard would be highly appreciated.
>>
>>
>>
>> Thanks and Regards,
>>
>> Ruwan Yatawara
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> http://www.udayangawiki.blogspot.com
>
Re: Introducing transport level (HTTPs etc.) access restriction to APIs
Posted by Udayanga Wickramasinghe <ma...@gmail.com>.
Hi,
This would work ok but i think there is a slight problem. Each time
a message is received by a non-allowed transport of an API , it will arrive
until the synapse mediation layer and will endup in the 'main' sequence
(because respective API has rejected it) . Because such request is intended
for a proper API ( But just not passing through allowed transport channel)
user might not want it to go through the 'main' sequence. Hence you may
need to handle 'dropping' off the message gracefully from the API .
However APIs are not Axis services ,therefore i think this runtime checking
is not as effective as using AxisService#setExposedTransports method (used
in ProxyServices)...
Regards
Udayanga
On Fri, Jun 28, 2013 at 5:18 AM, Ruwan Yatawara <ru...@wso2.com> wrote:
> Hi All,
>
> We have a requirement to introduce access restrictions to APIs based
> transport type. As it is done for proxy services, we wish to introduce a
> "transport" attribute based on which, access to the API will be deflected
> or approved.
>
> From what i observed, we may introduce a condition in canProcess() method
> of API class, to validate the inTransport of message context against the
> configured list of transports. But is it the correct way to achieve this?
>
> Pls. find attached sample API xml.
>
> Your advise on this regard would be highly appreciated.
>
>
>
> Thanks and Regards,
>
> Ruwan Yatawara
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
--
http://www.udayangawiki.blogspot.com