Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

[Pubudu Gunatilaka]

On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
wrote:

>
>
> On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
> wrote:
>
>> Are we going to use durable subscription here? When ever gw node down and
>> re start,
>> it should fetch messages which add to the topic during the down time.
>> In case durable subscription what is the mechanism to create client id
>> for each gw.Is that discussed and confirm?
>>
>
> No, we are not going to use durable topic. New gateways (scaling) or if we
> restart a gateway, existing APIs will fetch via API Manager core. Only new
> API (after boot up) notifications are getting via the topic and actual API
> will fetch from the core. ( we can try what sanjeewa mention - getting API
> from the topic - but previous APIs need to fetch from the core)
>
>

When we restart a gateway node, it would be better to fetch only the
updated APIs as well as the new APIs. Restarted gateway has the already
fetched APIs and it is not worth to fetch all the APIs again. We will have
to use durable subscription for this.

If we consider the container scenario, are we persisting gateway artifacts?
If we are not persisting gateway artifacts and restart the gateway
container, then we need to fetch all the APIs from the core. IMHO it would
better to persist data and load that data at restart as it would take time
to fetch all the APIs from the core.

Thank you!
-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

[Lakmal Warusawithana]

On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
wrote:

>
>
> On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
> wrote:
>
>> Are we going to use durable subscription here? When ever gw node down and
>> re start,
>> it should fetch messages which add to the topic during the down time.
>> In case durable subscription what is the mechanism to create client id
>> for each gw.Is that discussed and confirm?
>>
>
> No, we are not going to use durable topic.
>

Sorry I mean to say durable subscription.


> New gateways (scaling) or if we restart a gateway, existing APIs will
> fetch via API Manager core. Only new API (after boot up) notifications are
> getting via the topic and actual API will fetch from the core. ( we can try
> what sanjeewa mention - getting API from the topic - but previous APIs need
> to fetch from the core)
>
>
>>
>> On Tue, Apr 25, 2017 at 2:20 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> API create/update/delete are similar type of events IMO. After we
>>> getting any event for these what we have to do is redeploy API or discard
>>> it. IMO if possible we should try to avoid web service call based update
>>> and send ballerina file with event itself(if its not heavy object). Other
>>> type of event is subscription change(which originates from API store). And
>>> for the throttling we need another topic. So as i see we can survive with
>>> only 3 topics at the moment.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Tue, Apr 25, 2017 at 11:44 AM, Nuwan Dias  wrote:
>>>
 The type of events we're talking about here are rare events. API
 creation, subscription, etc won't happen that frequently. So I don't think
 there will be much load on the broker as such.

 Architecturally having separate topics will be clean. The code and the
 error handling parameters (dead letter queue) can be defined per event
 type. However I think it'll cause additional burden to the Gateway since
 the Gateway now has to establish and maintain several connections to the
 broker. And since these connections need to happen at startup, each
 connection that needs to be established adds up to the startup time of the
 Gateway. So I would prefer to minimize the number of topics as much as
 possible.

 On Tue, Apr 25, 2017 at 11:09 AM, Thilini Shanika 
 wrote:

> Hi All,
>
> According to APIM C5 architecture, the events like API create, API
> lifecycle status change, API subscriptions are notified to APIM gateway 
> via
> JMS topic/topics in the broker.
>
> Following diagram depicts how APIM core, broker and gateway components
> interact when there is an event generated from Core.
>
>
> Following are the two options we came up while implementing above
> event publishing scenario from APIM Core --> Broker --> Gateways.
>
> *1) Publishing all the events to a common topic *
>
> A single topic is maintained in broker and all the gateways are
> subscribed to this common topic. APIM core publishes all the events
> generated from APIM to this particular topic. After topic subscription, 
> the
> gateways keep listening to the topic and once a notification is received,
> it has to be filtered to identify the event type and perform the required
> action. The events like API create, lifecycle status change, API
> subscription etc are getting published through this common topic and the
> event type has to be reflected in the notification itself so that the
> gateways can identify the notification and decide what has to be performed
> next. In this case, it has to maintain a single connection to JMS topic
> from each gateway.
>
>
> ​
>
> *2) Maintaining dedicated topics for each event type*
>
> In this option, we can either maintain dedicated topic for each event
> type (API Create, API publish, API subscription) or maintain dedicated
> topics for API publisher, API store events. As per this solution, the
> gateways have to subscribe to all these topics and keep listening to all 
> of
> them. In that case, gateways have to establish and maintain more
> connections with the broker, since there are several topic subscriptions.
> Once a notification is generated from APIM and published to the relevant
> topic, that particular notification is received by the relevant gateway
> service and process the message to perform the next action. But, the
> filtering logic which has to be executed in ballerina gateway side is less
> complex in this solution.
>
>
> ​
> What would be the best option here? Your suggestions and comments are
> highly appreciated.
>
> Thanks
> Thilini
>
>
>
> --
> Thilini Shanika
> Senior Software Engineer
> WSO2, Inc.; http://wso2.com
> 20, Palmgrove Avenue, Colombo 3
>
> E-mail: tgtshan...@gmail.com
>

Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

[Lakmal Warusawithana]

On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena  wrote:

> Are we going to use durable subscription here? When ever gw node down and
> re start,
> it should fetch messages which add to the topic during the down time.
> In case durable subscription what is the mechanism to create client id for
> each gw.Is that discussed and confirm?
>

No, we are not going to use durable topic. New gateways (scaling) or if we
restart a gateway, existing APIs will fetch via API Manager core. Only new
API (after boot up) notifications are getting via the topic and actual API
will fetch from the core. ( we can try what sanjeewa mention - getting API
from the topic - but previous APIs need to fetch from the core)


>
> On Tue, Apr 25, 2017 at 2:20 PM, Sanjeewa Malalgoda 
> wrote:
>
>> API create/update/delete are similar type of events IMO. After we getting
>> any event for these what we have to do is redeploy API or discard it. IMO
>> if possible we should try to avoid web service call based update and send
>> ballerina file with event itself(if its not heavy object). Other type of
>> event is subscription change(which originates from API store). And for the
>> throttling we need another topic. So as i see we can survive with only 3
>> topics at the moment.
>>
>> Thanks,
>> sanjeewa.
>>
>> On Tue, Apr 25, 2017 at 11:44 AM, Nuwan Dias  wrote:
>>
>>> The type of events we're talking about here are rare events. API
>>> creation, subscription, etc won't happen that frequently. So I don't think
>>> there will be much load on the broker as such.
>>>
>>> Architecturally having separate topics will be clean. The code and the
>>> error handling parameters (dead letter queue) can be defined per event
>>> type. However I think it'll cause additional burden to the Gateway since
>>> the Gateway now has to establish and maintain several connections to the
>>> broker. And since these connections need to happen at startup, each
>>> connection that needs to be established adds up to the startup time of the
>>> Gateway. So I would prefer to minimize the number of topics as much as
>>> possible.
>>>
>>> On Tue, Apr 25, 2017 at 11:09 AM, Thilini Shanika 
>>> wrote:
>>>
 Hi All,

 According to APIM C5 architecture, the events like API create, API
 lifecycle status change, API subscriptions are notified to APIM gateway via
 JMS topic/topics in the broker.

 Following diagram depicts how APIM core, broker and gateway components
 interact when there is an event generated from Core.


 Following are the two options we came up while implementing above event
 publishing scenario from APIM Core --> Broker --> Gateways.

 *1) Publishing all the events to a common topic *

 A single topic is maintained in broker and all the gateways are
 subscribed to this common topic. APIM core publishes all the events
 generated from APIM to this particular topic. After topic subscription, the
 gateways keep listening to the topic and once a notification is received,
 it has to be filtered to identify the event type and perform the required
 action. The events like API create, lifecycle status change, API
 subscription etc are getting published through this common topic and the
 event type has to be reflected in the notification itself so that the
 gateways can identify the notification and decide what has to be performed
 next. In this case, it has to maintain a single connection to JMS topic
 from each gateway.


 ​

 *2) Maintaining dedicated topics for each event type*

 In this option, we can either maintain dedicated topic for each event
 type (API Create, API publish, API subscription) or maintain dedicated
 topics for API publisher, API store events. As per this solution, the
 gateways have to subscribe to all these topics and keep listening to all of
 them. In that case, gateways have to establish and maintain more
 connections with the broker, since there are several topic subscriptions.
 Once a notification is generated from APIM and published to the relevant
 topic, that particular notification is received by the relevant gateway
 service and process the message to perform the next action. But, the
 filtering logic which has to be executed in ballerina gateway side is less
 complex in this solution.


 ​
 What would be the best option here? Your suggestions and comments are
 highly appreciated.

 Thanks
 Thilini



 --
 Thilini Shanika
 Senior Software Engineer
 WSO2, Inc.; http://wso2.com
 20, Palmgrove Avenue, Colombo 3

 E-mail: tgtshan...@gmail.com


>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <077%20777%205729>
>>>
>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <+94%2071%2

Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

[Manoj Gunawardena]

Are we going to use durable subscription here? When ever gw node down and
re start,
it should fetch messages which add to the topic during the down time.
In case durable subscription what is the mechanism to create client id for
each gw.Is that discussed and confirm?

On Tue, Apr 25, 2017 at 2:20 PM, Sanjeewa Malalgoda 
wrote:

> API create/update/delete are similar type of events IMO. After we getting
> any event for these what we have to do is redeploy API or discard it. IMO
> if possible we should try to avoid web service call based update and send
> ballerina file with event itself(if its not heavy object). Other type of
> event is subscription change(which originates from API store). And for the
> throttling we need another topic. So as i see we can survive with only 3
> topics at the moment.
>
> Thanks,
> sanjeewa.
>
> On Tue, Apr 25, 2017 at 11:44 AM, Nuwan Dias  wrote:
>
>> The type of events we're talking about here are rare events. API
>> creation, subscription, etc won't happen that frequently. So I don't think
>> there will be much load on the broker as such.
>>
>> Architecturally having separate topics will be clean. The code and the
>> error handling parameters (dead letter queue) can be defined per event
>> type. However I think it'll cause additional burden to the Gateway since
>> the Gateway now has to establish and maintain several connections to the
>> broker. And since these connections need to happen at startup, each
>> connection that needs to be established adds up to the startup time of the
>> Gateway. So I would prefer to minimize the number of topics as much as
>> possible.
>>
>> On Tue, Apr 25, 2017 at 11:09 AM, Thilini Shanika 
>> wrote:
>>
>>> Hi All,
>>>
>>> According to APIM C5 architecture, the events like API create, API
>>> lifecycle status change, API subscriptions are notified to APIM gateway via
>>> JMS topic/topics in the broker.
>>>
>>> Following diagram depicts how APIM core, broker and gateway components
>>> interact when there is an event generated from Core.
>>>
>>>
>>> Following are the two options we came up while implementing above event
>>> publishing scenario from APIM Core --> Broker --> Gateways.
>>>
>>> *1) Publishing all the events to a common topic *
>>>
>>> A single topic is maintained in broker and all the gateways are
>>> subscribed to this common topic. APIM core publishes all the events
>>> generated from APIM to this particular topic. After topic subscription, the
>>> gateways keep listening to the topic and once a notification is received,
>>> it has to be filtered to identify the event type and perform the required
>>> action. The events like API create, lifecycle status change, API
>>> subscription etc are getting published through this common topic and the
>>> event type has to be reflected in the notification itself so that the
>>> gateways can identify the notification and decide what has to be performed
>>> next. In this case, it has to maintain a single connection to JMS topic
>>> from each gateway.
>>>
>>>
>>> ​
>>>
>>> *2) Maintaining dedicated topics for each event type*
>>>
>>> In this option, we can either maintain dedicated topic for each event
>>> type (API Create, API publish, API subscription) or maintain dedicated
>>> topics for API publisher, API store events. As per this solution, the
>>> gateways have to subscribe to all these topics and keep listening to all of
>>> them. In that case, gateways have to establish and maintain more
>>> connections with the broker, since there are several topic subscriptions.
>>> Once a notification is generated from APIM and published to the relevant
>>> topic, that particular notification is received by the relevant gateway
>>> service and process the message to perform the next action. But, the
>>> filtering logic which has to be executed in ballerina gateway side is less
>>> complex in this solution.
>>>
>>>
>>> ​
>>> What would be the best option here? Your suggestions and comments are
>>> highly appreciated.
>>>
>>> Thanks
>>> Thilini
>>>
>>>
>>>
>>> --
>>> Thilini Shanika
>>> Senior Software Engineer
>>> WSO2, Inc.; http://wso2.com
>>> 20, Palmgrove Avenue, Colombo 3
>>>
>>> E-mail: tgtshan...@gmail.com
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <077%20777%205729>
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Manoj Gunawardena
Tech Lead
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
Mobile : +94 77 2291643
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-

Re: [Architecture] JMX access control : readOnly and readWrite access

[Asma Jabir]

Hi Isuru

Yes I have started working on it and after the initial discussion following
are the approaches that were planned to implement so far.

   - Using password and access files
   - Using custom authentication with CAAS [1] to replace the password file
   and using the access file for authorization

If you have any requirements please share so we can discuss and seek
possibilities to satisfy them.


[1] https://github.com/this/carbon-uuf/tree/master/samples/
osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundle/
src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle

Thank you

Regards,
Asma

On Tue, Apr 25, 2017 at 8:19 PM, Isuru Perera  wrote:

> Hi Asma,
>
> Did you start working on this?
>
> On Fri, Apr 7, 2017 at 6:07 PM, Asma Jabir  wrote:
>
>> Hi
>>
>> With regard to the $subject issue in the c5 repo [1], we could use
>> several ways to implement a role based access control.
>>
>> 1. Using the password and access files
>>
>>- This is the inbuilt mechanism in JMX for monitoring and management
>>which uses 2 properties based text files to restrict access to readOnly or
>>readWrite to users. The password file contains username/password pairs
>>which is used to authenticate and the access file contains
>>username/privilege pairs which authorizes with readOnly or readWrite
>>access.
>>- A user will get either the *control over all* processes *or* just *a
>>view of all* depending on the access level.
>>- SSL is enabled by default for remote monitoring and thus the SSL
>>should be configured properly after setting up a digital certificate.
>>System properties for keystore and truststore should be set in the server.
>>
>> 2. Using custom authorization
>>
>>- If the completely readOnly or readWrite approach is not
>>appropriate, a fine-grained authorization can be done using either of the
>>following in lieu of the access file:
>>
>> i. Java Policy file  - The file should be supplied as a system property
>> on server startup.
>>
>> ii. Custom authorization using a server-side code
>>
>>
>> 3. Using custom authentication
>>
>>- JMXAuthenticator [2] interface is based on JAAS login module. Thus,
>>a custom JAAS authentication can be used for authentication in lieu of the
>>password file.
>>- The access file or one of the methods stated in *2.* can be used
>>for authorization.
>>- The JAAS configurations should be loaded on server startup by
>>setting a system property.
>>
>> [1] https://github.com/wso2/carbon-kernel/issues/1247
>> [2] http://docs.oracle.com/javase/7/docs/api/javax/managemen
>> t/remote/JMXAuthenticator.html
>>
>> Thank you
>>
>> Regards,
>> Asma
>> --
>> Asma Zinneera Jabir
>> Software Engineer
>> WSO2 Inc: http://wso2.com/
>> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuru Perera
> Technical Lead | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> about.me/chrishantha
> Contact: +IsuruPereraWSO2 
>



-- 
Asma Zinneera Jabir
Software Engineer
WSO2 Inc: http://wso2.com/
Contact No: +94 77 332 4752 <+94%2077%20332%204752>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Harsha Thirimanna]

On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya  wrote:

>
>
> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
>>> wrote:
>>>

 On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
 wrote:

>
>
> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>>
>>> Hi Gayan,
>>>
>>> What are you trying to achieve by moving the client-secret
>>> validation logic to the interceptor from the jax-rs layer?
>>>
>>
>> ​Actually, we have separate layer to pass the secured API in IS and
>> it is common service that can be used for any product. AppManager also
>> using that.
>> In here also Gayan is trying to get the security check into that
>> common layer instead of allowing to go into the next level to validate
>> headers.  ​
>>
>
> Are we going to use common basic authentication handler  ?
>

 ​This feature is already done in IS 5.3.0 as a common point to handle
 authentication and authorization per resources as in [1].​

 [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
 ion-authorization-common.html

>
> BTW;  Client credentials can be received as url param..  Are we
> validating them in here ?  If it is not;  Why are we introducing two
> validation points for same ?
>
> ​If we have our own way to pass authentication details,​ then we have
 to write an authentication handler to that and register.

>>>
>>> This is according to the OAuth2 spec...  It meant that we need another
>>> handler implementation to do it or can we use existing authentication
>>> handler ?
>>>
>>
>> ​What i meant was that we can write custom handler as well to here. ​
>>
> Yes.  if it is;  it must be shipped by default.
>
​Gayan will do that with this implementation. ​

>
>
>>
>>
>>
>>>
>>>



> Actually I do not see much use of changing the current validation
> model.
>
 ​This is for all the APIs in IS to handle authentication/authorization
 in common way​ and decouple it with implementation of each.

>>>


>
> Thanks,
> Asela.
>
>
>>
>>
>>
>>> Since both run on the same JVM, doesn't the overhead of the process
>>> remain the same, irrespective of where it runs?
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>>> wrote:
>>>
 Hi All,

 In Oauth /token endpoint and /revoke endpoint

 https://localhost:9443/oauth2/token
 https://localhost:9443/oauth2/revoke

 required authorization with client key, client secret in basic auth
 headers. Currently in implementation we validate those headers after
 serving request to JAX-RS endpoints. Basically /token, /revoke 
 endpoints
 are unsecured. There is significant amount of processing happen even 
 for
 wrong client secret.

 Since we have REST API  interceptor layer In IS 5.3.0  can we use
 it to validate client credentials ? We may need to plug an additional
 authenticator to validate client key, client secret in basic auth 
 headers.
 This authenticator may conflict with basic authenticator because
 both authenticators validate basic auth credentials different way. 
 There
 are two approaches to avoid the conflict.

 *#option 01 *
 Increase the priority of newly added authenticator and check the
 context inside authenticator canHandle.

 *#option 01 *
 Increase the priority of newly added authenticator and check
 existence of oauth application from client key.

 WDYT?

 --
 Gayan Gunawardana
 Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Asela Pathberiya]

On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna  wrote:

>
>
> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
 wrote:

>
> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>
>> Hi Gayan,
>>
>> What are you trying to achieve by moving the client-secret validation
>> logic to the interceptor from the jax-rs layer?
>>
>
> ​Actually, we have separate layer to pass the secured API in IS and it
> is common service that can be used for any product. AppManager also using
> that.
> In here also Gayan is trying to get the security check into that
> common layer instead of allowing to go into the next level to validate
> headers.  ​
>

 Are we going to use common basic authentication handler  ?

>>>
>>> ​This feature is already done in IS 5.3.0 as a common point to handle
>>> authentication and authorization per resources as in [1].​
>>>
>>> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
>>> ion-authorization-common.html
>>>

 BTW;  Client credentials can be received as url param..  Are we
 validating them in here ?  If it is not;  Why are we introducing two
 validation points for same ?

 ​If we have our own way to pass authentication details,​ then we have
>>> to write an authentication handler to that and register.
>>>
>>
>> This is according to the OAuth2 spec...  It meant that we need another
>> handler implementation to do it or can we use existing authentication
>> handler ?
>>
>
> ​What i meant was that we can write custom handler as well to here. ​
>
Yes.  if it is;  it must be shipped by default.


>
>
>
>>
>>
>>>
>>>
>>>
 Actually I do not see much use of changing the current validation
 model.

>>> ​This is for all the APIs in IS to handle authentication/authorization
>>> in common way​ and decouple it with implementation of each.
>>>
>>
>>>
>>>

 Thanks,
 Asela.


>
>
>
>> Since both run on the same JVM, doesn't the overhead of the process
>> remain the same, irrespective of where it runs?
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> In Oauth /token endpoint and /revoke endpoint
>>>
>>> https://localhost:9443/oauth2/token
>>> https://localhost:9443/oauth2/revoke
>>>
>>> required authorization with client key, client secret in basic auth
>>> headers. Currently in implementation we validate those headers after
>>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>>> are unsecured. There is significant amount of processing happen even for
>>> wrong client secret.
>>>
>>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it
>>> to validate client credentials ? We may need to plug an additional
>>> authenticator to validate client key, client secret in basic auth 
>>> headers.
>>> This authenticator may conflict with basic authenticator because
>>> both authenticators validate basic auth credentials different way. There
>>> are two approaches to avoid the conflict.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check the
>>> context inside authenticator canHandle.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check
>>> existence of oauth application from client key.
>>>
>>> WDYT?
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Thanks & Regards,
 Asela

 ATL
 Mobile : +94 777 625 933 <+94%2077%20762%205933>
  +358 449 228 979

 http://soasecurity.org/
 http://xacmlinfo.org/

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>> _

Re: [Architecture] Access token for API testing in Publisher and Store

[Lakmali Baminiwatta]

Hi Jo,

On 21 April 2017 at 06:23, Joseph Fonseka  wrote:

> Hi Lakmali
>
> On Thu, Apr 20, 2017 at 11:51 PM, Lakmali Baminiwatta 
> wrote:
>
>> On 20 April 2017 at 19:19, Joseph Fonseka  wrote:
>>
>>>
>>> @Jo
>> Even though the API is designed to work with client credential, it
>> doesn't mean only the subscribed users can invoke it, right? Any user that
>> access the subscribed app will be able to invoke that API. My argument is,
>> the pattern used in test app is possible in any other normal apps as well.
>> I understand that this can be confusing and might be not easy to convince
>> for some users.
>>
>
> Your argument assumes that an app is shared/available to all the users. It
> can be true for some scenarios like mobile apps but if you look at
> instances like B2B ( system to system ) API invocations app will not be
> available for all the users or for any user to start with.
>

 yeah.. By default exposing an app with all API subscriptions can be a
problem then.

Thanks,
Lakmali

>
> Regards
> Jo
>
>
>
>>
>> However, when proceeding with the implementation we found further
>> problems which we couldn't find clean enough solutions.
>>
>>- Getting the admin apps credentials to the front end for swagger can
>>be vulnerable. Even if we go for implicit grant type, we have to figure 
>> out
>>how to compose the callback URLs.
>>- We can do per user app creation with automatic on demand
>>subscriptions (may be with an explicit button as Jo mentioned). If so, 
>> only
>>thing we achieve here compared to C4 is doing an automatic
>>subscription/token generation for a default app.
>>
>> So for now, we'll be integrating API Console only for editor and Store.
>> Since API doesn't have security applied in Editor mode, we don't have to
>> worry about token generation. For Store, we will keep the same behavior as
>> in C4 for now.
>>
>> Thanks,
>> Lakmali
>>
>>
>>> Regards
>>> Jo
>>>
>>>

 Thanks,
 Lakmali

 I guess to prevent that you have to use a per user or per API test app.
>
> Regards
> Jo
>
> On Thu, Apr 20, 2017 at 10:10 AM, Lakmali Baminiwatta <
> lakm...@wso2.com> wrote:
>
>> Hi Jo,
>>
>> On 20 April 2017 at 09:01, Joseph Fonseka  wrote:
>>
>>> Hi Lakmali
>>>
>>> Small thing, will the portal app subscription be automatic in the
>>> store ? if so can we make it explicit with a button on top of the 
>>> swagger
>>> console with the title  "Try API with swagger console" and bellow that 
>>> we
>>> can explain what actually happens.
>>>
>>
>> We are creating an app for the admin user here and therefore the
>> subscription happens for the admin user. Therefore IMO, that information 
>> is
>> not required for the store user.
>>
>>>
>>> Also how will the test app affects stats ? If we are not planing to
>>> hide it better to document that behavior.
>>>
>>
>> The admin user will have this test app. I believe its okay for admin
>> to have this test app shown may be with a special flag.
>>
>> In overall, we can explain the underlying process here when we
>> document the options users will have around this.
>>
>> Thanks,
>> Lakmali
>>
>>
>>> Thanks
>>> Jo
>>>
>>> On Thu, Apr 20, 2017 at 8:17 AM, Lakmali Baminiwatta <
>>> lakm...@wso2.com> wrote:
>>>
 Hi all,

 We had a discussion regarding this yesterday and please find the
 summarized points.


- "Testing APIs" is a required feature for Store and Editor
portals. Since we are not restricting API designing only to the 
 editor, but
allowed in publisher too, it is good to have "Testing APIs" feature 
 in
Publisher for a complete story.
- For editor, since the API is published to a local GW, it will
not have any security and therefore testing API will not require any
tokens/subscriptions etc.
- When the API is published from Publisher portal to the GW in
CREATED state for testing, we have to apply standard 
 security/throttling to
avoid security risks.
- As discussed in this thread as well, we will be using the
OAuth app created for the portals as the test app. However, for 
 supporting
prod and sandbox tokens, we have to register 2 apps.
- We can create the test apps when doing the DCR call.
- When retrieving the swagger definition of the API, we can
check the availability of subscriptions against the test apps and 
 add if
not available.
- Since swagger itself support OAuth, we can rely on it to
obtain a token. For that, we need to inject the test app's 
 credentials to
swagger UI and KM details needs to b

Re: [Architecture] JMX access control : readOnly and readWrite access

[Isuru Perera]

Hi Asma,

Did you start working on this?

On Fri, Apr 7, 2017 at 6:07 PM, Asma Jabir  wrote:

> Hi
>
> With regard to the $subject issue in the c5 repo [1], we could use several
> ways to implement a role based access control.
>
> 1. Using the password and access files
>
>- This is the inbuilt mechanism in JMX for monitoring and management
>which uses 2 properties based text files to restrict access to readOnly or
>readWrite to users. The password file contains username/password pairs
>which is used to authenticate and the access file contains
>username/privilege pairs which authorizes with readOnly or readWrite
>access.
>- A user will get either the *control over all* processes *or* just *a
>view of all* depending on the access level.
>- SSL is enabled by default for remote monitoring and thus the SSL
>should be configured properly after setting up a digital certificate.
>System properties for keystore and truststore should be set in the server.
>
> 2. Using custom authorization
>
>- If the completely readOnly or readWrite approach is not appropriate,
>a fine-grained authorization can be done using either of the following in
>lieu of the access file:
>
> i. Java Policy file  - The file should be supplied as a system property
> on server startup.
>
> ii. Custom authorization using a server-side code
>
>
> 3. Using custom authentication
>
>- JMXAuthenticator [2] interface is based on JAAS login module. Thus,
>a custom JAAS authentication can be used for authentication in lieu of the
>password file.
>- The access file or one of the methods stated in *2.* can be used for
>authorization.
>- The JAAS configurations should be loaded on server startup by
>setting a system property.
>
> [1] https://github.com/wso2/carbon-kernel/issues/1247
> [2] http://docs.oracle.com/javase/7/docs/api/javax/managemen
> t/remote/JMXAuthenticator.html
>
> Thank you
>
> Regards,
> Asma
> --
> Asma Zinneera Jabir
> Software Engineer
> WSO2 Inc: http://wso2.com/
> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Isuru Perera
Technical Lead | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

about.me/chrishantha
Contact: +IsuruPereraWSO2 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Harsha Thirimanna]

On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya  wrote:

>
>
> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
>>> wrote:
>>>

 On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:

> Hi Gayan,
>
> What are you trying to achieve by moving the client-secret validation
> logic to the interceptor from the jax-rs layer?
>

 ​Actually, we have separate layer to pass the secured API in IS and it
 is common service that can be used for any product. AppManager also using
 that.
 In here also Gayan is trying to get the security check into that common
 layer instead of allowing to go into the next level to validate headers.  ​

>>>
>>> Are we going to use common basic authentication handler  ?
>>>
>>
>> ​This feature is already done in IS 5.3.0 as a common point to handle
>> authentication and authorization per resources as in [1].​
>>
>> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
>> ion-authorization-common.html
>>
>>>
>>> BTW;  Client credentials can be received as url param..  Are we
>>> validating them in here ?  If it is not;  Why are we introducing two
>>> validation points for same ?
>>>
>>> ​If we have our own way to pass authentication details,​ then we have to
>> write an authentication handler to that and register.
>>
>
> This is according to the OAuth2 spec...  It meant that we need another
> handler implementation to do it or can we use existing authentication
> handler ?
>

​What i meant was that we can write custom handler as well to here. ​



>
>
>>
>>
>>
>>> Actually I do not see much use of changing the current validation model.
>>>
>>>
>> ​This is for all the APIs in IS to handle authentication/authorization in
>> common way​ and decouple it with implementation of each.
>>
>
>>
>>
>>>
>>> Thanks,
>>> Asela.
>>>
>>>



> Since both run on the same JVM, doesn't the overhead of the process
> remain the same, irrespective of where it runs?
>
> Thanks,
> NuwanD.
>
> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
> wrote:
>
>> Hi All,
>>
>> In Oauth /token endpoint and /revoke endpoint
>>
>> https://localhost:9443/oauth2/token
>> https://localhost:9443/oauth2/revoke
>>
>> required authorization with client key, client secret in basic auth
>> headers. Currently in implementation we validate those headers after
>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>> are unsecured. There is significant amount of processing happen even for
>> wrong client secret.
>>
>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it
>> to validate client credentials ? We may need to plug an additional
>> authenticator to validate client key, client secret in basic auth 
>> headers.
>> This authenticator may conflict with basic authenticator because both
>> authenticators validate basic auth credentials different way. There are 
>> two
>> approaches to avoid the conflict.
>>
>> *#option 01 *
>> Increase the priority of newly added authenticator and check the
>> context inside authenticator canHandle.
>>
>> *#option 01 *
>> Increase the priority of newly added authenticator and check
>> existence of oauth application from client key.
>>
>> WDYT?
>>
>> --
>> Gayan Gunawardana
>> Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>


 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>>  +358 449 228 979
>>>
>>> http://soasecurity.org/
>>> http://xacmlinfo.org/
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Asela Pathberiya]

On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna  wrote:

>
> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>>>
 Hi Gayan,

 What are you trying to achieve by moving the client-secret validation
 logic to the interceptor from the jax-rs layer?

>>>
>>> ​Actually, we have separate layer to pass the secured API in IS and it
>>> is common service that can be used for any product. AppManager also using
>>> that.
>>> In here also Gayan is trying to get the security check into that common
>>> layer instead of allowing to go into the next level to validate headers.  ​
>>>
>>
>> Are we going to use common basic authentication handler  ?
>>
>
> ​This feature is already done in IS 5.3.0 as a common point to handle
> authentication and authorization per resources as in [1].​
>
> [1] http://harshathirimanna.blogspot.com/2016/11/
> authentication-authorization-common.html
>
>>
>> BTW;  Client credentials can be received as url param..  Are we
>> validating them in here ?  If it is not;  Why are we introducing two
>> validation points for same ?
>>
>> ​If we have our own way to pass authentication details,​ then we have to
> write an authentication handler to that and register.
>

This is according to the OAuth2 spec...  It meant that we need another
handler implementation to do it or can we use existing authentication
handler ?


>
>
>
>> Actually I do not see much use of changing the current validation model.
>>
> ​This is for all the APIs in IS to handle authentication/authorization in
> common way​ and decouple it with implementation of each.
>

>
>
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>>
>>>
 Since both run on the same JVM, doesn't the overhead of the process
 remain the same, irrespective of where it runs?

 Thanks,
 NuwanD.

 On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
 wrote:

> Hi All,
>
> In Oauth /token endpoint and /revoke endpoint
>
> https://localhost:9443/oauth2/token
> https://localhost:9443/oauth2/revoke
>
> required authorization with client key, client secret in basic auth
> headers. Currently in implementation we validate those headers after
> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
> are unsecured. There is significant amount of processing happen even for
> wrong client secret.
>
> Since we have REST API  interceptor layer In IS 5.3.0  can we use it
> to validate client credentials ? We may need to plug an additional
> authenticator to validate client key, client secret in basic auth headers.
> This authenticator may conflict with basic authenticator because both
> authenticators validate basic auth credentials different way. There are 
> two
> approaches to avoid the conflict.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check the
> context inside authenticator canHandle.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check existence
> of oauth application from client key.
>
> WDYT?
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Nuwan Dias

 Software Architect - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729 <+94%2077%20777%205729>

>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

http://soasecurity.org/
http://xacmlinfo.org/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Harsha Thirimanna]

On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya  wrote:

>
>
> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>>
>>> Hi Gayan,
>>>
>>> What are you trying to achieve by moving the client-secret validation
>>> logic to the interceptor from the jax-rs layer?
>>>
>>
>> ​Actually, we have separate layer to pass the secured API in IS and it is
>> common service that can be used for any product. AppManager also using
>> that.
>> In here also Gayan is trying to get the security check into that common
>> layer instead of allowing to go into the next level to validate headers.  ​
>>
>
> Are we going to use common basic authentication handler  ?
>

​This feature is already done in IS 5.3.0 as a common point to handle
authentication and authorization per resources as in [1].​

[1]
http://harshathirimanna.blogspot.com/2016/11/authentication-authorization-common.html

>
> BTW;  Client credentials can be received as url param..  Are we validating
> them in here ?  If it is not;  Why are we introducing two validation points
> for same ?
>
> ​If we have our own way to pass authentication details,​ then we have to
write an authentication handler to that and register.



> Actually I do not see much use of changing the current validation model.
>
​This is for all the APIs in IS to handle authentication/authorization in
common way​ and decouple it with implementation of each.



>
> Thanks,
> Asela.
>
>
>>
>>
>>
>>> Since both run on the same JVM, doesn't the overhead of the process
>>> remain the same, irrespective of where it runs?
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>>> wrote:
>>>
 Hi All,

 In Oauth /token endpoint and /revoke endpoint

 https://localhost:9443/oauth2/token
 https://localhost:9443/oauth2/revoke

 required authorization with client key, client secret in basic auth
 headers. Currently in implementation we validate those headers after
 serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
 are unsecured. There is significant amount of processing happen even for
 wrong client secret.

 Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
 validate client credentials ? We may need to plug an additional
 authenticator to validate client key, client secret in basic auth headers.
 This authenticator may conflict with basic authenticator because both
 authenticators validate basic auth credentials different way. There are two
 approaches to avoid the conflict.

 *#option 01 *
 Increase the priority of newly added authenticator and check the
 context inside authenticator canHandle.

 *#option 01 *
 Increase the priority of newly added authenticator and check existence
 of oauth application from client key.

 WDYT?

 --
 Gayan Gunawardana
 Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

[Sanjeewa Malalgoda]

API create/update/delete are similar type of events IMO. After we getting
any event for these what we have to do is redeploy API or discard it. IMO
if possible we should try to avoid web service call based update and send
ballerina file with event itself(if its not heavy object). Other type of
event is subscription change(which originates from API store). And for the
throttling we need another topic. So as i see we can survive with only 3
topics at the moment.

Thanks,
sanjeewa.

On Tue, Apr 25, 2017 at 11:44 AM, Nuwan Dias  wrote:

> The type of events we're talking about here are rare events. API creation,
> subscription, etc won't happen that frequently. So I don't think there will
> be much load on the broker as such.
>
> Architecturally having separate topics will be clean. The code and the
> error handling parameters (dead letter queue) can be defined per event
> type. However I think it'll cause additional burden to the Gateway since
> the Gateway now has to establish and maintain several connections to the
> broker. And since these connections need to happen at startup, each
> connection that needs to be established adds up to the startup time of the
> Gateway. So I would prefer to minimize the number of topics as much as
> possible.
>
> On Tue, Apr 25, 2017 at 11:09 AM, Thilini Shanika 
> wrote:
>
>> Hi All,
>>
>> According to APIM C5 architecture, the events like API create, API
>> lifecycle status change, API subscriptions are notified to APIM gateway via
>> JMS topic/topics in the broker.
>>
>> Following diagram depicts how APIM core, broker and gateway components
>> interact when there is an event generated from Core.
>>
>>
>> Following are the two options we came up while implementing above event
>> publishing scenario from APIM Core --> Broker --> Gateways.
>>
>> *1) Publishing all the events to a common topic *
>>
>> A single topic is maintained in broker and all the gateways are
>> subscribed to this common topic. APIM core publishes all the events
>> generated from APIM to this particular topic. After topic subscription, the
>> gateways keep listening to the topic and once a notification is received,
>> it has to be filtered to identify the event type and perform the required
>> action. The events like API create, lifecycle status change, API
>> subscription etc are getting published through this common topic and the
>> event type has to be reflected in the notification itself so that the
>> gateways can identify the notification and decide what has to be performed
>> next. In this case, it has to maintain a single connection to JMS topic
>> from each gateway.
>>
>>
>> ​
>>
>> *2) Maintaining dedicated topics for each event type*
>>
>> In this option, we can either maintain dedicated topic for each event
>> type (API Create, API publish, API subscription) or maintain dedicated
>> topics for API publisher, API store events. As per this solution, the
>> gateways have to subscribe to all these topics and keep listening to all of
>> them. In that case, gateways have to establish and maintain more
>> connections with the broker, since there are several topic subscriptions.
>> Once a notification is generated from APIM and published to the relevant
>> topic, that particular notification is received by the relevant gateway
>> service and process the message to perform the next action. But, the
>> filtering logic which has to be executed in ballerina gateway side is less
>> complex in this solution.
>>
>>
>> ​
>> What would be the best option here? Your suggestions and comments are
>> highly appreciated.
>>
>> Thanks
>> Thilini
>>
>>
>>
>> --
>> Thilini Shanika
>> Senior Software Engineer
>> WSO2, Inc.; http://wso2.com
>> 20, Palmgrove Avenue, Colombo 3
>>
>> E-mail: tgtshan...@gmail.com
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <077%20777%205729>
>



-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] [APIM] Frnot End scope validation

[Asela Pathberiya]

On Tue, Apr 25, 2017 at 1:11 PM, Ishara Karunarathna 
wrote:

> HI,
>
> On Tue, Apr 25, 2017 at 11:21 AM, Nuwan Dias  wrote:
>
>> Yes, maintaining the mappings is not an issue AFAIS. The API definition
>> (Swagger) itself has the scope associated with each resource. So we just
>> need a way of storing the role(s) against each scope. By default the
>> product will have like say <10 scopes. So what we're looking at is a config
>> with the following format.
>>
>> {
>> "scopes": [{
>> "key": "apim:add_api",
>> "roles": ["creator", "admin"]
>> },
>> {
>> "key": "apim:add_application",
>> "roles": ["subscriber", "admin"]
>> }
>> ]
>> }
>>
>> The above config is only required by the server, to issue the token. What
>> the client (Browser) needs to render the buttons and links are the scopes
>> associated with the token and the API definition (Swagger).
>>
> If we are only using scops  and Roles, and if we are not going for
> finegrain level such as attribute base restriction on this APIs I think its
> ok to go with simple implementation.
> Which will be easy to implement and anyone  users will easily understand
> stuff.
>

+1

I just want to know about how we are defining the policies whether it is
based on standard approach such as XACML.  Yes.  we need to use scope at
protocol level & it is totally fine.

If policies are simple as just have some kind of mapping on role-scope..
 yes we can use it within API definition & do not want to make it more
complex.

But; it is always better; if we can have some externalizing point (some
kind of authorization handler/validator) in to the implementation which may
help to plug any authorization server/endpoint.

Thanks,
Asela.


>
>
> -Ishara
>
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 10:10 AM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 9:43 AM, Nuwan Dias  wrote:
>>>
 What's wrong with using OAuth2.0 scopes? The authorization requirements
 are simply to define which role/group is permitted to access a given
 resource. Which is very simply supported OOTB via scopes and the
 configuration is very simple as well.

 One of the key design principles here is to keep things simple. Because
 this is something almost all users of the product will be
 configuring/tweaking when setting up a deployment for real. I don't think
 everyone understands XACML. Besides, we do not need the extensive feature
 set offered by XACML for this particular API.

 Another key design principle here is to make the API generic so that
 anyone can easily write a UI using it. OAuth2.0 is the de facto security
 standard for REST APIs and anyone using a REST API understands it (now). So
 why move away from the standard? When developing an SPA type UI app, it is
 extremely easy to render (or not) buttons/links when the resource is
 protected via scopes. XACML makes that tougher. Actually I personally
 haven't figured out how to render the html on the client side unless I
 evaluate the XACML policy on the client side, which of course is nearly
 impossible I guess.

 ​Our concern was not to say any wrong about the OAuth2 scopes. Only
>>> concern was we can use XACML for such a fine grained cases by getting its
>>> extensibility as well.​ Now we have JSON based RestAPI for XACML within IS
>>> as well.
>>> Yes I agree that OAuth 2 story is bit simple rather than using XACML.
>>> But anyway, you guys have to maintain the mapping somehow and as you said,
>>> it is also not such complicated to that.
>>>
>>>
>>>
 Thanks,
 NuwanD.

 On Tue, Apr 25, 2017 at 8:55 AM, Harsha Thirimanna 
 wrote:

>
>
> On 21 Apr 2017 5:27 p.m., "Asela Pathberiya"  wrote:
>
>
>
> On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray 
> wrote:
>
>> Hi Asela,
>>
>> What is reason for using scopes for authorization.. ?  Can't we use
>> policy based approach such as XACML ?
>>
>> Default authentication and authorization protocol we use is oauth,
>> hence we already have support for scopes in our REST APIs.
>> Therefore is it straight forward to use scopes as we just need to
>> validate UI components and it is not required to add the complexities we
>> can have from XACML.
>>
>
> What is the standard which defines the policies..  In scopes also;
>  you need to store the authorization mapping in some where.. isn't it ?
> Can't we use XACML policies for that ?
>
>>
> I also believe this is real use case of having XACML. Maintainability
> wise also XACML may be easy. I don't think it will give additional
> complexity ,because as Asela said anyway you must have this association in
> somewhere.
> Performance wise also XACML is good because of its caching layers in
> different level.
>
>
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Asela Pathberiya]

On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
wrote:

>
> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>
>> Hi Gayan,
>>
>> What are you trying to achieve by moving the client-secret validation
>> logic to the interceptor from the jax-rs layer?
>>
>
> ​Actually, we have separate layer to pass the secured API in IS and it is
> common service that can be used for any product. AppManager also using
> that.
> In here also Gayan is trying to get the security check into that common
> layer instead of allowing to go into the next level to validate headers.  ​
>

Are we going to use common basic authentication handler  ?

BTW;  Client credentials can be received as url param..  Are we validating
them in here ?  If it is not;  Why are we introducing two validation points
for same ?

Actually I do not see much use of changing the current validation model.

Thanks,
Asela.


>
>
>
>> Since both run on the same JVM, doesn't the overhead of the process
>> remain the same, irrespective of where it runs?
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> In Oauth /token endpoint and /revoke endpoint
>>>
>>> https://localhost:9443/oauth2/token
>>> https://localhost:9443/oauth2/revoke
>>>
>>> required authorization with client key, client secret in basic auth
>>> headers. Currently in implementation we validate those headers after
>>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>>> are unsecured. There is significant amount of processing happen even for
>>> wrong client secret.
>>>
>>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
>>> validate client credentials ? We may need to plug an additional
>>> authenticator to validate client key, client secret in basic auth headers.
>>> This authenticator may conflict with basic authenticator because both
>>> authenticators validate basic auth credentials different way. There are two
>>> approaches to avoid the conflict.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check the context
>>> inside authenticator canHandle.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check existence
>>> of oauth application from client key.
>>>
>>> WDYT?
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

http://soasecurity.org/
http://xacmlinfo.org/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

[Harsha Kumara]

Yes it's better to minimize the number of topics. We can have single topic
for life cycle changes with message type indicating state change. Using two
topics for API Publisher and Store events should be fine.

On Tue, Apr 25, 2017 at 11:44 AM, Nuwan Dias  wrote:

> The type of events we're talking about here are rare events. API creation,
> subscription, etc won't happen that frequently. So I don't think there will
> be much load on the broker as such.
>
> Architecturally having separate topics will be clean. The code and the
> error handling parameters (dead letter queue) can be defined per event
> type. However I think it'll cause additional burden to the Gateway since
> the Gateway now has to establish and maintain several connections to the
> broker. And since these connections need to happen at startup, each
> connection that needs to be established adds up to the startup time of the
> Gateway. So I would prefer to minimize the number of topics as much as
> possible.
>
> On Tue, Apr 25, 2017 at 11:09 AM, Thilini Shanika 
> wrote:
>
>> Hi All,
>>
>> According to APIM C5 architecture, the events like API create, API
>> lifecycle status change, API subscriptions are notified to APIM gateway via
>> JMS topic/topics in the broker.
>>
>> Following diagram depicts how APIM core, broker and gateway components
>> interact when there is an event generated from Core.
>>
>>
>> Following are the two options we came up while implementing above event
>> publishing scenario from APIM Core --> Broker --> Gateways.
>>
>> *1) Publishing all the events to a common topic *
>>
>> A single topic is maintained in broker and all the gateways are
>> subscribed to this common topic. APIM core publishes all the events
>> generated from APIM to this particular topic. After topic subscription, the
>> gateways keep listening to the topic and once a notification is received,
>> it has to be filtered to identify the event type and perform the required
>> action. The events like API create, lifecycle status change, API
>> subscription etc are getting published through this common topic and the
>> event type has to be reflected in the notification itself so that the
>> gateways can identify the notification and decide what has to be performed
>> next. In this case, it has to maintain a single connection to JMS topic
>> from each gateway.
>>
>>
>> ​
>>
>> *2) Maintaining dedicated topics for each event type*
>>
>> In this option, we can either maintain dedicated topic for each event
>> type (API Create, API publish, API subscription) or maintain dedicated
>> topics for API publisher, API store events. As per this solution, the
>> gateways have to subscribe to all these topics and keep listening to all of
>> them. In that case, gateways have to establish and maintain more
>> connections with the broker, since there are several topic subscriptions.
>> Once a notification is generated from APIM and published to the relevant
>> topic, that particular notification is received by the relevant gateway
>> service and process the message to perform the next action. But, the
>> filtering logic which has to be executed in ballerina gateway side is less
>> complex in this solution.
>>
>>
>> ​
>> What would be the best option here? Your suggestions and comments are
>> highly appreciated.
>>
>> Thanks
>> Thilini
>>
>>
>>
>> --
>> Thilini Shanika
>> Senior Software Engineer
>> WSO2, Inc.; http://wso2.com
>> 20, Palmgrove Avenue, Colombo 3
>>
>> E-mail: tgtshan...@gmail.com
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>



-- 
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Nuwan Dias]

Ok got it. So you're not trying to gain anything in terms of performance
but you get to reuse the existing code which validates the auth header.

On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna 
wrote:

>
> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:
>
>> Hi Gayan,
>>
>> What are you trying to achieve by moving the client-secret validation
>> logic to the interceptor from the jax-rs layer?
>>
>
> ​Actually, we have separate layer to pass the secured API in IS and it is
> common service that can be used for any product. AppManager also using
> that.
> In here also Gayan is trying to get the security check into that common
> layer instead of allowing to go into the next level to validate headers.  ​
>
>
>
>> Since both run on the same JVM, doesn't the overhead of the process
>> remain the same, irrespective of where it runs?
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> In Oauth /token endpoint and /revoke endpoint
>>>
>>> https://localhost:9443/oauth2/token
>>> https://localhost:9443/oauth2/revoke
>>>
>>> required authorization with client key, client secret in basic auth
>>> headers. Currently in implementation we validate those headers after
>>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>>> are unsecured. There is significant amount of processing happen even for
>>> wrong client secret.
>>>
>>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
>>> validate client credentials ? We may need to plug an additional
>>> authenticator to validate client key, client secret in basic auth headers.
>>> This authenticator may conflict with basic authenticator because both
>>> authenticators validate basic auth credentials different way. There are two
>>> approaches to avoid the conflict.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check the context
>>> inside authenticator canHandle.
>>>
>>> *#option 01 *
>>> Increase the priority of newly added authenticator and check existence
>>> of oauth application from client key.
>>>
>>> WDYT?
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>


-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] [APIM] Frnot End scope validation

[Ishara Karunarathna]

HI,

On Tue, Apr 25, 2017 at 11:21 AM, Nuwan Dias  wrote:

> Yes, maintaining the mappings is not an issue AFAIS. The API definition
> (Swagger) itself has the scope associated with each resource. So we just
> need a way of storing the role(s) against each scope. By default the
> product will have like say <10 scopes. So what we're looking at is a config
> with the following format.
>
> {
> "scopes": [{
> "key": "apim:add_api",
> "roles": ["creator", "admin"]
> },
> {
> "key": "apim:add_application",
> "roles": ["subscriber", "admin"]
> }
> ]
> }
>
> The above config is only required by the server, to issue the token. What
> the client (Browser) needs to render the buttons and links are the scopes
> associated with the token and the API definition (Swagger).
>
If we are only using scops  and Roles, and if we are not going for
finegrain level such as attribute base restriction on this APIs I think its
ok to go with simple implementation.
Which will be easy to implement and anyone  users will easily understand
stuff.

-Ishara

>
> Thanks,
> NuwanD.
>
> On Tue, Apr 25, 2017 at 10:10 AM, Harsha Thirimanna 
> wrote:
>
>>
>> On Tue, Apr 25, 2017 at 9:43 AM, Nuwan Dias  wrote:
>>
>>> What's wrong with using OAuth2.0 scopes? The authorization requirements
>>> are simply to define which role/group is permitted to access a given
>>> resource. Which is very simply supported OOTB via scopes and the
>>> configuration is very simple as well.
>>>
>>> One of the key design principles here is to keep things simple. Because
>>> this is something almost all users of the product will be
>>> configuring/tweaking when setting up a deployment for real. I don't think
>>> everyone understands XACML. Besides, we do not need the extensive feature
>>> set offered by XACML for this particular API.
>>>
>>> Another key design principle here is to make the API generic so that
>>> anyone can easily write a UI using it. OAuth2.0 is the de facto security
>>> standard for REST APIs and anyone using a REST API understands it (now). So
>>> why move away from the standard? When developing an SPA type UI app, it is
>>> extremely easy to render (or not) buttons/links when the resource is
>>> protected via scopes. XACML makes that tougher. Actually I personally
>>> haven't figured out how to render the html on the client side unless I
>>> evaluate the XACML policy on the client side, which of course is nearly
>>> impossible I guess.
>>>
>>> ​Our concern was not to say any wrong about the OAuth2 scopes. Only
>> concern was we can use XACML for such a fine grained cases by getting its
>> extensibility as well.​ Now we have JSON based RestAPI for XACML within IS
>> as well.
>> Yes I agree that OAuth 2 story is bit simple rather than using XACML. But
>> anyway, you guys have to maintain the mapping somehow and as you said, it
>> is also not such complicated to that.
>>
>>
>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Apr 25, 2017 at 8:55 AM, Harsha Thirimanna 
>>> wrote:
>>>


 On 21 Apr 2017 5:27 p.m., "Asela Pathberiya"  wrote:



 On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray 
 wrote:

> Hi Asela,
>
> What is reason for using scopes for authorization.. ?  Can't we use
> policy based approach such as XACML ?
>
> Default authentication and authorization protocol we use is oauth,
> hence we already have support for scopes in our REST APIs.
> Therefore is it straight forward to use scopes as we just need to
> validate UI components and it is not required to add the complexities we
> can have from XACML.
>

 What is the standard which defines the policies..  In scopes also;  you
 need to store the authorization mapping in some where.. isn't it ?  Can't
 we use XACML policies for that ?

>
 I also believe this is real use case of having XACML. Maintainability
 wise also XACML may be easy. I don't think it will give additional
 complexity ,because as Asela said anyway you must have this association in
 somewhere.
 Performance wise also XACML is good because of its caching layers in
 different level.


>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Thu, Apr 20, 2017 at 6:22 PM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> Hi Ishara,
>>
>> Please see my comments inline.
>>
>> On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray 
>> wrote:
>>
>>> Hi,
>>>
>>> Previous versions(Before C5) of APIM Publisher, Store Apps front end
>>> validations were done based on user roles.
>>>
>>> But with C5 we think of fine graining User Interfaces by controlling
>>> access to UI components such as Add, Edit, Delete buttons/links based on
>>> the user scopes.
>>>
>>> 1. We need to fin

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Harsha Thirimanna]

On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias  wrote:

> Hi Gayan,
>
> What are you trying to achieve by moving the client-secret validation
> logic to the interceptor from the jax-rs layer?
>

​Actually, we have separate layer to pass the secured API in IS and it is
common service that can be used for any product. AppManager also using
that.
In here also Gayan is trying to get the security check into that common
layer instead of allowing to go into the next level to validate headers.  ​



> Since both run on the same JVM, doesn't the overhead of the process remain
> the same, irrespective of where it runs?
>
> Thanks,
> NuwanD.
>
> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana 
> wrote:
>
>> Hi All,
>>
>> In Oauth /token endpoint and /revoke endpoint
>>
>> https://localhost:9443/oauth2/token
>> https://localhost:9443/oauth2/revoke
>>
>> required authorization with client key, client secret in basic auth
>> headers. Currently in implementation we validate those headers after
>> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
>> are unsecured. There is significant amount of processing happen even for
>> wrong client secret.
>>
>> Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
>> validate client credentials ? We may need to plug an additional
>> authenticator to validate client key, client secret in basic auth headers.
>> This authenticator may conflict with basic authenticator because both
>> authenticators validate basic auth credentials different way. There are two
>> approaches to avoid the conflict.
>>
>> *#option 01 *
>> Increase the priority of newly added authenticator and check the context
>> inside authenticator canHandle.
>>
>> *#option 01 *
>> Increase the priority of newly added authenticator and check existence of
>> oauth application from client key.
>>
>> WDYT?
>>
>> --
>> Gayan Gunawardana
>> Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Nuwan Dias]

Hi Gayan,

What are you trying to achieve by moving the client-secret validation logic
to the interceptor from the jax-rs layer? Since both run on the same JVM,
doesn't the overhead of the process remain the same, irrespective of where
it runs?

Thanks,
NuwanD.

On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana  wrote:

> Hi All,
>
> In Oauth /token endpoint and /revoke endpoint
>
> https://localhost:9443/oauth2/token
> https://localhost:9443/oauth2/revoke
>
> required authorization with client key, client secret in basic auth
> headers. Currently in implementation we validate those headers after
> serving request to JAX-RS endpoints. Basically /token, /revoke endpoints
> are unsecured. There is significant amount of processing happen even for
> wrong client secret.
>
> Since we have REST API  interceptor layer In IS 5.3.0  can we use it to
> validate client credentials ? We may need to plug an additional
> authenticator to validate client key, client secret in basic auth headers.
> This authenticator may conflict with basic authenticator because both
> authenticators validate basic auth credentials different way. There are two
> approaches to avoid the conflict.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check the context
> inside authenticator canHandle.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check existence of
> oauth application from client key.
>
> WDYT?
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture