Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller

[Nuwan Dias]

aviour is expected as well.
>
>
> New Requirements  and Features to Eliminate the Limitations
>
> As discussed above, the user should be able to import an API with a
> particular throttling policy only if that particular policy is already
> imported to that environment/instance. To facilitate this requirement, new
> commands should be introduced to export/import throttling policies, prior
> to export/import APIs. These commands can be in the below form.
>
> Command 1
>
> Command
>
> apictl export throttling-policy [flags]
>
> Examples
>
> apictl export throttling-policy -n MyThrottlingPolicy -t advanced -e
> environment
>
> Flags
>
> Mandatory
>
> -n, --name string  Name of the Throttling
> Policy to be exported
>
> -t, --type string Type of the Throttling
> Policy (Can be advanced, application, subscription)
>
>-e, --environment string   Environment to the which the
> Throttling Policy should be imported
>
> Optional
>
> --format string  File format of
> exported file (default "YAML")
>
> Command 2
>
> Command
>
> apictl import throttling-policy [flags]
>
> Example
>
> apictl import throttling-policy -f /home/wasura/mypolicy.yaml -t advanced
> -e environment
>
> Flags
>
> Mandatory
>
> -f, --file string  Name/Path of the
> Throttling Policy to be imported
>
> -t, --type string Type of the Throttling
> Policy (Can be advanced, application, subscription)
>
>-e, --environment string   Environment from which the
> Throttling Policy should be exported
>
> Optional
>
>   --update   Update an existing
> Throttling Policy or create a new Throttling Policy
>
> REST API Requirements
>
> To implement the above commands in the API Controller side, REST APIs
> related to the throttling policies are needed. IMO, we can use the existing
> REST APIs as explained below.
>
> To retrieve the throttling policy, the API Controller side can call either
> of the below three (3) REST API resources in Admin V1 REST API according to
> the type specified by -t (--type). Then, we can print it to a YAML/JSON
> file and export/save it from the API Controller itself.
>
>
>1.
>
>To export Advanced Throttling Policies - GET
>/throttling/policies/advanced
>2.
>
>To export  Application-level Throttling Tiers/Policies - GET
>/throttling/policies/application
>3.
>
>To export  Subscription-level Throttling Tiers/Policies - GET
>/throttling/policies/subscription
>
>
> To import the throttling policy, the API Controller side can call either
> of the below three (3) REST API resources in Admin V1 REST API according to
> the type specified by -t (--type).
>
>
>1.
>
>To import Advanced Throttling Policies - POST
>/throttling/policies/advanced
>
> (PUT /throttling/policies/advanced/{policyId} when the --update flag is
> specified)
>
>1.
>
>To import  Application-level Throttling Tiers/Policies - POST
>/throttling/policies/application
>
> (PUT /throttling/policies/application/{policyId} when the --update flag is
> specified)
>
>1.
>
>To import  Subscription-level Throttling Tiers/Policies - POST
>/throttling/policies/subscription
>
> (PUT /throttling/policies/subscription/{policyId} when the --update flag
> is specified)
>
> Your feedback on the above-stated feature will be much appreciated before
> starting the implementation.
>
> [1] https://github.com/wso2/product-apim-tooling/issues/329
>
> Thank you!
> --
> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
> (m) +94775396038 | (e) was...@wso2.com | (b) Medium
> <https://medium.com/@wasuradananjith>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
>
>

-- 
*Nuwan Dias* | VP and deputy CTO - API Management and Integration | WSO2
Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using advertiseOnly property to recognize AWS APIs

[Nuwan Dias]

So for existing users of this feature, the only reason this change can
backfire is when they have an invalid URL on the OpenAPI doc right? Because
when publishing an API to an external portal, the OpenAPI of that API would
be expected to contain the proper URL of the API. So in the event this
change starts displaying an invalid URL on the external store, I think the
right thing to do is to fix the OpenAPI doc on that API on the external
store.

On Mon, Nov 2, 2020 at 5:08 PM Malintha Amarasinghe 
wrote:

>
>
> On Mon, Nov 2, 2020 at 4:03 PM Malintha Amarasinghe 
> wrote:
>
>> When an API is published to an external store, we are doing an export
>> (zip) of the API from the current APIM and import it to the external store
>> [1]. Before doing so, the exported zip is modified and adding *advertiseOnly:
>> true* is also part of it [2].
>> When we are showing backend URLs from swagger, we might also have to
>> modify the swagger before pushing to the external store so that it will
>> reflect original API's GW to avoid it showing the original endpoints coming
>> from the swagger. WDYT?
>>
>
> Above is just to make sure our change to show GW urls doesn't negatively
> affect external store features as there are customers already using it. I
> am also thinking that showing the GW urls when advertiseOnly is true is the
> way to go.
>
> Thanks!
>
>
>>
>> [1]
>> https://github.com/wso2/carbon-apimgt/blob/462e4ec1279931e92f9d78cdcc5abb2a401cd3f5/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/publishers/WSO2APIPublisher.java#L101-L104
>> [2]
>> https://github.com/wso2/carbon-apimgt/blob/462e4ec1279931e92f9d78cdcc5abb2a401cd3f5/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/publishers/WSO2APIPublisher.java#L142
>>
>> On Mon, Nov 2, 2020 at 3:19 PM Nuwan Dias  wrote:
>>
>>> I think it's fine to display the host (servers) URL on the OpenAPI on
>>> the developer portal in case the advertiseOnly attribute is true. In case
>>> the host (servers) section on the OpenAPI is null/empty, we can default to
>>> the old behavior which is to not display anything.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Thu, Oct 29, 2020 at 2:57 PM Akshitha Dalpethado (Intern) <
>>> akshi...@wso2.com> wrote:
>>>
>>>> Hi guys,
>>>> I'm working on the project, harvesting APIs from AWS API gateway to the
>>>> WSO2 developer portal. As you guys know we have created a new apictl
>>>> command for this(apictl aws init).
>>>> We have decided to use the *advertiseOnly* property to recognize these
>>>> APIs when we import them to the developers portal and display the API's
>>>> host URL as the gateway URL. For instance instead of the gateway URL
>>>> generated by the developer portal this will be the URL displayed as the
>>>> gateway URL.
>>>> ern7ceaofh.execute-api.us-east-1.amazonaws.com
>>>>
>>>> But the problem we are having is *advertiseOnly* API gateway URLs, are
>>>> not displayed in the developer portal. We are looking for a way to show
>>>> gateway URLs for *advertiseOnly* APIs without breaking the old
>>>> external store feature.
>>>>
>>>> --
>>>> *Akshitha Dalpethado* | Intern | WSO2 Inc.
>>>>
>>>> (m) :0770284542 | Email : akshi...@wso2.com
>>>>
>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>
>>>
>>>
>>> --
>>> *Nuwan Dias* | VP and deputy CTO - API Management and Integration |
>>> WSO2 Inc.
>>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
>


-- 
*Nuwan Dias* | VP and deputy CTO - API Management and Integration | WSO2
Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using advertiseOnly property to recognize AWS APIs

[Nuwan Dias]

I think it's fine to display the host (servers) URL on the OpenAPI on the
developer portal in case the advertiseOnly attribute is true. In case the
host (servers) section on the OpenAPI is null/empty, we can default to the
old behavior which is to not display anything.

Thanks,
NuwanD.

On Thu, Oct 29, 2020 at 2:57 PM Akshitha Dalpethado (Intern) <
akshi...@wso2.com> wrote:

> Hi guys,
> I'm working on the project, harvesting APIs from AWS API gateway to the
> WSO2 developer portal. As you guys know we have created a new apictl
> command for this(apictl aws init).
> We have decided to use the *advertiseOnly* property to recognize these
> APIs when we import them to the developers portal and display the API's
> host URL as the gateway URL. For instance instead of the gateway URL
> generated by the developer portal this will be the URL displayed as the
> gateway URL.
> ern7ceaofh.execute-api.us-east-1.amazonaws.com
>
> But the problem we are having is *advertiseOnly* API gateway URLs, are
> not displayed in the developer portal. We are looking for a way to show
> gateway URLs for *advertiseOnly* APIs without breaking the old external
> store feature.
>
> --
> *Akshitha Dalpethado* | Intern | WSO2 Inc.
>
> (m) :0770284542 | Email : akshi...@wso2.com
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>


-- 
*Nuwan Dias* | VP and deputy CTO - API Management and Integration | WSO2
Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [New Feature][APIM] Monetization Per Frame on websocket

[Nuwan Dias]

I would really appreciate a concrete use case on this. I'm struggling to
figure out a scenario where someone would monetize the number of frames of
an application. WebSockets are usually used for server side push events.

We have a number of high priority items to deliver which are critical to
the market we want to win. Unless there is a clear demand and clear
use-case for this, it's hard to justify deprioritization of such a feature
for WS monetization over frames. So it would be really helpful if you can
describe the business need for this or even show an existing example of
such.

On Fri, Sep 25, 2020 at 12:35 PM Vanjikumaran Sivajothy 
wrote:

> @Nuwan Dias  @Arshardh Ifthikar ,
> Any comment on this and plan to adopt into the product?
>
> On Tue, Sep 8, 2020 at 11:42 AM Vanjikumaran Sivajothy 
> wrote:
>
>> @Nuwan Dias  there are multiple opportunities there for
>> the API producers who use the WebSocket as their protocol.
>> Few examples I see;
>> 1) Gaming API
>> 2) Documentation APIs
>>
>> On Sat, Sep 5, 2020 at 5:41 AM Nuwan Dias  wrote:
>>
>>> Monetizing websocket APIs for data bandwidth usage would make sense. But
>>> why would one want to set a price per frame?
>>>
>>> On Sat, Sep 5, 2020 at 5:57 PM Vanjikumaran Sivajothy 
>>> wrote:
>>>
>>>> Since the Product has a nessary component to put this together, Can you
>>>> consider this in upcoming version and implement it?
>>>>
>>>> On Tue, Sep 1, 2020 at 10:41 PM Arshardh Ifthikar 
>>>> wrote:
>>>>
>>>>> Yes, events are published to analytics per frame
>>>>>
>>>>> On Wed, Sep 2, 2020 at 11:08 AM Fazlan Nazeem 
>>>>> wrote:
>>>>>
>>>>>> AFAIK we publish an event to Analytics Server per incoming WebSocket
>>>>>> frame. This can be verified by a simple test.
>>>>>>
>>>>>> On Wed, Sep 2, 2020 at 10:53 AM Silmy Hasan  wrote:
>>>>>>
>>>>>>> Hi vanjikumaran,
>>>>>>>
>>>>>>> We make use of analytics to  summarize and persist the request count
>>>>>>> for a certain period of time for an API, as we need an internal storage 
>>>>>>> to
>>>>>>> persist the request counts in order to publish it to the Billing engine
>>>>>>> time to time . So If the data(Request stream) is published to analytics 
>>>>>>> per
>>>>>>> frame for websocket APIs , achieving this should not be a problem. I 
>>>>>>> think
>>>>>>> for web socket APIs,  request stream is published for each frame and if 
>>>>>>> so
>>>>>>> the same peristing and publishing logic could  be used for websocket 
>>>>>>> apis
>>>>>>> and this should be a minimal effort. if not we should find a way to
>>>>>>> internally persist the frame count  for webscoket APIs and write the 
>>>>>>> logic
>>>>>>> and publish it to the billing engine.
>>>>>>> @Fazlan Nazeem  @Rukshan Premathunga
>>>>>>>  @Arshardh Ifthikar   please
>>>>>>> confirm whether streams are published to analytics per frame for 
>>>>>>> Websocket
>>>>>>> APIS.
>>>>>>>
>>>>>>> Also we have had discussions on  whether frame or bandwidth based
>>>>>>> pricing fits web socket apis better. So I think we can check the
>>>>>>> feasibility of implementing it bandwidth wise as well and decide on the
>>>>>>> better option
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 1, 2020 at 9:45 AM Vanjikumaran Sivajothy <
>>>>>>> va...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Any update on this?
>>>>>>>>
>>>>>>>> On Tue, Aug 25, 2020 at 7:10 PM Vanjikumaran Sivajothy <
>>>>>>>> va...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Team,
>>>>>>>>>
>>>>>>>>> WSO2 API Manager offers a monetization functionality in the
>>>>>>>>> product and It is working perfectly with HTTP Request-Response for the
>>>>>>>>> dynamic pricing. However, WebSocket endpoints do not work like a 

Re: [Architecture] [Dev] [New Feature][APIM] Monetization Per Frame on websocket

[Nuwan Dias]

Monetizing websocket APIs for data bandwidth usage would make sense. But
why would one want to set a price per frame?

On Sat, Sep 5, 2020 at 5:57 PM Vanjikumaran Sivajothy 
wrote:

> Since the Product has a nessary component to put this together, Can you
> consider this in upcoming version and implement it?
>
> On Tue, Sep 1, 2020 at 10:41 PM Arshardh Ifthikar 
> wrote:
>
>> Yes, events are published to analytics per frame
>>
>> On Wed, Sep 2, 2020 at 11:08 AM Fazlan Nazeem  wrote:
>>
>>> AFAIK we publish an event to Analytics Server per incoming WebSocket
>>> frame. This can be verified by a simple test.
>>>
>>> On Wed, Sep 2, 2020 at 10:53 AM Silmy Hasan  wrote:
>>>
>>>> Hi vanjikumaran,
>>>>
>>>> We make use of analytics to  summarize and persist the request count
>>>> for a certain period of time for an API, as we need an internal storage to
>>>> persist the request counts in order to publish it to the Billing engine
>>>> time to time . So If the data(Request stream) is published to analytics per
>>>> frame for websocket APIs , achieving this should not be a problem. I think
>>>> for web socket APIs,  request stream is published for each frame and if so
>>>> the same peristing and publishing logic could  be used for websocket apis
>>>> and this should be a minimal effort. if not we should find a way to
>>>> internally persist the frame count  for webscoket APIs and write the logic
>>>> and publish it to the billing engine.
>>>> @Fazlan Nazeem  @Rukshan Premathunga
>>>>  @Arshardh Ifthikar   please
>>>> confirm whether streams are published to analytics per frame for Websocket
>>>> APIS.
>>>>
>>>> Also we have had discussions on  whether frame or bandwidth based
>>>> pricing fits web socket apis better. So I think we can check the
>>>> feasibility of implementing it bandwidth wise as well and decide on the
>>>> better option
>>>>
>>>>
>>>>
>>>> On Tue, Sep 1, 2020 at 9:45 AM Vanjikumaran Sivajothy 
>>>> wrote:
>>>>
>>>>> Any update on this?
>>>>>
>>>>> On Tue, Aug 25, 2020 at 7:10 PM Vanjikumaran Sivajothy 
>>>>> wrote:
>>>>>
>>>>>> Hi Team,
>>>>>>
>>>>>> WSO2 API Manager offers a monetization functionality in the product
>>>>>> and It is working perfectly with HTTP Request-Response for the dynamic
>>>>>> pricing. However, WebSocket endpoints do not work like a typical HTTP
>>>>>> request-Response as once the connection is made the
>>>>>> communication happens via frames.
>>>>>>
>>>>>> Therefore, It is ideal to consider to implement the dynamic
>>>>>> pricing option for frame count rather than request count.
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/wso2/product-apim/issues/9185
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Vanjikumaran Sivajothy | Solution Engineer |WSO2 Inc. (m) +1 925 464
>>>>>> 6816 | (e) vanji AT wso2.com <http://wso2.com>*
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Vanjikumaran Sivajothy | Solution Engineer |WSO2 Inc. (m) +1 925 464
>>>>> 6816 | (e) vanji AT wso2.com <http://wso2.com>*
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Shilmy Hasan
>>>> Software Engineer | WSO2
>>>>
>>>> E-mail :si...@wso2.com
>>>> Phone :0779188653
>>>> web : http://www.wso2.com
>>>>
>>>> [image: https://wso2.com/signature] <https://wso2.com/signature>
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>>
>>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
>>> Mobile : +94772338839 | fazl...@wso2.com
>>>
>>>
>>>
>>
>> --
>> *Arshardh Ifthikar*
>> Senior Software Engineer | WSO2 Inc.
>>
>> Email: arsha...@wso2.com
>> Mobile: +94777218551
>> Web: http://wso2.com
>>
>> <http://wso2.com/signature>
>>
>
>
> --
>
> *Vanjikumaran Sivajothy | Solution Engineer |WSO2 Inc. (m) +1 925 464 6816
> | (e) vanji AT wso2.com <http://wso2.com>*
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
*Nuwan Dias* | VP and deputy CTO - API Management and Integration | WSO2
Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [Vote] Release of WSO2 API Manager 3.2.0 RC5

[Nuwan Dias]

I Product
>>>>  - Export an API Product
>>>>  - Generate keys for an API Product
>>>>  - Delete an API Product
>>>>  - List API Products
>>>>
>>>> Testing environment - Ubuntu 20.04 LTS, JDK 1.8.0_251
>>>>
>>>> No blockers found.
>>>>
>>>> *[+] Stable - Go ahead and release.*
>>>>
>>>> Thanks,
>>>> Wasura
>>>>
>>>> On Sat, Aug 15, 2020 at 10:23 AM Mushthaq Rumy 
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> We are pleased to announce the fifth release candidate of WSO2 API
>>>>> Manager 3.2.0.
>>>>>
>>>>> This release fixes the following issues.
>>>>>
>>>>>- Fixes : product-apim
>>>>>
>>>>> <https://github.com/wso2/product-apim/issues?q=is%3Aissue+is%3Aclosed+closed%3A2020-03-20..2020-08-15>
>>>>>- Fixes : analytics-apim
>>>>><https://github.com/wso2/analytics-apim/milestone/28?closed=1>
>>>>>
>>>>> Source and distribution,
>>>>> Runtime :
>>>>> https://github.com/wso2/product-apim/releases/tag/v3.2.0-rc5
>>>>> Analytics :
>>>>> https://github.com/wso2/analytics-apim/releases/tag/v3.2.0-rc3
>>>>>
>>>>> Documentation : https://apim.docs.wso2.com/en/3.2.0/
>>>>> Migration docs :
>>>>> https://apim.docs.wso2.com/en/3.2.0/install-and-setup/upgrading-wso2-api-manager/upgrading-process/
>>>>>
>>>>> Please download, test the product and vote.
>>>>>
>>>>> [+] Stable - go ahead and release
>>>>> [-] Broken - do not release (explain why)
>>>>>
>>>>> Thanks,
>>>>> WSO2 API Manager Team
>>>>>
>>>>>
>>>>> --
>>>>> Mushthaq Rumy
>>>>> *Associate Technical Lead*
>>>>> Mobile : +94 (0) 779 492140
>>>>> Email : musht...@wso2.com
>>>>> WSO2, Inc.; http://wso2.com/
>>>>> lean . enterprise . middleware.
>>>>>
>>>>> <http://wso2.com/signature>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
>>>> (m) +94775396038 | (e) was...@wso2.com | (b) Medium
>>>> <https://medium.com/@wasuradananjith>
>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>
>>>>
>>>> ___
>>>> Dev mailing list
>>>> d...@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards
>>>
>>> *Chaminda Jayawardena*
>>> WSO2 Inc. - http://wso2.com
>>> +94-77-7725234
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>> ___
>>> 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
>>
>
>
> --
> Saranki Magenthirarajah | Software Engineer | WSO2 Inc.
> (m) +94 770403900 | (e) sara...@wso2.com
> blog: https://medium.com/@m.saranki
> <http://wso2.com/signature>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
*Nuwan Dias* | Senior Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [Vote] Release of WSO2 API Manager 3.2.0 RC2

[Nuwan Dias]

Tested the basic flows for super tenant and tenant users. Tested API test
console on Publisher. No issues identified.

+1 to proceed with release.

On Sat, Aug 8, 2020, 12:25 Arshardh Ifthikar  wrote:

> Hi all,
>
> We are pleased to announce the second release candidate of WSO2 API
> Manager 3.2.0.
>
> This release fixes the following issues.
>
>- Fixes : product-apim
>
> 
>- Fixes : analytics-apim
>
>
> Source and distribution,
> Runtime : https://github.com/wso2/product-apim/releases/tag/v3.2.0-rc2
> Analytics :
> https://github.com/wso2/analytics-apim/releases/tag/v3.2.0-rc2
>
> Documentation : https://apim.docs.wso2.com/en/3.2.0/
> Migration docs :
> https://apim.docs.wso2.com/en/3.2.0/install-and-setup/upgrading-wso2-api-manager/upgrading-process/
>
> Please download, test the product and vote.
>
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> WSO2 API Manager Team
>
> --
> *Arshardh Ifthikar*
> Senior Software Engineer | WSO2 Inc.
>
> Email: arsha...@wso2.com
> Mobile: +94777218551
> Web: http://wso2.com
>
> 
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Harvesting API's from AWS API Gateway to the WSO2 developers portal

[Nuwan Dias]

The plan is to get the apictl to do this itself, using the aws cli
underneath. So for example, a command like below would export the Foo API
into the WSO2 dev portal from the AWS gateway's production stage.

:\> apictl aws import Foo --stage-name production

Thanks,
NuwanD.

On Fri, Aug 7, 2020 at 5:13 PM Uvindra Dias Jayasinha 
wrote:

> Hi Akshitha,
>
> Based on what you have said so far seems that this can easily be achieved
> by chaining these 5 commands together in a script. Cloud you give some
> details about the kind of automation you are trying to introduce with your
> project?
>
> On Thu, 6 Aug 2020 at 13:40, Akshitha Dalpethado (Intern) <
> akshi...@wso2.com> wrote:
>
>> Basically what we are trying to achieve through this project is to give
>> our wso2 apim users the ability to extract API's created on AWS API Gateway
>> from a specific account to the WSO2 developers portal by extracting the
>> swagger definition of an API created in the AWS using the AWS Command Line
>> Interface (AWS CLI).
>>
>> First we will be requesting for the API's a user has created in the AWS
>> APIG which will return the API's created in the AWS APIG (from a specific
>> account) and their ID's and also we will be requesting for the API Stage
>> names which is also required to extract the swagger definition of a API
>> from AWS APIG using AWS CLI.
>>
>>
>> *Command01: aws apigateway get-rest-apisCommand02: aws apigateway
>> get-stages --rest-api-id Command03: aws apigateway get-export
>> --rest-api-id  --stage-name  --export-type swagger
>> /path/file_name.json*
>>
>> Then we initialize an API project using WSO2 API CTL using the swagger
>> definition we extracted from the AWS APIG.
>> *Command: ./apictl init  --oas path/file_name.json*
>>
>> Then we can import the initialized API project to the WSO2 Developers
>> portal as an API by using the following API CTL command.
>> *Command: ./apictl import-api -f  -e 
>> -k*
>>
>> This is how it can be done manually but our goal is to automate this
>> process and allow users to extract API's they have created in the AWS APIG
>> to the WSO2 Developers portal.
>>
>>
>>
>>
>>
>> --
>> *Akshitha Dalpethado* | Intern | WSO2 Inc.
>>
>> (m) :0770284542 | Email : akshi...@wso2.com
>>
>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Senior Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] AsyncAPI specification support for WSO2 API Manager

[Nuwan Dias]

[Adding Frank and Vanji]

On Tue, Aug 4, 2020 at 5:05 PM Amila De Silva  wrote:

> Hi Ziyam,
>
> On Tue, Aug 4, 2020 at 1:48 PM Nuwan Dias  wrote:
>
>> [Adding Frank and Vanji]
>>
>> On Tue, Aug 4, 2020 at 1:26 PM Ziyam Santhosh (Intern) 
>> wrote:
>>
>>> Introduction to AsyncAPI specification
>>>
>>> *Nowadays, AsyncAPI is one of the most popular topics in the world of
>>> event-driven APIs. Earlier, There was a need for a tool to specify and
>>> document the event-driven APIs where OpenAPI specifications are restricted
>>> only to document REST APIs. Then after, AsyncAPI specification was
>>> introduced to document the specifications for event-driven APIs. There are
>>> many similarities between OpenAPI specifications and AsyncAPI
>>> specifications because AsyncAPI was inspired by OpenAPI. Keywords can be
>>> mentioned as one of the major differences between them. (Eg: The endpoints
>>> of the REST API are called as paths and endpoints of Event-driven API are
>>> called as channels).*Why AsyncAPI for WSO2 API Manager?
>>>
>>> *AsyncAPI specification helps to understand the defined APIs for both
>>> humans and machines. This makes it more special to be used by most of the
>>> developers. Enabling the usage of AsyncAPI specifications in WSO2 API
>>> manager will help our developers and consumers to easily work with
>>> event-driven APIs within our product.*Objectives of the project
>>>
>>>1.
>>>
>>>Users will be able to use existing Websocket or Kafka endpoints to
>>>create event-driven APIs by importing their AsyncAPI specifications.
>>>2.
>>>
>>>Application developers will be able to subscribe to those
>>>event-driven APIs and be allowed to consume WebSockets and Kafka streams.
>>>
>>> Importing AsyncAPI specifications
>>>
>>> *API Manager already supports WebSockets. After the implementation of
>>> this project, A WebSocket can be easily created by importing its AsyncAPI
>>> specification. Kafka is a distributed streaming platform which helps to
>>> build event-driven applications. These applications may have event-driven
>>> APIs. These APIs which are created using Kafka protocols can be described
>>> using AsyncAPI specifications. By importing these specifications into the
>>> APIM, we can enable the application developers to consume Kafka streams by
>>> subscribing to these APIs. This will be a new feature for our APIM.*
>>> Subscribing to event-driven APIs
>>>
>>> When an application developer subscribes to consume a WebSocket API,
>>> that particular WebSocket API’s proxy will be created in our API Gateway.
>>> So the gateway endpoint of that API will be used by the consumer. But, when
>>> a consumer subscribes for a Kafka endpoint API, there won’t be any mediator
>>> like API gateway between them. The Kafka endpoint itself will be used by
>>> the consumer. Still, not all Kafka Streams are free to use. There are
>>> security policies for some Kafka Streams which require certificates to use
>>> those streams. WSO2 APIM will be the provider of those certificates for our
>>> consumers to subscribe to the Kafka streams.
>>>
>> So if this was correctly understood, only WebSocket APIs will be secured
> and Throttled through the Gateway, Kafka Streams are only registered as
> APIs to make them more discoverable (and maybe Kafka Streams are only
> exposed as internal APIs). Application on DevPortal is only needed when
> consuming the WebSocket API.
> If the above is correct, the part about APIM providing certificates to
> consume Kafka streams isn't clear. Can you please explain that a bit?
>
>>
>>>
>>>
>>>
>>> Regards,--
>>> *Ziyam Santhosh*
>>> Software Engineering Intern | WSO2
>>>
>>> Email: zi...@wso2.com
>>> Mobile: +94752204021
>>> Web: http://wso2.com
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>
>>
>>
>> --
>> *Nuwan Dias* | Senior Director | WSO2 Inc.
>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Amila De Silva*
> Software Architect | Associate Director, Engineering - WSO2 Inc.
> (m) +94 775119302 | (e) ami...@wso2.com
> <http://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Senior Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] AsyncAPI specification support for WSO2 API Manager

[Nuwan Dias]

[Adding Frank and Vanji]

On Tue, Aug 4, 2020 at 1:26 PM Ziyam Santhosh (Intern) 
wrote:

> Introduction to AsyncAPI specification
>
> *Nowadays, AsyncAPI is one of the most popular topics in the world of
> event-driven APIs. Earlier, There was a need for a tool to specify and
> document the event-driven APIs where OpenAPI specifications are restricted
> only to document REST APIs. Then after, AsyncAPI specification was
> introduced to document the specifications for event-driven APIs. There are
> many similarities between OpenAPI specifications and AsyncAPI
> specifications because AsyncAPI was inspired by OpenAPI. Keywords can be
> mentioned as one of the major differences between them. (Eg: The endpoints
> of the REST API are called as paths and endpoints of Event-driven API are
> called as channels).*Why AsyncAPI for WSO2 API Manager?
>
> *AsyncAPI specification helps to understand the defined APIs for both
> humans and machines. This makes it more special to be used by most of the
> developers. Enabling the usage of AsyncAPI specifications in WSO2 API
> manager will help our developers and consumers to easily work with
> event-driven APIs within our product.*Objectives of the project
>
>1.
>
>Users will be able to use existing Websocket or Kafka endpoints to
>create event-driven APIs by importing their AsyncAPI specifications.
>2.
>
>Application developers will be able to subscribe to those event-driven
>APIs and be allowed to consume WebSockets and Kafka streams.
>
> Importing AsyncAPI specifications
>
> *API Manager already supports WebSockets. After the implementation of this
> project, A WebSocket can be easily created by importing its AsyncAPI
> specification. Kafka is a distributed streaming platform which helps to
> build event-driven applications. These applications may have event-driven
> APIs. These APIs which are created using Kafka protocols can be described
> using AsyncAPI specifications. By importing these specifications into the
> APIM, we can enable the application developers to consume Kafka streams by
> subscribing to these APIs. This will be a new feature for our APIM.*
> Subscribing to event-driven APIs
>
> When an application developer subscribes to consume a WebSocket API, that
> particular WebSocket API’s proxy will be created in our API Gateway. So the
> gateway endpoint of that API will be used by the consumer. But, when a
> consumer subscribes for a Kafka endpoint API, there won’t be any mediator
> like API gateway between them. The Kafka endpoint itself will be used by
> the consumer. Still, not all Kafka Streams are free to use. There are
> security policies for some Kafka Streams which require certificates to use
> those streams. WSO2 APIM will be the provider of those certificates for our
> consumers to subscribe to the Kafka streams.
>
>
>
>
> Regards,--
> *Ziyam Santhosh*
> Software Engineering Intern | WSO2
>
> Email: zi...@wso2.com
> Mobile: +94752204021
> Web: http://wso2.com
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>


-- 
*Nuwan Dias* | Senior Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [Vote] Release of WSO2 API Manager 3.1.0 RC3

[Nuwan Dias]

Tested the basic flows with custom users and the api import functionality
using CTL.

[+] Stable - go ahead and release



On Sun, Mar 22, 2020 at 4:45 PM Sanjula Madurapperuma 
wrote:

> Hi all,
>
> I have tested the following:
>
>- API Security Audit
>- AWS Lambda functions
>- Working with Observability
>
> No blocking issues found.
>
> +1 - Stable - Go ahead and release
>
> Thanks,
> Sanjula
>
> On Sun, Mar 22, 2020 at 4:36 PM Tharindu Dharmarathna 
> wrote:
>
>> Hi All,
>>
>> I have tested the following Databases.
>>
>> 1. Oracle
>> 2. Mysql 5.7
>> 3. Mysql 8
>> 4. Postgresql
>> 5. Oracle
>> 6. MSSQL
>>
>> No issues found.
>> +1 go ahead and Release
>>
>> Thanks
>>
>> On Sat, Mar 21, 2020 at 12:56 AM Krishan Wijesena 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are pleased to announce the third release candidate of WSO2 API
>>> Manager 3.1.0.
>>>
>>> This release fixes the following issues.
>>>
>>>- Fixes : product-apim
>>>
>>> <https://github.com/wso2/product-apim/issues?q=is%3Aissue+is%3Aclosed+closed%3A2019-11-01..2020-03-20+label%3A3.1.0+>
>>>- Fixes : analytics-apim
>>><https://github.com/wso2/analytics-apim/milestone/20?closed=1>
>>>
>>> Source and distribution,
>>> Runtime :
>>> https://github.com/wso2/product-apim/releases/tag/v3.1.0-rc3
>>> Analytics :
>>> https://github.com/wso2/analytics-apim/releases/tag/v3.1.0-rc3
>>>
>>> Please download, test the product and vote.
>>>
>>> [+] Stable - go ahead and release
>>> [-] Broken - do not release (explain why)
>>>
>>> Thanks,
>>> WSO2 API Manager Team
>>>
>>> --
>>>
>>> *Krishan Wijesena*
>>> Senior Software Engineer | WSO2
>>>
>>> Email : krish...@wso2.com
>>> Mobile : +94776219923
>>> WSO2 Inc : http://wso2.com
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>
>>
>>
>> --
>>
>> *Tharindu Dharmarathna*Technical Lead
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091*
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> *Sanjula Madurapperuma* | Software Engineering Intern | WSO2 Inc.
> (m) +94 768877766 | (e) sanj...@wso2.com
> <http://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Senior Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM 3.1.0] Support externalizing login/logout URLs (/authorize and /oidc/logout)

[Nuwan Dias]

On Tue, Jan 7, 2020 at 12:23 PM Harsha Kumara  wrote:

>
>
> On Tue, Jan 7, 2020 at 12:20 PM Malintha Amarasinghe 
> wrote:
>
>> Hi,
>>
>> Currently, we do not support $subject and we always use the local IDP as
>> the login/logout URLs (/authorize and /oidc/logout). In normal cases, this
>> works without issues. But when it comes to configuring federated login with
>> facebook, google etc, it is required to use IS (IS as KM) as the
>> intermediate IDP which has the required authenticators to support
>> facebook/google logins. In those cases, we need to point the local IDP to
>> the IS/KM and the IS/KM points to Facebook as a federated login. But this
>> flow has unnecessary one additional hop caused by the local IDP.
>>
>> As a solution, we plan to support externalizing the IDP URL (used for
>> /authorize and /oidc/logout).
>>
>> [image: image.png]
>>
>> The plan is to introduce new configs as below:
>>
>> *api-manager.xml*
>>
>> {% if apim.idp is defined %}
>> 
>> 
>>
>> {{apim.idp.authorize_endpoint}}
>> {{apim.idp.oidc_logout_endpoint}}
>>
>> 
>> {% endif %}
>>
>> *deployment.toml*
>>
>> #[api.idp]
>> #authorize_endpoint = "https://localhost:9444/oauth2/authorize;
>> #oidc_logout_endpoint = "https://localhost:9444/oidc/logout;
>>
> Token endpoint will be pointed to  gateway?
>

I don't think so. The key manager of the gateway can be something else
which does not know how to validate the token.

>
>> By default, the server will use the local IDP for login/logout. Only, if
>> the above URLs are configured, they will be used instead of the default
>> ones.
>>
>> Thoughts are highly appreciated.
>>
>> Thanks!
>> Malintha
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: hars...@wso2.coim
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 API Manager 3.0.0 RC3

[Nuwan Dias]

Tried out the API controller (CLI) to import an API and the subscription
and invocation process of it. Works as expected.

[+] Stable - go ahead and release

On Fri, Oct 25, 2019 at 3:52 AM Samitha Chathuranga 
wrote:

> Hi All,
>
> We are pleased to announce the second release candidate of WSO2 API
> Manager 3.0.0.
>
> This release fixes the following issues.
>
>- Fixes : product-apim
>
> <https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24>
>- Fixes : carbon-apimgt
>
> <https://github.com/wso2/carbon-apimgt/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24+>
>- Fixes : analytics-apim
>
> <https://github.com/wso2/analytics-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24>
>
> Source and distribution,
> Runtime : https://github.com/wso2/product-apim/releases/tag/v3.0.0-rc3
> Analytics :
> https://github.com/wso2/analytics-apim/releases/tag/v3.0.0-rc3
> APIM Tooling :
> https://github.com/wso2/product-apim-tooling/releases/tag/v3.0.0-rc
>
> Please download, test the product and vote.
>
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> WSO2 API Manager Team
>
>
> --
> *Samitha Chathuranga*
> *Senior Software Engineer*, *WSO2 Inc.*
> lean.enterprise.middleware
> Mobile: +94715123761
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs

[Nuwan Dias]

This is a feature we actually started implementation on but never
completed. We should do this feature for the Microgateway. Then proxy the
Store/Publisher APIs using the Microgateway itself rather than using MSF4J
interceptors.

On Wed, Sep 4, 2019 at 12:12 PM Rukshan Premathunga 
wrote:

>
>
> On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby 
> wrote:
>
>> Hi Rukshan,
>>
>> On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga 
>> wrote:
>>
>>> Hi Johann,
>>>
>>> If we keep the access token when generating a new token, where we can
>>> save it? Keeping in the memory will reset if the GWs get restarted. Also,
>>> we may need to keep track of each part (Map) of a token. In pub store since
>>> we need only one token at a time, this may be easy. But in the gateway can
>>> we manage this for all the tokens? Please correct me if I'm wrong.
>>>
>>
>> We don't need to store anything on the API Gateway. It will be similar to
>> how API Store/Publisher do it now - split the access token and save it in 2
>> cookies - one "httponly" and one "non-httponly". And when it is time to
>> validate it join them back. The only difference is that we will do in the
>> API Gateway instead of API Store/Publisher so that we can use the same
>> protection mechanism for regular APIs hosted on the API Gateway.
>>
> Thanks, Johann for the explanation. So we required an additional handler
> or improvement to the authentication handler to reconstruct access token.
>
>>
>> Thanks & Regards,
>> Johann.
>>
>>
>>>
>>> Thanks and Regards
>>>
>>>
>>>
>>> On Wed, Sep 4, 2019 at 10:54 AM Dushan Silva  wrote:
>>>
>>>> Hi Johann,
>>>> AFAIK we are using #2 and a similar mechanism using jaggery for the
>>>> APIM 3.x.x store/publisher.
>>>>
>>>> I'm a bit unclear on what do you mean by *"other APIs". *
>>>>
>>>> On Wed, Sep 4, 2019 at 10:47 AM Johann Nallathamby 
>>>> wrote:
>>>>
>>>>> Hi APIM Team,
>>>>>
>>>>> Protecting access tokens in SPAs has been a  complicated affair.
>>>>> Though there hasn't been a standard solution pattern for this problem, a
>>>>> cookie based protection approach is what most vendors follow.
>>>>>
>>>>> With APIM 3.x.x we are supporting cookie based access tokens to
>>>>> protect the API Store/Publisher Rest APIs. However, since this
>>>>> implementation has been done in API Store/Publisher backend, it cannot be
>>>>> reused for regular APIs hosted on the API Gateway. I was wondering if we
>>>>> can support this as a standard protection mechanism for other APIs as 
>>>>> well.
>>>>>
>>>>> *Steps*
>>>>>
>>>>> 1. Intercept the token response from authorization server in the API
>>>>> Gateway.
>>>>> 2. Modify the token response in the gateway by splitting the access
>>>>> token and writing one half to a "httponly" cookie, and other half to a
>>>>> "non-httponly" cookie or leave it in the token response body.
>>>>> 3. When the SPA calls an API by setting part of the access token which
>>>>> it has access to, in the authroziation header, the gateway will join the
>>>>> other half it reads from the "httponly" cookie, and introspect with the
>>>>> authorization server.
>>>>> 4. The current API Store/Publisher Rest APIs can also be proxied via
>>>>> the gateway to obtain same functionality.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thanks & Regards,
>>>>> Johann.
>>>>>
>>>>> --
>>>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions
>>>>> Architect | WSO2 Inc.
>>>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
>>>>> [image: Signature.jpg]
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> Dushan Silva
>>>> Software Engineer
>>>>
>>>> *WSO2, Inc. *
>>>>
>>>> lean . enterprise . middleware
>>>> Mob: +94 774 979042
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
>>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>>
>>
>> --
>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
>> WSO2 Inc.
>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
>> [image: Signature.jpg]
>>
>
>
> --
> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Making self-contained access tokens the default in APIM 3.0

[Nuwan Dias]

On Wed, 21 Aug 2019 at 10:57 pm, Manjula Rathnayake 
wrote:

> Hi Nuwan,
>
> Can the same API gateway handle both self-contained and opaque tokens?
>

Yes it can. The gateway needs to be connected to the key manager if it is
expected to validate opaque tokens.

>
> How does the API consumption work? Does the application need to invoke
> both the KM and gateway endpoints to refresh/revoke and invoke the APIs?
>

If the gateway is connected to the key manager the app can use the /token
and /revoke endpoints on the gateway itself. Otherwise the key manager
needs to be expose them some other way for apps to use.

>
> Thank you.
>
> On Wed, Aug 21, 2019 at 1:21 PM Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias  wrote:
>>
>>> Hi,
>>>
>>> With the introduction of the Microgateway self-contained access tokens
>>> were supported in the API Manager since version 2.5. Self-contained access
>>> tokens however were only supported in the Microgateway so far. The regular
>>> gateway was unable to process and validate a self-contained access token.
>>> With API Manager 3.0 we are bringing this support to the regular gateway as
>>> well. With this we hope to make self-contained tokens the default token
>>> type of applications. Opaque tokens will still be supported as before.
>>> There are several benefits of using self-contained access tokens. These are,
>>>
>>> 1) The gateway no longer connects to the Key Manager when processing API
>>> requests. This makes the deployment simpler and reduces configuration
>>> points a bit.
>>> 2) We no longer have to scale the Key Manager when we need the Gateway
>>> to be scaled. This bring a significant reduction to the cost of using the
>>> product in larger deployments.
>>> 3) The gateway becomes regionally resilient. A token issued from one
>>> region can be validated by a gateway in another region even if the data is
>>> not synced.
>>> 4) Back-end JWTs will be included in as part of the access token itself
>>> (self-contained). This eliminates the need of creating back-end JWTs while
>>> the API request is being processed. Which in turn makes APIs calls much
>>> faster.
>>>
>>> One pending items that's left to handle is the revocation of
>>> self-contained access tokens. Since the gateway does not connect to the Key
>>> Manager for validating self-contained tokens, the gateway will not know
>>> when a particular token has been revoked. Using shorter expiry times for
>>> access token addresses this solution to a certain extent. We hope to
>>> implement the same solution we implemented for the Microgateway to address
>>> this. The Key Manager will be notifying the gateway cluster through a
>>> broker when a token has been revoked. And the gateway will no longer be
>>> treating the particular token as valid upon receiving the notification.
>>>
>>> Appreciate your thoughts and suggestions on this.
>>>
>>
>> So we are making it as default to increase the usage of it ?
>>
>> Is this would be same for developer token in store (application tokens)?
>> What are the default user details which are adding to self-contains
>> access token ?
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>> Thanks,
>>> NuwanD.
>>> --
>>> *Nuwan Dias* | Director | WSO2 Inc.
>>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>>> [image: Signature.jpg]
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> Mobile : +94 777 625 933
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Manjula Rathnayaka* | Senior Technical Lead | WSO2 Inc.
> (m) +94 77 743 1987 | (w) +94 11 214 5345 | (e) manju...@wso2.com
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Making self-contained access tokens the default in APIM 3.0

[Nuwan Dias]

On Wed, 21 Aug 2019 at 1:21 pm, Asela Pathberiya  wrote:

>
>
> On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias  wrote:
>
>> Hi,
>>
>> With the introduction of the Microgateway self-contained access tokens
>> were supported in the API Manager since version 2.5. Self-contained access
>> tokens however were only supported in the Microgateway so far. The regular
>> gateway was unable to process and validate a self-contained access token.
>> With API Manager 3.0 we are bringing this support to the regular gateway as
>> well. With this we hope to make self-contained tokens the default token
>> type of applications. Opaque tokens will still be supported as before.
>> There are several benefits of using self-contained access tokens. These are,
>>
>> 1) The gateway no longer connects to the Key Manager when processing API
>> requests. This makes the deployment simpler and reduces configuration
>> points a bit.
>> 2) We no longer have to scale the Key Manager when we need the Gateway to
>> be scaled. This bring a significant reduction to the cost of using the
>> product in larger deployments.
>> 3) The gateway becomes regionally resilient. A token issued from one
>> region can be validated by a gateway in another region even if the data is
>> not synced.
>> 4) Back-end JWTs will be included in as part of the access token itself
>> (self-contained). This eliminates the need of creating back-end JWTs while
>> the API request is being processed. Which in turn makes APIs calls much
>> faster.
>>
>> One pending items that's left to handle is the revocation of
>> self-contained access tokens. Since the gateway does not connect to the Key
>> Manager for validating self-contained tokens, the gateway will not know
>> when a particular token has been revoked. Using shorter expiry times for
>> access token addresses this solution to a certain extent. We hope to
>> implement the same solution we implemented for the Microgateway to address
>> this. The Key Manager will be notifying the gateway cluster through a
>> broker when a token has been revoked. And the gateway will no longer be
>> treating the particular token as valid upon receiving the notification.
>>
>> Appreciate your thoughts and suggestions on this.
>>
>
> So we are making it as default to increase the usage of it ?
>

Well, the objective is to make the gateway more independent, easily
scalable and regionally resilient.

>
> Is this would be same for developer token in store (application tokens)?
>

Yes.

What are the default user details which are adding to self-contains access
> token ?
>

Same as the opaque token. Whoever authenticates to the system using the
grant type. In case of the store developer token it will be the app owner.

>
> Thanks,
> Asela.
>
>
>>
>> Thanks,
>> NuwanD.
>> --
>> *Nuwan Dias* | Director | WSO2 Inc.
>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>> [image: Signature.jpg]
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
>>
>
> --
> Thanks & Regards,
> Asela
>
> Mobile : +94 777 625 933
>
> http://soasecurity.org/
> http://xacmlinfo.org/
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM-3.0] Store REST API to get all active tenants

[Nuwan Dias]

Ideally we would need to support getting all tenants. But for now I think
its ok to support the active state only. Using the query param to pass in
the state gives us the flexibility to support other (inactive) states in
the future.

Regarding the other tenant specific APIs, I don't see a need to support
them right now unless we have a business requirement to do so.

On Mon, Aug 12, 2019 at 6:05 PM Dushan Silva  wrote:

> Hi all,
>
> *Few clarifications*
> We decide to write this rest endpoint to retrieve active-tenants, In
> addition to this is there a requirement where we would need to get inactive
> tenants ?
>
> what @Thilini Shanika  said makes senses its better if
> we can retrieve some important information such as tenantId, domain..
> anything else that we should return may seem significant for this api?
>
> On the other hand would we need to add few more tenant specific APIs  such
> as getting all tenant details, getting tenant by tenantId etc ? currently
> we only needed to get the active tenants for UI purposes. WDYT @Nuwan Dias
>  @Sanjeewa Malalgoda 
>
> Thanks
>
> On Mon, Aug 12, 2019 at 5:46 PM Dushan Silva  wrote:
>
>> adding architecture
>>
>> On Mon, Aug 12, 2019 at 5:34 PM Sanjeewa Malalgoda 
>> wrote:
>>
>>> Yes, Nuwan is correct here. State is filter criteria and using query
>>> parameters is recommended. Also when we fetching this sort of resources its
>>> always good to have a way to limit and paginate number of results return.
>>> @Everyone i can see many team mates need to update API and add/modify
>>> resources. In that case schedule meeting and discuss about all resource is
>>> good IMO.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Mon, Aug 12, 2019 at 5:26 PM Nuwan Dias  wrote:
>>>
>>>> We have to discuss this publicly guys.
>>>>
>>>> Shouldn't this be /tenants?state=active?
>>>>
>>>> On Mon, Aug 12, 2019 at 5:19 PM Dushan Silva  wrote:
>>>>
>>>>> Hi all,
>>>>> We are planning to add a REST API endpoint to APIM 3.0 Store REST API
>>>>> to get all the tenant active tenant domains. Shown below is the swagger
>>>>> related to the new rest api.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *### The tenant
>>>>>> resource
>>>>>> APIs##'/tenants/active-tenants':
>>>>>> #  # Retrieve all
>>>>>> active tenants  #
>>>>>> get:security:  - OAuth2Security:  - []summary: |
>>>>>> Get all active tenants namesdescription: |  This operation is to
>>>>>> retrieve all active tenantstags:  - active tenantsresponses:
>>>>>>   200:description: |  OK.  Tenant names returned.
>>>>>>   headers:  Content-Type:description: |
>>>>>>   The content type of the body.type: stringschema:
>>>>>> type: '#/definitions/TenantList'  404:description: |
>>>>>>   Not Found.  Requested application does not exist.
>>>>>> schema:
>>>>>> $ref: '#/definitions/Error'  406:description: |
>>>>>>   Not Acceptable.  The requested media type is not supported
>>>>>> schema:  $ref: '#/definitions/Error'*
>>>>>
>>>>>
>>>>>

Re: [Architecture] [APIM] [3.0] Introducing APIKeys for securing API's

[Nuwan Dias]

AFAIU the JWT will contain the APIs for which the particular Key is valid
and the TTL of the API Key. And we of course verify the signature of the
JWT as well.

When using an opaque key the gateway will have to communicate with the Key
Manager or API Store to validate the API Key. We're trying to eliminate the
gateway's dependencies during the runtime so that we can scale the gateway
more easily and have regional resiliency for the gateways as well.

On Fri, Jul 26, 2019 at 2:16 PM Bhathiya Jayasekara 
wrote:

> Hi Dumindu,
>
> What's the reason for using a JWT instead of an opaque key? What are the
> information we include in the JWT?
>
> Thanks,
> Bhathiya
>
> On Fri, Jul 26, 2019 at 1:44 PM Chathura Ekanayake 
> wrote:
>
>> Hi Dumindu,
>>
>> Could you briefly mention the steps for publishing, subscribing to and
>> invoking APIs with API Keys.
>>
>> According to the given description it looks like a similar approach to
>> using client credentials grant (with JWT). Or is it that we can associate a
>> key with an API at the publishing time.
>>
>> If it is the latter case, I guess we cannot do user or application based
>> throttling or analytics with this approach.
>>
>> Regards,
>> Chathura
>>
>> On Fri, Jul 26, 2019 at 12:46 PM Dumindu Kanchana 
>> wrote:
>>
>>> API key is the simplest form of app-based security that we will be able
>>> to configure for an API.
>>>
>>> Securing the API's with this method was already implemented in few
>>> API-Manager solutions and currently I'm working on to introduce this for
>>> the APIM 3.0.0.
>>>
>>> An API key is a string value passed by a client app to the APIM gateway.
>>> The key uniquely identifies the client app. A client app simply presents an
>>> API key with its request, then APIM gateway checks to see that the API key
>>> is in an approved state for the API being requested and allow/deny based on
>>> the validation.
>>>
>>> We are going to use a JWT to represent the APIKey which will be
>>> generated from the APIM-Store. This self-contained API Key will be
>>> validated from the gateway before allowing a resource to be consumed.
>>>
>>> In order to use this feature, we need to,
>>>
>>>1. APIKey security enabled for the API.
>>>2. An application created in the store to generate a API key
>>>
>>> As the initial steps, I'm working on to develop the Store/Publisher Rest
>>> API's and the backend implementation. We are also going to support API Key
>>> revocation for this feature.
>>>
>>> [1] Mail - "API key support"
>>> [2] Invitation: Discussion on integrating API-Key feature for AM-3.0.0 @
>>> Wed Jul 10, 2019
>>>
>>> Thanks,
>>> --
>>> *Dumindu Kanchna*
>>> Software Engineer | WSO2
>>>
>>> Email : dumin...@wso2.com
>>> Mobile : +94766958493
>>> Web : https://wso2.com
>>>
>>> <http://wso2.com/signature>
>>>
>>
>
> --
> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc.
> (m) +94 71 547 8185  | (e) bhathiya-@t-wso2-d0t-com
>
>
>

-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev][IAM] Moving File Based Artifacts to Artifact Store

[Nuwan Dias]

; customer who has asked us to support multiple types of storage mechanisms
>>> for artifacts and/or configurations? Where is this requirement coming from?
>>> I've only seen such requirements for user stores. For configurations I feel
>>> this is just over engineering. May be it is a valid requirement for
>>> artifacts? Even if we agree that there are valid reasons to support this
>>> then it has to be supported for all configurations and/or artifacts.
>>>
>>>>
>>>>- There should be a way to identify the repository where the data
>>>>is loaded from. The repository can be the file system, database or any
>>>>other storage mechanism.
>>>>
>>>> It sounds like this can get too complicated.
>>>
>>>>
>>>>- In both the read write operations the enduser should have the
>>>>control to decide the storage mechanism.
>>>>
>>>> Hmm.. this sounds more like a requirement to optimize database read
>>> write performance. Doesn't sound right for artifacts.
>>>
>>>>
>>>>- If the user needs to migrate a userstore from one storage
>>>>mechanism (file system) to another then they can do it via UI.
>>>>
>>>> Again too many options for the user can make the product fragile.
>>>
>>>
>>>> When persisting the data in the database there are two options we can
>>>> use :
>>>>
>>>>- Persist data as a blob
>>>>
>>>> If we persist as blob then we lose the granular control over each
>>> property for validation, transformation, etc.
>>>
>>>>
>>>>- Persists data as key value pair
>>>>
>>>> +1 for this.
>>>
>>>
>>>> If we are to go with the option one then we can persist the file as a
>>>> blob and reuse most of the existing parsing logics.
>>>>
>>>
>>> Given the understanding I think I prefer option 1 with properties.
>>>
>>> Thanks & Regards,
>>> Johann.
>>>
>>>
>>>>
>>>> Highly appreciate your suggestions and feedbacks on the above approach.
>>>>
>>>> [1] [Architecture][IAM][JDBC based Configuration Store] Database Schema
>>>> [2] [Architecture] [IS] JDBC based Configuration Store for WSO2 IS
>>>>
>>>> Thanks,
>>>> Hasanthi
>>>>
>>>> --
>>>>
>>>> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
>>>> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
>>>>
>>>>
>>>
>>> --
>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect
>>> | WSO2 Inc.
>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
>>> [image: Signature.jpg]
>>>
>>
>>
>> --
>> Ruwan Abeykoon | Director/Architect | WSO2 Inc.
>> (w) +947435800  | Email: ruw...@wso2.com
>>
>>
>
> --
> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
> WSO2 Inc.
> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
> [image: Signature.jpg]
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] JWT Authentication for API Gateway

[Nuwan Dias]

/token;,
>>>>>>>>>>>>   "keytype": "PRODUCTION",
>>>>>>>>>>>>   "subscribedAPIs": [
>>>>>>>>>>>> {
>>>>>>>>>>>>   "subscriberTenantDomain": "carbon.super",
>>>>>>>>>>>>   "name": "PizzaShackAPI",
>>>>>>>>>>>>   "context": "/pizzashack/1.0.0",
>>>>>>>>>>>>   "publisher": "admin",
>>>>>>>>>>>>   "version": "1.0.0",
>>>>>>>>>>>>   "subscriptionTier": "Gold"
>>>>>>>>>>>> }
>>>>>>>>>>>>   ],
>>>>>>>>>>>>   "consumerKey": "tRfDHrQNasyVaCVv1Ej4GnR2bD0a",
>>>>>>>>>>>>   "exp": 1561701126,
>>>>>>>>>>>>   "iat": 1561697526,
>>>>>>>>>>>>   "jti": "39d826ca-a56b-4637-b799-sa1ba4bbf24d"
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> We are hoping to use the same caches used for OAuth tokens to
>>>>>>>>>>>> store the JWT tokens as well. In that scenario, the payload will 
>>>>>>>>>>>> be stored
>>>>>>>>>>>> as a JSONObject in the cache as the value and the key will be the 
>>>>>>>>>>>> "jti"
>>>>>>>>>>>> value (Unique identifier of the token) of the token.
>>>>>>>>>>>>
>>>>>>>>>>>> The swagger stored in the gateway as a local entry will be used
>>>>>>>>>>>> to
>>>>>>>>>>>>  - retrieve the missing information in the payload of JWT token
>>>>>>>>>>>> such as "API tier"
>>>>>>>>>>>>  - retrieve scopes bound to the resource for scope validation
>>>>>>>>>>>>
>>>>>>>>>>>> The related Git issue can be found here [1]. I would really
>>>>>>>>>>>> appreciate any feedback. Thank you.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Chamod.
>>>>>>>>>>>>
>>>>>>>>>>>> [1] - https://github.com/wso2/product-apim/issues/5115
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>>>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> *Harsha Kumara*
>>>>>>>>>>>
>>>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>>>> Mobile: +94775505618
>>>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>>>
>>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks & Regards,
>>>>>>>>>
>>>>>>>>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
>>>>>>>>> Mobile : +94772338839 | fazl...@wso2.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>>>> GET INTEGRATION AGILE
>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
>>>>>>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
>>>>>>> GET INTEGRATION AGILE
>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Malintha Amarasinghe
>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>> http://wso2.com/
>>>>>>
>>>>>> Mobile : +94 712383306
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Harsha Kumara*
>>>>>
>>>>> Technical Lead, WSO2 Inc.
>>>>> Mobile: +94775505618
>>>>> Email: hars...@wso2.coim
>>>>> Blog: harshcreationz.blogspot.com
>>>>>
>>>>> GET INTEGRATION AGILE
>>>>> Integration Agility for Digitally Driven Business
>>>>>
>>>>
>>>>
>>>> --
>>>> *Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
>>>> (m) +94-717-064-214 |  (e) raji...@wso2.com 
>>>>
>>>> <https://wso2.com/signature>
>>>>
>>>
>>>
>>> --
>>>
>>> *Harsha Kumara*
>>>
>>> Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Email: hars...@wso2.coim
>>> Blog: harshcreationz.blogspot.com
>>>
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: hars...@wso2.coim
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Non persistent Access Tokens

[Nuwan Dias]

On Tue, Jun 25, 2019 at 10:59 AM Prabath Siriwardena 
wrote:

> +1
>
> This is what we plan in IS too - to make all the tokens JWT by default.
> This approach also helps in multi-regional setups.
>
> The drawback is the revocation. But we can find a workaround for that.
>

We have currently implemented a messaging based solution for that. The KM
(IS) would be notifying a topic on a broker to which the Microgateways are
all subscribed to. When a token is revoked the Microgateways would get to
know about that through the broker. The Microgateway would also persist the
revoked tokens locally (until expire) to deal with restarts of the
Microgateways.

>
> Thanks & Regards
> -Prabath
>
> On Mon, Jun 24, 2019 at 10:23 PM Nuwan Dias  wrote:
>
>> Hi,
>>
>> I've recently been thinking about $subject. Currently when we generate an
>> access token we persist it in the DB for various reasons. One of those
>> reasons is for validation of the issued token. But with self contained
>> signed access tokens we no longer need to look up the DB to validate the
>> access token. Not having to lookup a DB during validation is a very
>> powerful capability which opens avenues for heavily distributed
>> architectures, regional resiliencies and so on. What would be the downsides
>> of not persisting self-contained access tokens? And what mechanisms can we
>> come up with to remediate those?
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> *Nuwan Dias* | Director | WSO2 Inc.
>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>> [image: Signature.jpg]
>>
>
>
> --
> Thanks & Regards,
> Prabath
> https://github.com/prabath/me
>
>
>
>

-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Non persistent Access Tokens

[Nuwan Dias]

Hi,

I've recently been thinking about $subject. Currently when we generate an
access token we persist it in the DB for various reasons. One of those
reasons is for validation of the issued token. But with self contained
signed access tokens we no longer need to look up the DB to validate the
access token. Not having to lookup a DB during validation is a very
powerful capability which opens avenues for heavily distributed
architectures, regional resiliencies and so on. What would be the downsides
of not persisting self-contained access tokens? And what mechanisms can we
come up with to remediate those?

Thanks,
NuwanD.

-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [DEV] [VOTE] Release WSO2 API Microgateway 3.0.1 RC3

[Nuwan Dias]

Tested the basic flows and the Docker runtime.

[+] - Stable - Go ahead and release.

Thanks,
NuwanD.

On Sun, Jun 9, 2019 at 10:25 AM Praminda Jayawardana 
wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the third release candidate
> of WSO2 API Microgateway 3.0.1.
>
> The WSO2 API Microgateway is a lightweight, gateway distribution which can
> be used with single or multiple APIs.
>
> Please find the improvements and fixes related to this release in Fixed
> issues
> <https://github.com/wso2/product-microgateway/issues?utf8=%E2%9C%93=is%3Aissue+closed%3A2018-10-12..2019-06-09>
>
> Download the product from here
> <https://github.com/wso2/product-microgateway/releases/tag/v3.0.1-rc3>
>
> The Tag to be voted upon is
> https://github.com/wso2/product-microgateway/releases/tag/v3.0.1-rc3
>
> Please download, test the product and vote.
>
> *[+] Stable - Go ahead and release*
>
> *[-] Broken - Do not release *(explain why)
>
>
> Documentation: https://docs.wso2.com/display/MG301/
>
> Best Regards,
> WSO2 API Manager Team
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: Basic Authentication for APIM Gateway

[Nuwan Dias]

instead of using Basic Authentication.
>>>>>
>>>>> One option would be to allow users to send a custom header containing
>>>>> the client id which requires a lesser logical change at their code level.
>>>>> Even this option will arise the need for dynamic headers to support
>>>>> multi-tenants as well which is a considerable change.
>>>>>
>>>>> Best regards,
>>>>> Chamod.
>>>>>
>>>>> On Fri, Mar 8, 2019 at 2:33 PM Chamod Samarajeewa 
>>>>> wrote:
>>>>>
>>>>>> Are we caching the decision?
>>>>>>>
>>>>>>
>>>>>> Yes. We are hoping to use a caching mechanism.
>>>>>>
>>>>>> On Fri, Mar 8, 2019 at 2:29 PM Harsha Kumara 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 8, 2019 at 3:56 AM Chamod Samarajeewa 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Harsha,
>>>>>>>>
>>>>>>>> In the current implementation, we are not calling a token endpoint.
>>>>>>>> We directly validate basic auth credentials using 
>>>>>>>> RemoteUserStoreManager
>>>>>>>> admin service. Therefore, no hardcoded consumer key and password is 
>>>>>>>> used.
>>>>>>>>
>>>>>>> Are we caching the decision?
>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Chamod.
>>>>>>>>
>>>>>>>> On Fri, Mar 8, 2019 at 2:18 PM Harsha Kumara 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> @Chamod Samarajeewa  can you share current
>>>>>>>>> implementation details? Is you basic authentication handler, I assume 
>>>>>>>>> you
>>>>>>>>> calling token endpoint with hard coded consumer key and password. We 
>>>>>>>>> should
>>>>>>>>> be able to support Johann's suggestion with Option 1.
>>>>>>>>>
>>>>>>>>> On Fri, Mar 8, 2019 at 3:20 AM Harsha Kumara 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Is your requirement is to provide basic authentication via
>>>>>>>>>> clientId and clientSecret? For the microgateway, it will required to
>>>>>>>>>> validate the this by connecting to the key manager and bring the 
>>>>>>>>>> throttling
>>>>>>>>>> information and etc which will require another API. Else at micro 
>>>>>>>>>> gateway
>>>>>>>>>> it will required to generate a token using clientd and secret and 
>>>>>>>>>> resume
>>>>>>>>>> the flow.
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 8, 2019 at 2:28 AM Johann Nallathamby <
>>>>>>>>>> joh...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> *[sending this mail again because previous one wasn't copied to
>>>>>>>>>>> architecture@wso2.org ]*
>>>>>>>>>>>
>>>>>>>>>>> Hi Nuwan, Hi Harsha, Hi Chamod,
>>>>>>>>>>>
>>>>>>>>>>> An additional thought here. Most of the times customers who ask
>>>>>>>>>>> for basic authentication support are the customers who need to 
>>>>>>>>>>> support
>>>>>>>>>>> legacy external applications I believe; not so much the internal
>>>>>>>>>>> applications. Because, there can be many external parties and they 
>>>>>>>>>>> cannot
>>>>>>>>>>> ask all those parties to change. For example, mobile apps that take
>>>>>>>>>>> username/password to be changes to OAuth2.
>>>>>>>>>>>
>>>>>>>>>>> In those cases it could be also useful to track all these
>>>>>>>>>>> "clients&q

Re: [Architecture] [APIM] Introduce API Product Concept

[Nuwan Dias]

In addition to bundling APIs, an important feature with API products is the
ability to create products with only parts of APIs. For example you have an
API with 20 resources that performs various actions. You may want to create
2 API products with that API. One product with only the read-only
operations of that API (5 resources) and sell it at a certain price. And
the other product with all operations available at a higher price than the
former.

On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva  wrote:

> Hi Chathura,
>
> Please find my answers below.
>
> "*How does API product level throttling work with API/resource level
> throttling? Does it override API/resource level throttling? Or does the
> most restrictive policy apply?*"
>
> Resource level policies will be inherited from underlying APIs. API level
> subscription policy will get overridden by product level subscription
> policies.
>
> "*So when getting a token does the user has to specify the API product
> scope and the resource scope (if any)?*"
>
> Yes, normal oauth scope rules will not get affected.
>
>
> Thanks,
>
> Sachini
>
> On Tue, Apr 9, 2019 at 2:20 PM Chathura Ekanayake 
> wrote:
>
>> Hi Sachini,
>>
>> Grouping APIs as mentioned is an useful feature. Few comments inline..
>>
>> On Tue, Apr 2, 2019 at 2:25 PM Sachini De Silva 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are planning to introduce API product concept to API Manager.
>>>
>>> An API product is basically a bundle of APIs/ API resources that is made
>>> available to users to subscribe and consume. API product creator can attach
>>> a throttling policy and other metadata to the API product. The collection
>>> of APIs/resources in the product are such that they address a specific
>>> business use case.
>>>
>>> For example, I have 3 APIs as below. And I need to bundle API A and B
>>> together, attach a higher throttling limit and make it available for paid
>>> customers. And bundle API B, C together with a lower throttling limit and
>>> make it available for free use.
>>>
>>
>> How does API product level throttling work with API/resource level
>> throttling? Does it override API/resource level throttling? Or does the
>> most restrictive policy apply?
>>
>>
>>>
>>> [image: image.png]
>>>
>>> Below is how we are planning to implement this feature on APIM.
>>>
>>> 1. When a user creates an API product a new scope(without any role
>>> assigned) will be created and attached to all the api resources he/she is
>>> allowing for that API product.
>>> 2. Then a user can subscribe to the api product and in order to get a
>>> token for the API product, he/she has to pass the scope details along with
>>> the token request.
>>> 3. So that the request can be identified as coming through the API
>>> product and handled accordingly.
>>>
>>> The reason for using this scope based approach is to avoid creating a
>>> new gateway resource for the APIs in the product. In above, the requests
>>> will be directed to the existing APIs deployed in the gateway and the
>>> request will be distinguished as coming from an API product by using the
>>> scope attached to the access token.
>>>
>>> Following are several concerns we identified and appreciate your
>>> thoughts and suggestions on them.
>>>
>>> * At the moment an API resource can’t be assigned multiple scopes. - we
>>> are currently looking into this.
>>>
>>
>> So when getting a token does the user has to specify the API product
>> scope and the resource scope (if any)?
>>
>>
>>> * We are planning to introduce a new API product throttling level. At
>>> the moment we are further looking into throttling and analytics for API
>>> products.
>>>
>>> * With regard to UI aspects, we will be adding a new section in API
>>> publisher UI to create and modify API products. And in store, we will be
>>> adding a new section to view and subscribe to API products.
>>>
>>> Thanks,
>>> Sachini
>>> --
>>>
>>> *Sachini De Silva*
>>> Software Engineer - WSO2
>>>
>>> Email : sachi...@wso2.com
>>> Mobile : +94714765495
>>>
>>>
>
> --
>
> *Sachini De Silva*
> Software Engineer - WSO2
>
> Email : sachi...@wso2.com
> Mobile : +94714765495
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] How are we planing to support API versioning in v3

[Nuwan Dias]

On Fri, Mar 22, 2019 at 2:17 AM Nuwan Bandara  wrote:

> Hi All,
>
> I stumbled upon one of Roy Fielding tweets -
> https://twitter.com/fielding/status/376835835670167552 :)
>

I unfortunately don't agree with this tweet :). I don't understand how
having a v1 makes your API non-evolvable. IMO the sole purpose of having v1
is to say the API will/should evolve to v2, v3, likewise.

>
> and started digging bit on api versioning. Right now we encourage API-M
> users to make API versions explicit in the API URI. which means a sample
> URI is /{context}/{version}/{resource}
>
> example: /pizzahut/v1/order
>
> however this is not the best option. We are gateway providers, IMO we
> should give options.
>

We give an option to omit the version from the URI by marking the API as
the default version to route to. So you can access this API through
/pizzahut/order (no need v1). The gateway will route the request to
whatever version is selected as primary (default).

>
> some good alternatives are allow API developers to use headers to
> communicate version info like
>
> GET /pizzahut/order
> Accept: application/vnd.pizza.order.v1+json
>
> or something similar.
>
> I know we can handle custom headers in mediation, but we should provide
> this by default, maybe provide that as the default option rather than URL
> based explicit option.
>
> Some good reading -
> https://www.mnot.net/blog/2012/12/04/api-evolution.html
>
> Regards,
> /Nuwan
>
> --
>
>
> *Thanks & Regards,*
> *Nuwan Bandara | Director - **Solutions Architecture,  WSO2 Inc.*
> *+1 646 643 8618 | +1 650 745 2169 Ext 4212 | http://nuwanbando.com
> <http://nuwanbando.com> *
> <http://www.nuwanbando.com/>
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

[Nuwan Dias]

I don't think we need to complicate this anymore. We all know the downsides
of having too many options to do the same thing in slightly different ways.

The reason you're seeing this as "Gateway" AND "Key Manager" is because you
are thinking in terms of profiles. But if you look at it from a single
product point of view what we simply have is API Manager integration with
third part IDP. When someone implements the interfaces they are simply
implementing API Manager interfaces not Gateway interfaces nor Key Manager
interfaces. So even if someone wants to do a subscription validation at the
point of validating the token they simply have to implement the relevant
interface method and deploy on the gateway itself. There's no need to
deploy additional nodes or anything like that just because this code is
executed on the Key Manager profile. The only downside of this approach is
that you would need to run the gateway in the default profile. Which I
think is a good trade off rather than complicating the product than it
already is.

Thanks,
NuwanD.

On Fri, Mar 8, 2019 at 1:56 PM Johann Nallathamby  wrote:

> Hi Nuwan,
>
> On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias  wrote:
>
>> There are several reasons.
>>
>> 1) It is not just the gateway but also the store that needs to
>> communicate with the IDP. So the integration point cannot be the gateway
>> alone.
>>
>
> Correct. So when we do integrations in the current model we have, do we
> not need to integrate the API store with the 3rd party key manager? Are you
> saying the API store works as it is with our key manager, and the key
> manager extension takes care of all integrations with the 3rd party? As a
> percentage how many percent of times we needed to customize the API store
> for 3rd party integrations? Can you give some examples of when we needed to
> customize the API store?
>
> One use case I came across was to integrate multiple key managers to the
> API store. In that case I believe we need to customize the store. Or may be
> still there is some way you can hide the number of 3rd party key managers,
> from the WSO2 key manager interface?
>
>
>> 2) Most customers sill want to validate the subscription in addition to
>> validating the token. The IDP will validate the token but APIM will have to
>> validate the subscription. The gateway cannot validate the subscription
>> directly since it requires access to the DB on which this data is stored.
>>
>
> Ok. This is a good point. So I understand to cater this we need to go
> through our key manager.
> Just a thought. Can we give 2 options here:
> 1. For customers who want to validate subscription they can proxy only the
> validation call through our key manager.
> 2. For customers who don't want to validate subscriptions they can
> directly call the 3rd party key manager. This percentage could be quite low
> as I understand.
> May be there is no code changes required here. But it could be our
> guideline. What do you think?
>
> I haven't done a key manager extension myself. But as far as the runtime
> validation extension goes, what I understand is that it should be simple as
> one API call. The gateway calls the WSO2 key manager's validation API,
> which internally calls the 3rd party key manager's introspection API, gets
> the response, validates it, validates the subscription in the database, and
> returns validation response to gateway. Correct?
> I will check on the 3rd party key manager extension sample and get back if
> I find anything more complicated than this.
>
>
>
>> 3) Scopes are also not always supported by all IDPs and even when they do
>> only very few IDPs can map a resource against a scope. While standard IDPs
>> support introspection of tokens there is no such standard for validating
>> whether a given token bears the required scope to access a resource.
>> Therefore we again need to perform this validation on APIM. And in order to
>> do that you again have to get access to the storage where this information
>> is stored. The gateway in most cases doesn't have access to the storage
>> layer of APIM.
>>
>
> Ok. So this also should be covered by the validation call to the key
> manager in option 1 above. We can also add scope validation to our
> guideline of when to propose key manager extension.
>
> Thanks & Regards,
> Johann.
>
>
>>
>> On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby 
>> wrote:
>>
>>> APIM Team,
>>>
>>> I would like to understand what was the original reason we went with a
>>> 3rd party key manager extension in our key manager component, rather than
>>> giving the extensibility to integrate a 3rd party ke

Re: [Architecture] [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

[Nuwan Dias]

There are several reasons.

1) It is not just the gateway but also the store that needs to communicate
with the IDP. So the integration point cannot be the gateway alone.
2) Most customers sill want to validate the subscription in addition to
validating the token. The IDP will validate the token but APIM will have to
validate the subscription. The gateway cannot validate the subscription
directly since it requires access to the DB on which this data is stored.
3) Scopes are also not always supported by all IDPs and even when they do
only very few IDPs can map a resource against a scope. While standard IDPs
support introspection of tokens there is no such standard for validating
whether a given token bears the required scope to access a resource.
Therefore we again need to perform this validation on APIM. And in order to
do that you again have to get access to the storage where this information
is stored. The gateway in most cases doesn't have access to the storage
layer of APIM.

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby  wrote:

> APIM Team,
>
> I would like to understand what was the original reason we went with a 3rd
> party key manager extension in our key manager component, rather than
> giving the extensibility to integrate a 3rd party key manager at the
> gateway itself.
>
> What are the problems in supporting 3rd party Key Manager integrations
> directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can
> provide a well designed OAuth2 security handler on the gateway, with
> template methods to extend and integrate 3rd party KMs?
>
> Pros:
> 1. Taking advantage of standards such as OAuth2/OpenID Connect which are
> supported by many vendors already, will reduce developer effort to
> understand protocols, will reduce development time and increase
> reusability. I feel like we are just complicating the process by going
> through a constricted API layer.
> 2. Higher level SPIs like handlers in the gateway are much easier to
> understand and more people have worked with those SPIs already for other
> purposes.
> 3. It gives you more flexibility to integrate with key manager, because
> there is more contextual information available in gateway.
> E.g. recently in a customer engagement I came across the requirement to
> integrate with multiple 3rd party key managers, based on hostname of the
> API request, using one gateway handler extension.
> 4. It is seen as a security vulnerability to share the access tokens and
> refresh tokens via a 3rd part component in between client and actual token
> provider.
> 5. We don't need to have our key manager in the deployment if we can
> directly integrate with the 3rd party key manager, which saves running cost
> for the customer.
>
> Cons:
> 1. The contract of the handler may not be as clear as the key manager
> extension, because it is a more generic extension than the key manager
> extension; the key manager extension could be more tighter. But this can be
> improved by design patterns.
>
> I believe the pros out weigh the cons. If you think the key manager
> extension point is also important, then we can have two levels of extension
> points, and choose depending on what we think is the best for the
> requirement.
>
> What is your opinion on this?
>
> Thanks & Regards,
> Johann.
>
> --
> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
> WSO2 Inc.
> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
> [image: Signature.jpg]
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Decoupling API Manager and API Microgateway

[Nuwan Dias]

lhost:9443/oauth2/token;
>>>
>>>
>>> *Implementation:*
>>>
>>> In order to implement as above, we need to recognize the REST API
>>> version which corresponds to the API Manager version. Following approaches
>>> are identified;
>>>
>>>
>>> 1. Get the version of the REST API of the specific API Manager version
>>> by using the API Manager’s swagger definition. However, an endpoint to
>>> access swagger definition is not provided in API Manager 2.x
>>>
>>> 2. Profile REST API version for each API Manager version in
>>> Microgateway. (Drawback of this approach is that, Microgateway will only
>>> provide backward compatibility(compatible only to past API Manager
>>> versions) because new versions of API Manager which are released later may
>>> not be included yet in version profiling.)
>>>
>>>
>>> Among them, the second option is selected. Version profiling in
>>> Microgateway is more suited considering time constraints and simplicity.
>>>
>>>
>>> I would really appreciate your feedback. Thank you.
>>>
>>>
>>> *Reference:*
>>>
>>> [1] https://github.com/wso2/product-microgateway/issues/301
>>>
>>
>>
>> --
>> *Amali Lakshika*
>>
>>
>>
>>
>> *Software EngineerWSO2 Inc.: https://wso2.com
>> <http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932 1861*
>>
>> *skype: amali.94d*
>>
>> <http://wso2.com/signature>
>>
>>
>
>
> --
> *Amali Lakshika*
>
>
>
>
> *Software EngineerWSO2 Inc.: https://wso2.com
> <http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932 1861*
>
> *skype: amali.94d*
>
> <http://wso2.com/signature>
>
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Microgateway] API Manager JWT Token Revocation Feature

[Nuwan Dias]

On Wed, Feb 27, 2019 at 12:54 PM Vanjikumaran Sivajothy 
wrote:

> OAuth Token can be exchanged for a JWT token; In that case, if the root
> OAuth token revoked there is a need of removing the relevant JWT token
> also.
>

I'm not sure whether we support a scenario like that today. What is the
grant type that allows you to exchange an OAuth token for a self contained
(JWT) token?

>
> Will it be under consideration in this implementation?
>
> On Wed, Feb 13, 2019 at 12:52 AM Nuwan Dias  wrote:
>
>>
>>
>> On Wed, Feb 13, 2019 at 11:27 AM Sanjeewa Malalgoda 
>> wrote:
>>
>>> Thanks for the inputs. When i think about this feature further i think
>>> we do not need to limit this capability for JWT revoke. We can implement
>>> some mechanism to send some updates details etc to gateways from outside on
>>> demand. JWT revocation could be one use case. But we need to check the
>>> feasibility of pushing config updates(API resource updates etc), blocking
>>> conditions etc. If we have something like config API then it will also work
>>> here. If we have high decentralized system with multiple gateways then
>>> updating each of them might be complicated task( However this might be easy
>>> if container management system).
>>>
>>
>> Yes, once we have the infra setup we can use it for multiple things.
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Tue, Feb 12, 2019 at 5:11 PM Nuwan Dias  wrote:
>>>
>>>> I have created a Git issue for this [1].
>>>>
>>>> I believe the pub-sub model is more suitable for this. I've explained
>>>> the proposed architecture on the Git issue.
>>>>
>>>> This capability is only required for the ones who want to propagate
>>>> token revocations to the microgateways as soon as possible. The tokens
>>>> (usually) expire in about an hour. Therefore the user group who are
>>>> interested in this feature are the ones who would typically want the
>>>> revocations to be propagated sooner than that. And these types of users
>>>> would most probably demand for a near real time impact. The disadvantage of
>>>> the pull model is that for the revocations to be notified soon enough, the
>>>> microgateways will have to keep polling the STS quite frequently, say like
>>>> once every minute at least. With 100 microgateways, that would mean a
>>>> considerable amount of load on the STS to deal with. And we now have to
>>>> worry about the scaling factor of the STS along with the scaling factor of
>>>> the microgateway. Hence I doubt the polling model is right for this.
>>>>
>>>> With web-hooks the problem is that the STS requires an outward
>>>> connection to each of the microgateways. Imagine having the STS on cloud
>>>> and the microgateways on-prem. The cloud would not have a physical
>>>> connection to the on-prem microgateways to revoke tokens.
>>>>
>>>> The pub-sub model gives us a decoupled architecture (in terms of
>>>> scalability) with a near real-time impact, which I think is ideal. For the
>>>> persistence related issue I think we need to introduce a lightweight
>>>> persistence layer across the microgateways.
>>>>
>>>> [1] - https://github.com/wso2/product-microgateway/issues/298
>>>>
>>>> On Sat, Feb 9, 2019 at 9:53 PM Fazlan Nazeem  wrote:
>>>>
>>>>> Hi Sanjeewa,
>>>>>
>>>>> Irrespective of the method we use to implement this, once we choose a
>>>>> mechanism, we will not be able to refer to the JWT tokens as
>>>>> self-contained, isn't it? Because we will have to depend on an external
>>>>> party to decide the validity of a token.
>>>>>
>>>>> AFAIU, I think the pub/sub model and push model has a disadvantage if
>>>>> the process running the topic(in pub/sub model) or the microgateway(in 
>>>>> push
>>>>> model) restarted(unless we repopulate the topic or the mgw memory on each
>>>>> restart with JTIs of unexpired revoked tokens).
>>>>>
>>>>> With the Pull model, I don't see this issue. the key manager only
>>>>> needs to store the unexpired revoked token information.
>>>>>
>>>>> I also feel that we need to introduce a config to switch on
>>>>> enabling/disabling this feature so that we can also use the microgat

Re: [Architecture] [APIM - Microgateway] Restructuring the Microgateway Project Folder Structure and Command Execution to Support Multiple APIs

[Nuwan Dias]

On Mon, Feb 25, 2019 at 3:31 PM Arshardh Ifthikar  wrote:

> Hi all,
>
> Shall we also give the option for a developer to specify the default API
> version.
> We will have to come up with a mechanism to support this. It would be
> great if we can add this as a flag or introduce a new command, instead of
> altering the swagger file.
> This was a requirement when we first released the developer-first approach.
>

Yes +1. Since this concept is a WSO2 specific thing we can't add it to the
OAS file IMO. This is one use-case for bringing up a api meta-data file.
There should be a specific entry in this file to indicate that a given API
should be exposed as the default version API.

>
> Thanks,
> Arshardh
>
> On Mon, Feb 25, 2019 at 10:15 AM Nuwan Dias  wrote:
>
>>
>>
>> On Sun, Feb 24, 2019 at 3:20 PM Pubudu Gunatilaka 
>> wrote:
>>
>>> Hi,
>>>
>>> On Sat, Feb 23, 2019 at 1:01 PM Viraj Gamage  wrote:
>>>
>>>> Hi all,
>>>>
>>>> There is a requirement to add the following features to the
>>>> Microgateway in Future.
>>>>
>>>>1.
>>>>
>>>>Add multiple APIs to a project
>>>>2.
>>>>
>>>>Publish APIs from Microgateway to Store
>>>>3.
>>>>
>>>>Support fine-grained endpoint configurations based on resource
>>>>level.
>>>>-
>>>>
>>>>   Ex. GET menu - 
>>>> POST order - 
>>>>
>>>>
>>>> Currently, when the “micro-gw setup” command is executed, it fails if
>>>> the project already exists and therefore we have no mechanism to add
>>>> another API to the same project.
>>>>
>>>
>>> We have the label concept in APIM to group APIs and use that label to
>>> generate the microgateway. But when moving with dev first approach, we
>>> can't use this approach.
>>>
>>
>> I wonder whether if its even required in this case. The labels are
>> attached to APIs on "API Manager". And all APIs with the same label are put
>> into the same project anyway. In the developer first approach you have a
>> native way of putting APIs into the same project, so labels become
>> obsolete.
>>
>>>
>>>> Considering the developer first approach, the current folder structure
>>>> of the project is as follows.
>>>>
>>>> Command:
>>>>
>>>> *micro-gw setup  -oa  -e *
>>>>
>>>> Folder Structure:
>>>>
>>>> .
>>>>
>>>> ├── conf
>>>>
>>>> │   └── deployment-config.toml
>>>>
>>>> ├── src
>>>>
>>>> │   ├── PizzaShackAPI_1_0_0.bal
>>>>
>>>> │   ├── extension_filter.bal
>>>>
>>>> │   ├── listeners.bal
>>>>
>>>> │   └── policies
>>>>
>>>> │   ├── application_10PerMin.bal
>>>>
>>>> │   ├── application_20PerMin.bal
>>>>
>>>> │   ├── application_50PerMin.bal
>>>>
>>>> │   ├── subscription_Bronze.bal
>>>>
>>>> │   ├── subscription_Gold.bal
>>>>
>>>> │   ├── subscription_Silver.bal
>>>>
>>>> │   ├── subscription_Unauthenticated.bal
>>>>
>>>> │   └── throttle_policy_initializer.bal
>>>>
>>>> └── target
>>>>
>>>> *Proposed Flow of the Process:*
>>>>
>>>> *1. setup command*
>>>>
>>>> *micro-gw setup  *
>>>> This is allowed and it will create the following folder structure
>>>>
>>>> ├── conf
>>>>
>>>> │   └── deployment-config.toml
>>>>
>>>> ├── routes.yaml
>>>>
>>>> ├── src
>>>>
>>>> │   └── policies
>>>>
>>>> └── target
>>>>
>>>> *micro-gw setup  -a  -oa 
>>>> -e *
>>>>
>>>>
>>> How do we handle functions? We may need a mechanism to provide a set of
>>> functions for mediations and match those with the relevant resources. There
>>> can be instances where we need to define multiple endpoints. Then we would
>>> need a way to define those multiple endpoints.
>>>
>>
>> Yes, we would need something like micro-gw add route -e "endpoint" -f

Re: [Architecture] [APIM - Microgateway] Restructuring the Microgateway Project Folder Structure and Command Execution to Support Multiple APIs

[Nuwan Dias]

rence with add-route command)
>>
>>
>> More importantly, there will not be a code generation operation at the
>> “setup” phase. In other words, there won’t be a “pizzashackAPI_1.0.0.bal”
>> file during this phase.
>>
>>
>> 2. add-api command
>>
>> As mentioned earlier, A project can either be “setup” with just one API
>> definition or without any API definition. To add more APIs, we need to
>> introduce the add command.
>>
>> *micro-gw add-api -a  -oa 
>> -e 
>>
>>
> I think in all the cases we have to specifically provide the project name
> when executing the tool kit commands. If you look at the below commands,
> you will need the relevant project. Shall we come up with a command like
> below?
>
> micro-gw set-project 
>

Yes, +1.

>
> Then we don't need to provide the project name every time.
>
>>
>> As mentioned in the setup command, the user can define his own api_name.
>> This is to add the capability to automate the execution (shell scripts).
>> For more details see the “add_route” command in the below section. But in
>> all the other operations, we will be continuing with api_name provided in
>> the swagger.
>>
>> consider the following command,
>>
>> micro-gw add-api -a DrinksAPI -oa drinks_swagger.json -e some_endpoint
>>
>> ├── API_files
>>
>> │   ├── DrinksAPI
>>
>> │   │ └── v_1.0.0
>>
>> │   │├── drinksAPI.yaml
>>
>> │   │└── meta_data.dat
>>
>> │   └── PizzaAPI
>>
>> │   └── v_1.0.0
>>
>> │   ├── meta_data.dat
>>
>> │   └── pizzashackAPI.yaml
>>
>> ├── conf
>>
>> │   └── deployment-config.toml
>>
>> ├── routes.yaml
>>
>> ├── src
>>
>> │   └── policies
>>
>> └── target
>>
>> It can be observed that still there is no code generation (bal file
>> generation) has happened.
>>
>> 3. add-route command
>>
>>
>> * micro-gw add-route -a  -v 
>>   -e *
>>
>>
>> We have added a basic endpoint while setting up the API. This command is
>> to provide separate endpoints based on resource level.  would
>> be something like “GET”, “POST” etc. and resource_name would be something
>> like “menu”. These details would be added to the routes.yaml as well.
>>
>>
>> 4. build command
>>
>>
>> micro-gw build 
>>
>>
>> This is the same existing command. The difference is that code generation
>> and compilation both happen at this phase. (Previously code generation
>> happened at the “setup”  phase.) In this case, pizzashackAPI_1.0.0.bal file
>> and drinksAPI_1.0.0.bal both will be saved in the src directory. Target
>> directory will have all the components which will be required to run the
>> microgateway.
>>
>>
>> 5. delete_api command
>>
>>
>> micro-gw delete-api -a  -v 
>>
>
>> Since we are supporting add_api command, we need to support delete_api
>> command as well.
>>
>> 6. list_apis command
>>
>>
>> micro-gw list_apis
>>
>>
>> This will list down all the APIs with their available versions. (API name
>> would be the name of that folder corresponding to the API)
>>
>> 7. register command
>>
>> micro-gw register -a  -v 
>>
>>
>> This command will publish the API in Store. Since we have the swagger
>> file saved in the directory, we can use the Publisher API.
>>
>>
>>
>> Please consider that the command names and the arguments are not
>> finalized yet. But this is the expected way to accomplish the task.
>>
>> As the initial step, the setup command and build command will be changed
>> as mentioned. In addition, the register command will be implemented.
>>
>> Regards,
>> Viraj
>> --
>> *Viraj Salaka Gamage* | Software Engineer | WSO2 Inc.
>> +94 710 618 178
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Associate Technical Lead
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>

-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Basic Authentication for APIM Gateway

[Nuwan Dias]

Yes, if we can maintain the resources and their respective scopes at the
synapse definition, we can avoid doing another call to KM (and the DB) at
the point of token validation.

Also Chamod I guess we will have to come up with a design of how to keep
those information in the synapse XML.

On Thu, Feb 21, 2019 at 2:27 PM Chamod Samarajeewa  wrote:

> Hi all,
>
> We have currently used the AuthenticationAdmin service to authenticate a
> user given the username and password(Basic Authentication). The next step
> is to validate whether the scopes bound to a resource are matched with the
> user roles. In this case, we might have to access the KeyManager several
> times as mentioned below.
>
> 1) Validate user based on username and password
> 2) To check whether the resource has a scope and if so request the scopes
> 3) Request user roles if scopes are bound to the resource
>
> We thought we can minimize the performance degradation which can happen
> due to multiple requests to the Key Manager as below.
>
> *Solution :*
>
> When a user publishes an API, the scopes bound to the API should be added
> to the Synapse-config. Then, at the runtime we can read the synapse
> configuration of API to check whether the resource has a scope bound and if
> so what are the scopes without calling the Key Manager.
>
> I would really appreciate any feedback. Thank you.
>
> Best regards,
> Chamod.
>
>
> On Sat, Feb 16, 2019 at 9:10 PM Chamod Samarajeewa 
> wrote:
>
>> Hi Harsha,
>>
>> Yes, the user can expose API either OAuth, Basic auth or even both with
>> this implementation. Thank you.
>>
>> Best Regards,
>> Chamod.
>>
>> On Fri, Feb 15, 2019 at 9:34 PM Harsha Kumara  wrote:
>>
>>> Hi Chamod,
>>>
>>> Can user choose to expose API either OAuth or Basic authentication with
>>> this implementation?
>>>
>>> We need to provide basic authentication agaist user store configured in
>>> the key manager. Because most of the timee, gateway won't share user
>>> stores. Please add the local user store authentication support as well. We
>>> need to look for possible caching mechanism for this.
>>>
>>> Since we do have mutual authentication as a security scheme, check the
>>> best way of providing the basic authentication
>>>
>>> Thanks,
>>> Harsha
>>>
>>> On Fri, Feb 15, 2019 at 9:07 PM Chamod Samarajeewa 
>>> wrote:
>>>
>>>> Adding architecture@wso2.org
>>>>
>>>> On Fri, Feb 15, 2019 at 5:18 PM Harsha Kumara  wrote:
>>>>
>>>>> Hi Chamod,
>>>>>
>>>>> Can user choose to expose API either OAuth or Basic authentication
>>>>> with this implementation?
>>>>>
>>>>> We need to provide basic authentication agaist user store configured
>>>>> in the key manager. Because most of the timee, gateway won't share user
>>>>> stores. Please add the local user store authentication support as well. We
>>>>> need to look for possible caching mechanism for this.
>>>>>
>>>>> Since we do have mutual authentication as a security scheme, check the
>>>>> best way of providing the basic authentication
>>>>>
>>>>> Thanks,
>>>>> Harsha
>>>>>
>>>>> On Fri, Feb 15, 2019 at 4:59 PM Chamod Samarajeewa 
>>>>> wrote:
>>>>>
>>>>>> Adding architect...@wso2.com.
>>>>>>
>>>>>>
>>>>>> -- Forwarded message -
>>>>>> From: Nuwan Dias 
>>>>>> Date: Fri, Feb 15, 2019 at 3:01 PM
>>>>>> Subject: Re: Basic Authentication for APIM Gateway
>>>>>> To: Chamod Samarajeewa 
>>>>>> Cc: Architecture Team , APIM Team <
>>>>>> apim-gr...@wso2.com>
>>>>>>
>>>>>>
>>>>>> Chamod, this email should be sent to architecture@wso2.org.
>>>>>>
>>>>>> Thanks,
>>>>>> NuwanD.
>>>>>>
>>>>>> On Fri, Feb 15, 2019 at 2:37 PM Chamod Samarajeewa 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I have included the information in the Github issue here as well.
>>>>>>>
>>>>>>> *Requirements*
>>>>>>>
>>>>>>>
>>>>>>> Provi

Re: [Architecture] [Microgateway] API Manager JWT Token Revocation Feature

[Nuwan Dias]

On Wed, Feb 13, 2019 at 11:27 AM Sanjeewa Malalgoda 
wrote:

> Thanks for the inputs. When i think about this feature further i think we
> do not need to limit this capability for JWT revoke. We can implement some
> mechanism to send some updates details etc to gateways from outside on
> demand. JWT revocation could be one use case. But we need to check the
> feasibility of pushing config updates(API resource updates etc), blocking
> conditions etc. If we have something like config API then it will also work
> here. If we have high decentralized system with multiple gateways then
> updating each of them might be complicated task( However this might be easy
> if container management system).
>

Yes, once we have the infra setup we can use it for multiple things.

>
> Thanks,
> sanjeewa.
>
> On Tue, Feb 12, 2019 at 5:11 PM Nuwan Dias  wrote:
>
>> I have created a Git issue for this [1].
>>
>> I believe the pub-sub model is more suitable for this. I've explained the
>> proposed architecture on the Git issue.
>>
>> This capability is only required for the ones who want to propagate token
>> revocations to the microgateways as soon as possible. The tokens (usually)
>> expire in about an hour. Therefore the user group who are interested in
>> this feature are the ones who would typically want the revocations to be
>> propagated sooner than that. And these types of users would most probably
>> demand for a near real time impact. The disadvantage of the pull model is
>> that for the revocations to be notified soon enough, the microgateways will
>> have to keep polling the STS quite frequently, say like once every minute
>> at least. With 100 microgateways, that would mean a considerable amount of
>> load on the STS to deal with. And we now have to worry about the scaling
>> factor of the STS along with the scaling factor of the microgateway. Hence
>> I doubt the polling model is right for this.
>>
>> With web-hooks the problem is that the STS requires an outward connection
>> to each of the microgateways. Imagine having the STS on cloud and the
>> microgateways on-prem. The cloud would not have a physical connection to
>> the on-prem microgateways to revoke tokens.
>>
>> The pub-sub model gives us a decoupled architecture (in terms of
>> scalability) with a near real-time impact, which I think is ideal. For the
>> persistence related issue I think we need to introduce a lightweight
>> persistence layer across the microgateways.
>>
>> [1] - https://github.com/wso2/product-microgateway/issues/298
>>
>> On Sat, Feb 9, 2019 at 9:53 PM Fazlan Nazeem  wrote:
>>
>>> Hi Sanjeewa,
>>>
>>> Irrespective of the method we use to implement this, once we choose a
>>> mechanism, we will not be able to refer to the JWT tokens as
>>> self-contained, isn't it? Because we will have to depend on an external
>>> party to decide the validity of a token.
>>>
>>> AFAIU, I think the pub/sub model and push model has a disadvantage if
>>> the process running the topic(in pub/sub model) or the microgateway(in push
>>> model) restarted(unless we repopulate the topic or the mgw memory on each
>>> restart with JTIs of unexpired revoked tokens).
>>>
>>> With the Pull model, I don't see this issue. the key manager only needs
>>> to store the unexpired revoked token information.
>>>
>>> I also feel that we need to introduce a config to switch on
>>> enabling/disabling this feature so that we can also use the microgateways
>>> in the current mode.
>>>
>>> On Thu, Feb 7, 2019 at 3:58 PM Sanjeewa Malalgoda 
>>> wrote:
>>>
>>>> Hi All,
>>>> I'm initiating this mail thread to discuss more about JWT token
>>>> revocation feature we are planning to implement for API Manager
>>>> micro-gateway. In API Manager micro-gateway we do support both oauth access
>>>> tokens and JWT access tokens. When we use OAuth access tokens we can revoke
>>>> them and make it effect immediately. Since all OAuth tokens geting
>>>> validated with key manager revoked tokens will fail validation. When we use
>>>> JWT token we do token validation within gateway itself without calling key
>>>> manager or external party. Since JWT is self contained one we are basically
>>>> trust its content as long as token not expired and signature valid. Then it
>>>> will be a problem.
>>>>
>>>> So we will need to have some mechanism to propagate revoked token
>>>> details to micro-gateways as well.

Re: [Architecture] [Microgateway] API Manager JWT Token Revocation Feature

[Nuwan Dias]

ion Agility for Digitally Driven Business
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Thanks & Regards,
>
> *Fazlan Nazeem*
> Associate Technical Lead
> WSO2 Inc
> Mobile : +94772338839
> fazl...@wso2.com
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Cookie Based Authentication for Micro-gateway.

[Nuwan Dias]

>>>>log:printError("No authorization header was provided");
>>>>
>>>>setErrorMessageToFilterContext(context,
>>>> API_AUTH_MISSING_CREDENTIALS);
>>>>
>>>>sendErrorResponse(listener, request, untaint context);
>>>>
>>>>return false;
>>>>
>>>>}
>>>>
>>>> Above code segment will do that identification of header type of the
>>>> coming request. Then the validation process will be done at the separate
>>>> file named as* "cookie.bal"*. In this file the extraction of session
>>>> Id and validation of that Id with given value at the server startup will be
>>>> done. For that I have implemented a new function as "*ProcessRequest*"
>>>> which returns a string or an error. If any of the cookies included in
>>>> request is not equal to given Id then the validation process will be
>>>> failed. If it fails, then it throws an error and authnFilter will be
>>>> failed. If any of session Id of a cookie matches with given one then that
>>>> id will be returned to authnFilter for further execution at authnFilter.
>>>>
>>>> public function processRequest(http:Listener listener, http:Request
>>>> request, http:FilterContext context)
>>>>
>>>>returns string|error {
>>>>
>>>>boolean isAuthorized;
>>>>
>>>>//get required cookie as config value
>>>>
>>>>string requiredCookie = config:getAsString(COOKIE_HEADER,
>>>> default = "");
>>>>
>>>>//extraxt cookies from the incoming request
>>>>
>>>>string authHead = request.getHeader(COOKIE_HEADER);
>>>>
>>>>string[] cookies = authHead.trim().split(";");
>>>>
>>>>foreach cookie in cookies{
>>>>
>>>>io:println(cookie);
>>>>
>>>>string[] sessionIds = cookie.trim().split("=");
>>>>
>>>>string sessionId = sessionIds[1];
>>>>
>>>>if (sessionId == requiredCookie){
>>>>
>>>>return sessionId;
>>>>
>>>>}
>>>>
>>>>}
>>>>
>>>>error notFound = {message:"No matched cookie found"};
>>>>
>>>>return notFound;
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> *Chamindu Udakara *
>>>> *Software engineering Intern*
>>>> WSO2  (University of Moratuwa)
>>>> *mobile *: *+94 755285531*  |   *email *:  cudak...@gmail.com
>>>> ___
>>>> 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
>>
>
>
> --
> *Rajith Roshan* | Senior Software Engineer | WSO2 Inc.
> (m) +94-717-064-214 |  (e) raji...@wso2.com 
>
> <https://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Cookie Based Authentication for Micro-gateway.

[Nuwan Dias]

The requirement to implement $subject is to enable client-side web
applications (Javascript driven SPAs) to use OAuth2 APIs easily. When an
SPA uses OAuth2 protected APIs, they are required to present a valid access
token. To do this these Applications need to execute some Javascript on the
client side (we browser) which reads an access token stored in some storage
and adds it as a header to the request initiated from the SPA (browser).

The problem here is that if a token is to be stored in a way that is
accessible by client side Javascript, the token becomes vulnerable to any
type of Javascript that runs on the domain of the particular web
application. Meaning that if the application becomes vulnerable to a cross
site scripting attack (XSS) they run the risk of the token being stolen by
an unintended party. To keep the token safe, it makes sense to store the
token in 'httpOnly' format so that they become inaccessible to Javascript.
This way, the token will be submitted to the API in a cookie and hence the
need for the Gateway to identify the token which it may now receive in the
form of a cookie and no longer as an HTTP header.

On Fri, Jan 4, 2019 at 5:04 PM Chamindu Udakara  wrote:

> Hi All,
>
> My project is to add cookie based authentication for micro-gateway. This
> is the approach that I have come up with. Please review and let me know
> what you think and please be kind enough to suggest your suggestions.
>
> Requirement
>
> Provide authentication for product micro-gateway with cookie based
> authentication which uses session HTTP cookies for authentication.
>
> Suggested Approach
>
> When an user invoke an API with a cookie, micro-gateway has to validate
> that cookie prior to the response. The list of cookies included in the HTTP
> request which use to authenticate, have to be extracted from the request.
> From all extracted cookies,their respective session ID value has to be
> extracted properly.
>
> The Authn filter will check incoming request to micro-gateway and
> determine whether it contains header as "Authorization" or header as
> "Cookie". If header is equals to "Cookie" then the cookie validation
> process will be executed and cookie will be validated. If not it will
> execute as a normal request which contains header as "Authorization". The
> session ID of the required cookie can be provided to server as a direct key
> value pair at the micro-gateway server startup.
>
>
>
>
>
>
> if (request.hasHeader(authHeaderName)) {
>
>authHeader = request.getHeader(authHeaderName);
>
>}else if (request.hasHeader(COOKIE_HEADER)){
>
>//Authentiction with HTTP cookies
>
>CookieBasedAuth cookieBasedAuth = new CookieBasedAuth ();
>
>result = cookieBasedAuth.processRequest(listener, request,
> context);
>
>}else {
>
>log:printError("No authorization header was provided");
>
>setErrorMessageToFilterContext(context,
> API_AUTH_MISSING_CREDENTIALS);
>
>sendErrorResponse(listener, request, untaint context);
>
>return false;
>
>}
>
> Above code segment will do that identification of header type of the
> coming request. Then the validation process will be done at the separate
> file named as* "cookie.bal"*. In this file the extraction of session Id
> and validation of that Id with given value at the server startup will be
> done. For that I have implemented a new function as "*ProcessRequest*"
> which returns a string or an error. If any of the cookies included in
> request is not equal to given Id then the validation process will be
> failed. If it fails, then it throws an error and authnFilter will be
> failed. If any of session Id of a cookie matches with given one then that
> id will be returned to authnFilter for further execution at authnFilter.
>
> public function processRequest(http:Listener listener, http:Request
> request, http:FilterContext context)
>
>returns string|error {
>
>boolean isAuthorized;
>
>//get required cookie as config value
>
>string requiredCookie = config:getAsString(COOKIE_HEADER, default
> = "");
>
>//extraxt cookies from the incoming request
>
>string authHead = request.getHeader(COOKIE_HEADER);
>
>string[] cookies = authHead.trim().split(";");
>
>foreach cookie in cookies{
>
>io:println(cookie);
>
>string[] sessionIds = cookie.trim().split("=");
>
>string sessionId = sessionIds[1];
>
>if (sessionId == re

Re: [Architecture] Auth0 OpenID Connector for IS

[Nuwan Dias]

Hi Nirubikaa,

The image hasn't loaded it seems, could you attach it please?

I'm trying to figure out the problem we're trying to solve with this
solution. Could you briefly explain the use case (problem) as well please?

Thanks,
NuwanD.

On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
wrote:

> Hi all,
> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
> diagram below:
>
>
>
>
> In the flow of OpenID Connect,
>
> User sends a request to service provider, then the request is redirected
> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
> client credentials, and Openid scope. Then the Auth0 redirects to the
> request with Authorization code.
>
> Then WSO2 IS requests Access token, to that Auth0 responses with the
> Access token, An ID token is issued from the token endpoint in addition to
> an Access token.
>
> WSO2 IS requests to get user info, And Auth0 can retrieve user information
> from the ID token or Access token.
>
> Thanks.
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Solution Design : Support for HTTP2 on the Microgateway

[Nuwan Dias]

On Thu, Dec 20, 2018 at 5:10 PM Sanjeewa Malalgoda 
wrote:

> Can you create document explaining this feature in detail with possible
> user scenarios. It would be great if we can have some test artifacts as
> well.
>

+1. Let's create a GDoc and share please.

>
> Thanks,
> sanjeewa.
>
> On Thu, Dec 20, 2018 at 3:38 PM Varuni Punchihewa 
> wrote:
>
>> Hi Sanjeewa,
>>
>> There's no effect to ballerina filters from setting the http version to
>> 2.0. But the connection established via the client and the microgateway and
>> microgateway with the backend would be more efficient and fast due to the
>> features like header compression, it's full multiplexed nature etc.
>> Furthermore, we won't be using the server push feature in the microgateway
>> since there's no much use cases of it with the microgateway.
>>
>> Thank you
>> Best Regards,
>>
>> *Varuni Punchihewa*
>> Intern - Software Engineering | *WSO2*
>> *Tel:* +94 71 699 5861
>> <http://wso2.com/signature>
>>
>>
>> On Fri, Oct 26, 2018 at 12:05 PM Sanjeewa Malalgoda 
>> wrote:
>>
>>> Can you please explain how are we planning to go ahead with this
>>> feature? Even now with ballerina we can create http2 client endpoint or
>>> server endpoint with http2 follows.
>>> If we do same now how will it work with existing filters?
>>>
>>> endpoint http:Listener testEP {
>>> port: 9095,
>>> httpVersion: "2.0"
>>> };
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Sat, Oct 6, 2018 at 5:13 PM Varuni Punchihewa 
>>> wrote:
>>>
>>>> Hi all!
>>>> Please find my project description and the design as below.
>>>>
>>>> *Project description*
>>>>
>>>> The WSO2 API Microgateway currently supports only http and https as the
>>>> incoming and outgoing transport protocols. This project is for enabling it
>>>> to support HTTP2 for both incoming and outgoing message flows. We need to
>>>> evaluate the use of OAuth2.0, and rate limiting capabilities on the current
>>>> Microgateway and see how this impacts the move to HTTP2.
>>>>
>>>> *Solution Design*
>>>>
>>>>- Supporting the messages received by the microgateway from the
>>>>clients, by both HTTP/1.1 and HTTP/2.0 protocols
>>>>- All the communication that happen between the Microgateway and
>>>>the Back end service will support HTTP/2.0 (The maximum version 
>>>> supported
>>>>is set to 2.0. In case if it supports only 1.1, then it will be backward
>>>>compatible to 1.1 and would not be a problem to communications)
>>>>
>>>> Best Regards,
>>>>
>>>> *Varuni Punchihewa*
>>>> Intern - Software Engineering | *WSO2*
>>>>
>>>> *Tel:* +94 71 699 5861
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> *Sanjeewa Malalgoda*
>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>> <https://medium.com/@sanjeewa190>
>>>
>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>> Integration Agility for Digitally Driven Business
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>
> --
> *Sanjeewa Malalgoda*
> Software Architect | Associate Director, Engineering - WSO2 Inc.
> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
> <http://sanjeewamalalgoda.blogspot.com>, Medium
> <https://medium.com/@sanjeewa190>
>
> GET INTEGRATION AGILE <https://wso2.com/signature>
> Integration Agility for Digitally Driven Business
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: Developer-First Microgateway Creation

[Nuwan Dias]

needs to give additional information on the
>>>>>>>>>endpoint (ex: endpoint type), the user can give the path to the 
>>>>>>>>> endpoint
>>>>>>>>>config with the *-ec* or *--endpointConfig *option.
>>>>>>>>>- The user can provide the path to the CORS configuration with
>>>>>>>>>the *-cc* or *--corsConfig *option.
>>>>>>>>>
>>>>>>>>> The following is the basic command to setup a new API in the
>>>>>>>>> Microgateway with this feature implemented.
>>>>>>>>>
>>>>>>>>>> *micro-gw setup test-project -o /path/to/def/apidef.json -e
>>>>>>>>>> http://localhost:9090/hello/sayHello 
>>>>>>>>>> <http://localhost:9090/hello/sayHello>*
>>>>>>>>>
>>>>>>>>>
>>>>>>>> -o is typically used to specify the "output" location so can made a
>>>>>>>> confusion at first glance. Shall we try to use a different flag? (eg : 
>>>>>>>> -oa)
>>>>>>>>
>>>>>>>> Is it possible to override the endpoint configurations you provide
>>>>>>>> by -e or -ec after setting up and building the microgateway? Just 
>>>>>>>> wanted to
>>>>>>>> make sure [1] is supported here too.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://docs.wso2.com/display/AM260/Overriding+Endpoint+Information
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Malintha
>>>>>>>>
>>>>>>>>>
>>>>>>>>> *2. Fetching the Throttling Policies*
>>>>>>>>> We store the most commonly used policies within the
>>>>>>>>> Microgateway distribution and copy these policies to the project when 
>>>>>>>>> the
>>>>>>>>> setup command is executed. If a user needs to add a custom policy, 
>>>>>>>>> the user
>>>>>>>>> can add it to the policy directory in the Microgateway.
>>>>>>>>>
>>>>>>>>> Your comments and suggestions on this feature will be highly
>>>>>>>>> appreciated.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Arshardh
>>>>>>>>> --
>>>>>>>>> *Arshardh Ifthikar*
>>>>>>>>> Software Engineer | WSO2 Inc.
>>>>>>>>>
>>>>>>>>> Email: arsha...@wso2.com
>>>>>>>>> Mobile: +94719806525
>>>>>>>>> Web: http://wso2.com
>>>>>>>>>
>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>> ___
>>>>>>>>> Architecture mailing list
>>>>>>>>> Architecture@wso2.org
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Malintha Amarasinghe
>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>>>> http://wso2.com/
>>>>>>>>
>>>>>>>> Mobile : +94 712383306
>>>>>>>> ___
>>>>>>>> Architecture mailing list
>>>>>>>> Architecture@wso2.org
>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Sanjeewa Malalgoda*
>>>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>>>>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>>>>> <https://medium.com/@sanjeewa190>
>>>>>>>
>>>>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>> ___
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> --
>>>>>> *Joseph Fonseka*
>>>>>> WSO2 Inc.; http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>> mobile: +94 772 512 430
>>>>>> skype: jpfonseka
>>>>>>
>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>
>>>>>> ___
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Sanjeewa Malalgoda*
>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>>> <https://medium.com/@sanjeewa190>
>>>>>
>>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>>> Integration Agility for Digitally Driven Business
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> *Thanks & Regards,*
>>>> *Nuwan Bandara | Director - **Solutions Architecture,  WSO2 Inc.*
>>>> *+1 646 643 8618 | +1 650 745 2169 Ext 4212 | http://nuwanbando.com
>>>> <http://nuwanbando.com> *
>>>> <http://www.nuwanbando.com/>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>>
>>
>> *Thanks & Regards,*
>> *Nuwan Bandara | Director - **Solutions Architecture,  WSO2 Inc.*
>> *+1 646 643 8618 | +1 650 745 2169 Ext 4212 | http://nuwanbando.com
>> <http://nuwanbando.com> *
>> <http://www.nuwanbando.com/>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: Developer-First Microgateway Creation

[Nuwan Dias]

On Fri, Oct 26, 2018 at 2:37 PM Joseph Fonseka  wrote:

>
>
> On Fri, Oct 26, 2018 at 11:58 AM Nuwan Dias  wrote:
>
>>
>>
>> On Fri, 26 Oct 2018 at 11:16 am, Arshardh Ifthikar 
>> wrote:
>>
>>> Hi all,
>>>
>>> The existing Microgateway loads the api via contacting the API Manager
>>> instance that should be up and running. We are developing a feature where
>>> we have given the option to setup the Microgateway without an API Manager
>>> instance running. There are two aspects that the Microgateway uses the API
>>> Manager during setup
>>>
>>>1. Loading the Api Definition
>>>2. Fetching the Throttling Policies
>>>
>>> In order to decouple the the Microgateway from  API Manager, these
>>> aspects needs to be addressed.
>>>
>>> *1. Loading the Api Definition*
>>> This implementation requires the user to enter at least the path of the
>>> open api specification file and the endpoint of that API. If the user needs
>>> additional functionality, they can provide the paths to the endpoint
>>> definition and the CORS configuration json files.
>>>
>>>- The Open API Specification file should be given with the *-o *or
>>>* --open-api *option.
>>>- The endpoint needs to be given with the *-e* or *--endpoint*
>>>option.
>>>- If the user needs to give additional information on the endpoint
>>>(ex: endpoint type), the user can give the path to the endpoint config 
>>> with
>>>the *-ec* or *--endpointConfig *option.
>>>- The user can provide the path to the CORS configuration with the
>>>*-cc* or *--corsConfig *option.
>>>
>>> We do need to introduce a way to provide additional information that we
>> cannot already do with OAS. But that shouldn’t mean that we should do that
>> with a lot of files because that reduces the user experience. So we
>> probably need to find a way to contract this information to one file.
>>
>
> OAS extentions [1] can be used to capture aditional information.
>

The problem is that these are not standard. Since the OAS files are
user-provided data, we cannot rely on those to bear information that our
system requires. So I think its best to stick to the OAS spec only, so that
we can work with any OAS file provided to us from any system without
requiring modifications to it.

>
> Regards
> Jo
>
> [1]
> https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#specification-extensions
>
>
>>
>> The following is the basic command to setup a new API in the
>>> Microgateway with this feature implemented.
>>>
>>>> *micro-gw setup test-project -o /path/to/def/apidef.json -e
>>>> http://localhost:9090/hello/sayHello 
>>>> <http://localhost:9090/hello/sayHello>*
>>>
>>>
>>> *2. Fetching the Throttling Policies*
>>> We store the most commonly used policies within the
>>> Microgateway distribution and copy these policies to the project when the
>>> setup command is executed. If a user needs to add a custom policy, the user
>>> can add it to the policy directory in the Microgateway.
>>>
>>> Your comments and suggestions on this feature will be highly appreciated.
>>>
>>> Thanks,
>>> Arshardh
>>> --
>>> *Arshardh Ifthikar*
>>> Software Engineer | WSO2 Inc.
>>>
>>> Email: arsha...@wso2.com
>>> Mobile: +94719806525
>>> Web: http://wso2.com
>>>
>>> <http://wso2.com/signature>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>> --
>> *Nuwan Dias* | Director | WSO2 Inc.
>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>> [image: Signature.jpg]
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * <http://lk.linkedin.com/in/rumeshbandara>*
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: Developer-First Microgateway Creation

[Nuwan Dias]

On Fri, 26 Oct 2018 at 11:16 am, Arshardh Ifthikar 
wrote:

> Hi all,
>
> The existing Microgateway loads the api via contacting the API Manager
> instance that should be up and running. We are developing a feature where
> we have given the option to setup the Microgateway without an API Manager
> instance running. There are two aspects that the Microgateway uses the API
> Manager during setup
>
>1. Loading the Api Definition
>2. Fetching the Throttling Policies
>
> In order to decouple the the Microgateway from  API Manager, these aspects
> needs to be addressed.
>
> *1. Loading the Api Definition*
> This implementation requires the user to enter at least the path of the
> open api specification file and the endpoint of that API. If the user needs
> additional functionality, they can provide the paths to the endpoint
> definition and the CORS configuration json files.
>
>- The Open API Specification file should be given with the *-o *or
>* --open-api *option.
>- The endpoint needs to be given with the *-e* or *--endpoint* option.
>- If the user needs to give additional information on the endpoint
>(ex: endpoint type), the user can give the path to the endpoint config with
>the *-ec* or *--endpointConfig *option.
>- The user can provide the path to the CORS configuration with the
>*-cc* or *--corsConfig *option.
>
> We do need to introduce a way to provide additional information that we
cannot already do with OAS. But that shouldn’t mean that we should do that
with a lot of files because that reduces the user experience. So we
probably need to find a way to contract this information to one file.

The following is the basic command to setup a new API in the
> Microgateway with this feature implemented.
>
>> *micro-gw setup test-project -o /path/to/def/apidef.json -e
>> http://localhost:9090/hello/sayHello <http://localhost:9090/hello/sayHello>*
>
>
> *2. Fetching the Throttling Policies*
> We store the most commonly used policies within the
> Microgateway distribution and copy these policies to the project when the
> setup command is executed. If a user needs to add a custom policy, the user
> can add it to the policy directory in the Microgateway.
>
> Your comments and suggestions on this feature will be highly appreciated.
>
> Thanks,
> Arshardh
> --
> *Arshardh Ifthikar*
> Software Engineer | WSO2 Inc.
>
> Email: arsha...@wso2.com
> Mobile: +94719806525
> Web: http://wso2.com
>
> <http://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] why wso2 token call return oauth token whereas I configured wso2 to return jwt token

[Nuwan Dias]

Hi Nicolas,

To get a JWT token from the API Manager, the Token Type of the application
you are trying with needs to be set to 'JWT'. This needs to be done from
the API Store UI under the Edit Application section. See the section
"Generate a JWT token and invoke the API" of the document [1] to see what
this looks like.

[1] - https://docs.wso2.com/display/AM260/Microgateway+Quick+Start

Thanks,
NuwanD.

On Wed, Oct 24, 2018 at 3:45 PM Nicolas Maujean <
nicolas.maujean.fra...@gmail.com> wrote:

>
> hi,
>
> Why wso2 token call return oauth token whereas we configured wso2 to
> return jwt token, the following way :
>
>
> https://docs.wso2.com/display/AM170/Passing+Enduser+Attributes+to+the+Backend+Using+JWT
>
> when we call the command, to get the token, we get the following result :
>
> [root@DL-OPEN-INT conf]# curl -k -d "grant_type=client_credentials" \
>
> -H "Authorization: Basic 
> OXpEQWNFaEljOVN5aElwcDFDaFhJRUxRSTFrYTo2dVY4MGQyM2lIYUZjWHZva2c4bUtrTDB1UDhh" 
> \
>  https://10.200.36.22:8243/token
>
> {"access_token":"d4dce5b7-d75d-327c-a5e9-a13ca48782d6","scope":"am_application_scope
> default","token_type":"Bearer","expires_in":3600}[root@DL-OPEN-INT conf]#
>
> here is the api-manager.xml :
>
> 
> 
> true
>
> 
> X-JWT-Assertion
>
> 
> 
> org.wso2.carbon.apimgt.impl.token.DefaultClaimsRetriever
>
> 
> http://wso2.org/claims
>
> 
> NONE
>
> 
> 
> org.wso2.carbon.apimgt.keymgt.token.JWTGenerator
>
> 
> 
> 
>
> 
> 
> 
>
>
> best regards,
>
>
> Nicolas Maujean
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Announce] WSO2 Product Installation Resources Released!!!

[Nuwan Dias]

On Wed, Oct 10, 2018 at 10:22 AM Vimukthi Perera  wrote:

> Hi Nuwan,
>
> On Wed, Oct 10, 2018 at 7:36 AM Nuwan Dias  wrote:
>
>> Hi Vimukthi,
>>
>> Why is it that the API Manager artifacts have a 4 digit versioning and
>> the others have the standard 3 digit versioning?
>>
>> All the producs have the 4 digit versioning. Please see the link. It was
> my mistake that I have added the release tag to the Name in API Manager.
> Extremely sorry.
>

Yup, I missed the tag name and only noticed the label.

>
> Regards,
>
>
>> Thanks,
>> NuwanD.
>>
>> On Wed, Oct 10, 2018 at 1:42 AM Vimukthi Perera 
>> wrote:
>>
>>> WSO2 Installation Experience team is pleased to announce the release of
>>> Ansible, AWS, Docker, Kubernetes, Puppet and Vagrant resources for WSO2
>>> products.
>>> Ansible
>>>
>>> Related artifacts:
>>>
>>>-
>>>
>>>WSO2 API Manager v2.6.0.1 -
>>>https://github.com/wso2/ansible-apim/releases/tag/v2.6.0.1
>>>-
>>>
>>>WSO2 Identity Server v5.7.0 -
>>>https://github.com/wso2/ansible-is/releases/tag/v5.7.0.1
>>>-
>>>
>>>WSO2 Stream Processor v4.3.0 -
>>>https://github.com/wso2/ansible-sp/releases/tag/v4.3.0.1
>>>-
>>>
>>>WSO2 Enterprise Integrator v6.4.0 -
>>>https://github.com/wso2/ansible-ei/releases/tag/v6.4.0.1
>>>
>>>
>>> Issues:
>>>
>>>-
>>>
>>>WSO2 API Manager - https://github.com/wso2/ansible-apim/issues
>>>-
>>>
>>>WSO2 Identity Server - https://github.com/wso2/ansible-is/issues
>>>-
>>>
>>>WSO2 Stream Processor - https://github.com/wso2/ansible-sp/issues
>>>-
>>>
>>>WSO2 Enterprise Integrator -
>>>https://github.com/wso2/ansible-ei/issues
>>>
>>> AWS
>>>
>>> Related artifacts:
>>>
>>>-
>>>
>>>WSO2 API Manager v2.6.0.1 -
>>>https://github.com/wso2/aws-apim/releases/tag/v2.6.0.1
>>>-
>>>
>>>WSO2 Identity Server v5.7.0 -
>>>https://github.com/wso2/aws-is/releases/tag/v5.7.0.1
>>>-
>>>
>>>WSO2 Stream Processor v4.3.0 -
>>>https://github.com/wso2/aws-sp/releases/tag/v4.3.0.1
>>>-
>>>
>>>WSO2 Enterprise Integrator v6.4.0 -
>>>https://github.com/wso2/aws-ei/releases/tag/v6.4.0.1
>>>
>>>
>>> Issues:
>>>
>>>-
>>>
>>>WSO2 API Manager - https://github.com/wso2/aws-apim/issues
>>>-
>>>
>>>WSO2 Identity Server - https://github.com/wso2/aws-is/issues
>>>-
>>>
>>>WSO2 Stream Processor - https://github.com/wso2/aws-sp/issues
>>>-
>>>
>>>WSO2 Enterprise Integrator - https://github.com/wso2/aws-ei/issues
>>>
>>> Docker
>>>
>>> Related artifacts:
>>>
>>>-
>>>
>>>WSO2 API Manager v2.6.0.1 -
>>>https://github.com/wso2/docker-apim/releases/tag/v2.6.0.1
>>>-
>>>
>>>WSO2 Identity Server v5.7.0 -
>>>https://github.com/wso2/docker-is/releases/tag/v5.7.0.1
>>>-
>>>
>>>WSO2 Stream Processor v4.3.0 -
>>>https://github.com/wso2/docker-sp/releases/tag/v4.3.0.1
>>>-
>>>
>>>WSO2 Enterprise Integrator v6.4.0 -
>>>https://github.com/wso2/docker-ei/releases/tag/v6.4.0.1
>>>
>>>
>>> Issues:
>>>
>>>-
>>>
>>>WSO2 API Manager - https://github.com/wso2/docker-apim/issues
>>>-
>>>
>>>WSO2 Identity Server - https://github.com/wso2/docker-is/issues
>>>-
>>>
>>>WSO2 Stream Processor - https://github.com/wso2/docker-sp/issues
>>>-
>>>
>>>WSO2 Enterprise Integrator - https://github.com/wso2/docker-ei/issues
>>>
>>> Kubernetes
>>>
>>> Related artifacts:
>>>
>>>-
>>>
>>>WSO2 API Manager v2.6.0.1 -
>>>https://github.com/wso2/kubernetes-apim/releases/tag/v2.6.0.1
>>>-
>>>
>>>WSO2 Identity Server v5.7.0 -
>>>https://github.com/wso2/kubernetes-is/releases/tag/v5.7.0.1
>>>-
>>>
>>>WSO2 Stream Processor v4.3.0

Re: [Architecture] [Announce] WSO2 Product Installation Resources Released!!!

[Nuwan Dias]

   -
>
>WSO2 API Manager v2.6.0.1 -
>https://github.com/wso2/vagrant-apim/releases/tag/v2.6.0.1
>-
>
>WSO2 Identity Server v5.7.0 -
>https://github.com/wso2/vagrant-is/releases/tag/v5.7.0.1
>-
>
>WSO2 Stream Processor v4.3.0 -
>https://github.com/wso2/vagrant-sp/releases/tag/v4.3.0.1
>-
>
>WSO2 Enterprise Integrator v6.4.0 -
>https://github.com/wso2/vagrant-ei/releases/tag/v6.4.0.1
>
>
> Issues:
>
>-
>
>WSO2 API Manager - https://github.com/wso2/vagrant-apim/issues
>-
>
>WSO2 Identity Server - https://github.com/wso2/vagrant-is/issues
>-
>
>WSO2 Stream Processor - https://github.com/wso2/vagrant-sp/issues
>-
>
>WSO2 Enterprise Integrator - https://github.com/wso2/vagrant-ei/issues
>
>
> How You Can Contribute
>
> Join our mailing list and correspond with the developers directly.
>
> Developer List: d...@wso2.org
>
> User List: u...@wso2.org
>
> Reporting Issues
>
> We encourage you to report issues and documentation faults regarding WSO2 
> Ansible,
> AWS, Docker, Kubernetes, Puppet and Vagrant resource through respective
> repositories by creating issues.
>
> Thank you!
>
> WSO2 Installation Experience Team
>
> Vimukthi Perera
> Software Engineer
> WSO2 Inc.
>
> Mobile: +94771153999
> Blog: https://medium.com/@vimukthiperera
> Web: http://wso2.com
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Project 240: Communication channel between API Providers and API Consumers

[Nuwan Dias]

The CREATED_BY and UPDATED_BY columns are ones we add to all tables for
audit purposes. We don't associate them with any business logic nor do we
reason out any logic for having or not having those columns.

On Tue, Oct 2, 2018 at 10:02 AM Wasura Wattearachchi 
wrote:

> Hi Ishara,
>
> Thank you for pointing this out.
>
> On Tue, Oct 2, 2018 at 5:42 AM Ishara Cooray  wrote:
>
>> Hi Wasura,
>>
>> I think PARENT_COMMENT_ID should have a default value because first
>> comment does not have a associated parent comment.
>>
>> When we are inserting a parent comment it will not have a
> PARENT_COMMENT_ID. So this may throw an error due to violation of
> Referential Integrity Constraint. So I thought not to have any constraint
> for PARENT_COMMENT_ID and we discussed this yesterday during the code
> review.
>
>
>> Since there are two fields CREATED_BY and UPDATED_BY I guess comments
>> can be updated(edit/delete) by someone other than the owner.
>>
>
> +1 for this. I must handle this in the logic when updating a comment. I
> will look into this matter.
>
>> Appreciate if you clarify the expected behavior.
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>>
>
> Thank you!
>
>>
>> On Mon, Oct 1, 2018 at 10:54 PM Wasura Wattearachchi 
>> wrote:
>>
>>> Hi all,
>>>
>>> According to what we have discussed today during the code review, I
>>> added a new attribute named ENTRY_POINT to distinguish the role of the
>>> person, based on the entry point - whether the particular person initiates
>>> the comment from the API Store or the API Publisher. Following is the ERD
>>> for that (You can find the newly added attribute in green colour).
>>>
>>>
>>>
>>>
>>> Following is the corresponding *table* and the data types.
>>>
>>>
>>> AM_API_COMMENTS
>>>
>>> UUID
>>>
>>> VARCHAR(255)
>>>
>>> PRIMARY KEY
>>>
>>> COMMENT_TEXT
>>>
>>> TEXT
>>>
>>> USER_IDENTIFIER
>>>
>>> VARCHAR(255)
>>>
>>> CATEGORY
>>>
>>> VARCHAR(20)
>>>
>>> DEFAULT ‘General’
>>>
>>> PARENT_COMMENT_ID
>>>
>>> VARCHAR(255)
>>>
>>> ENTRY_POINT
>>>
>>> VARCHAR(20)
>>>
>>> API_ID
>>>
>>> VARCHAR(255)
>>>
>>> FOREIGN KEY REFERENCES AM_API (UUID) ON DELETE CASCADE ON UPDATE CASCADE
>>>
>>> CREATED_BY
>>>
>>> VARCHAR(100)
>>>
>>> CREATED_TIME
>>>
>>> TIMESTAMP
>>>
>>> DEFAULT CURRENT_TIMESTAMP
>>>
>>> UPDATED_BY
>>>
>>> VARCHAR(100)
>>>
>>> UPDATED_TIME
>>>
>>> TIMESTAMP
>>>
>>> DEFAULT CURRENT_TIMESTAMP
>>>
>>>
>>> I would much appreciate if you can provide feedback and suggestions.
>>>
>>>
>>> Thank you!
>>>
>>>
>>> On Wed, Sep 19, 2018 at 10:24 AM Ishara Cooray  wrote:
>>>
>>>> Hi,
>>>>
>>>> Thanks for the clarification Wasura.
>>>>
>>>> In C5 we have used *USER_IDENTIFIER* in below APIM tables.
>>>> AM_USER_NAME_MAPPING
>>>> AM_API_RATINGS
>>>> AM_API_COMMENTS
>>>>
>>>> But in C5 UM tables we still have used *USER_ID*.
>>>>
>>>> AUTH_UM_PASSWORD_INFO
>>>> AUTH_UM_USER_GROUP
>>>> AUTH_UM_USER_ATTRIBUTES
>>>>
>>>> Is there any particular reason for that?
>>>>
>>>> I am +1 to use USER_ID in apim tables as well.
>>>>
>>>>
>>>> Thanks & Regards,
>>>> Ishara Cooray
>>>> Senior Software Engineer
>>>> Mobile : +9477 262 9512
>>>> WSO2, Inc. | http://wso2.com/
>>>> Lean . Enterprise . Middleware
>>>>
>>>> On Tue, Sep 18, 2018 at 9:17 PM, Wasura Wattearachchi 
>>>> wrote:
>>>>
>>>>> Hi Ishara,
>>>>>
>>>>> I agree with you. It is better to have USER_ID rather than
>>>>> USER_IDENTIFIER. But there is a problem. I checked all the tables in
>>>>> the database again and found that there are some tables which have
>>>>> USER_IDENTIFIER column (which is used to symbolize the username of the
>>>>> current user like in AM_API_COMMENTS table).
>>>>

Re: [Architecture] Solution Design : Support for HTTP2 on the Microgateway

[Nuwan Dias]

Hi Varuni,

I think in the first phase we have to build the http2 to http scenario.
Basically if a back-end service is offering an http service, we can create
an http2 receiving API on the microgateway. This way we build a mechanism
of providing http2 support on a http service.

Thanks,
NuwanD.

On Mon, Sep 24, 2018 at 3:33 PM Varuni Punchihewa  wrote:

> Hi all!
> Please find my project description and the design as below.
>
> *Project description*
>
> The WSO2 API Microgateway currently supports only http and https as the
> incoming and outgoing transport protocols. This project is for enabling it
> to support HTTP2 for both incoming and outgoing message flows. We need to
> evaluate the use of OAuth2.0, and rate limiting capabilities on the current
> Microgateway and see how this impacts the move to HTTP2.
>
> *Solution Design*
>
>- Forwarding the messages received by the microgateway from the
>clients, over HTTP/1.1 protocol to HTTP/2.0 protocol
>- When it comes to the transport layer between the microgateway and
>the back-end service, give an option to select http1 or http2 (in the
>command line), in order to use the server push promises facility offered by
>http2, if the back-end supports http2. If it does not, then it will be
>using the http1 protocol.
>- If the back-end supports http2, then the Microgateway will fetch all
>the promises received from the back-end (it will check whether there's any
>promises via hasPromise() first), construct the requested resource, and
>send it to the Client.
>
>
>
> Best Regards,
>
> *Varuni Punchihewa*
> Intern - Software Engineering | *WSO2*
>
> *Tel:* +94 71 699 5861
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Migration approach for APIM 2.6.0 to 3.0.0

[Nuwan Dias]

gn reviews within team and below doc [1] contains the
>>>> overall design of migration process. And each operation executed at API
>>>> export/import process (for migration) is detailed under Section 7 (*Using
>>>> the Import Export CLI tool for migration - User Steps and Steps executed in
>>>> each command*).
>>>>
>>>> Appreciate any comments and suggestions.
>>>>
>>>> Meanwhile I have worked on changing required REST APIs for this
>>>> migration process and are almost done. API/App export related operations
>>>> from CLI tool is done upto an extent allowing to be finalized based on
>>>> finalized design.
>>>>
>>>> [1]
>>>> https://docs.google.com/document/d/1N8ZXPf1-dKpYf09w7AZ9M6RHXnsU2Orht37N1yETbnE/edit?usp=sharing
>>>>
>>>> Regards,
>>>> Samitha
>>>>
>>>> On Wed, Aug 1, 2018 at 10:31 AM Samitha Chathuranga 
>>>> wrote:
>>>>
>>>>> Hi Nuwan,
>>>>>
>>>>> One main reason is that, if we follow approach 1, migration story
>>>>> cannot be done in single step. Specially two CLI tools will have to
>>>>> be used for the two sub steps of exporting and importing.
>>>>>
>>>>> And also normal API/Application export flow will change as major
>>>>> modifications will be required for certain aspects. i.e.
>>>>>
>>>>>- bulk export/import
>>>>>- correlate the difference in the format of archives supported by
>>>>>2.6 vs 3.0
>>>>>- exporting and importing additional artifacts such as throttle
>>>>>policies, access tokens, user role permissions
>>>>>
>>>>> Importing the 2.6 format API/Applications to 3.0 would require
>>>>> completely new effort too. So anyway we will have to change the 3.0 import
>>>>> tool highly.
>>>>>
>>>>> And my perception is that normal import export and migration oriented
>>>>> export-import are tow separate tasks and thought it is better to isolate
>>>>> the two objectives. (as similarly we do in earlier versions). We will also
>>>>> have to think about specific permissions required for the migration
>>>>> oriented export-import in same tool.
>>>>>
>>>>> Eventhough we may go with Approach 2, we can reuse the same code bases
>>>>> when possible.
>>>>>
>>>>> But anyway it is a matter of decision, whether we manage the normal
>>>>> import/export and migration-oriented-import/export separately. Approach 1
>>>>> would result with some higher level of import/export while in approach 2,
>>>>> we could highlight it as a migration.
>>>>>
>>>>> Regards,
>>>>> Samitha
>>>>>
>>>>> On Tue, Jul 31, 2018 at 11:08 PM, Nuwan Dias  wrote:
>>>>>
>>>>>> I would rather go with approach 1. In approach 2 you are suggesting
>>>>>> to develop a separate web app and a separate tool, why do you think it is
>>>>>> better than enhancing the current App and CLI? Its obviously going to be 
>>>>>> a
>>>>>> lot more work than approach 1, plus at the end of the day we will throw
>>>>>> away one of those tools because we don't need two tools doing the same
>>>>>> thing.
>>>>>>
>>>>>> On Tue, Jul 31, 2018 at 10:10 PM Samitha Chathuranga <
>>>>>> sami...@wso2.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This is regarding the initial design on possible approaches to
>>>>>>>> proceed with upgrading APIM 2.6.0(to be released) to 3.0.0. The 
>>>>>>>> migration
>>>>>>>> process has been already decided to implement through an export/import
>>>>>>>> approach as a database migration approach won't be realistic as for 
>>>>>>>> older
>>>>>>>> versions. So the simple generic approach is that each artifact 
>>>>>>>> specially
>>>>>>>> APIs and Applications would be exported from 2.6.0 environment and then
>>>>>>>> will be imported in to 3.0.0 environment.
>>>>>>>>

Re: [Architecture] Dev][VOTE] Release of WSO2 API Manager 2.6.0 RC3

[Nuwan Dias]

Tested the following.

Basic API creation by creator role
Publishing by publisher role
User sign up
Creation and invocation of SOAP APIs
Microgateway VM mode
Microgateway docker mode

[+] Stable - go ahead and release

Thanks,
NuwanD.

On Sat, Sep 15, 2018 at 10:34 AM Chamila Adhikarinayake 
wrote:

> Microgateway RC3 can be found in
> https://github.com/wso2/product-microgateway/releases/tag/v2.6.0-rc3
>
> Thanks
> Chamila
>
> On Sat, Sep 15, 2018 at 7:04 AM, Chamila Adhikarinayake  > wrote:
>
>> Hi All,
>>
>> We are pleased to announce the third release candidate of WSO2 API
>> Manager 2.6.0.
>>
>> This release fixes the following issues.
>>
>> Fixes : carbon-apimgt
>> <https://github.com/wso2/carbon-apimgt/issues?utf8=%E2%9C%93=is%3Aclosed+closed%3A2018-07-16..2018-09-15+-label%3A%22APIM+3.0.0%22>
>> Fixes : product-apim
>> <https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aclosed+closed%3A2018-07-16..2018-09-15+-label%3A%223.0.0%22>
>> Fixes : analytics-apim
>> <https://github.com/wso2/analytics-apim/issues?utf8=%E2%9C%93=is%3Aclosed+closed%3A2018-07-16..2018-09-15>
>> Fixes : product-microgateway
>> <https://github.com/wso2/product-microgateway/issues?utf8=%E2%9C%93=is%3Aclosed+closed%3A2018-07-16..2018-09-15>
>>
>> Source and Distribution,
>>- Runtime :
>> https://github.com/wso2/product-apim/releases/tag/v2.6.0-rc3
>>- Analytics :
>> https://github.com/wso2/analytics-apim/releases/tag/v2.6.0-rc3
>>- Tooling :
>> https://github.com/wso2/devstudio-tooling-apim/releases/tag/v2.6.0-rc1
>>- Microgateway :
>> https://github.com/wso2/product-microgateway/releases/tag/v2.6.0-rc2
>>
>> Please download, test the product and vote.
>>
>>   [+] Stable - go ahead and release
>>   [-] Broken - do not release (explain why)
>>
>> Thanks,
>> ~ WSO2 API Manager Team ~
>>
>>
>> --
>> Regards,
>> Chamila Adhikarinayake
>> Associate Technical Lead
>> WSO2, Inc.
>> Mobile - +94712346437
>> Email  - chami...@wso2.com
>> Blog  -  http://helpfromadhi.blogspot.com/
>>
>
>
>
> --
> Regards,
> Chamila Adhikarinayake
> Associate Technical Lead
> WSO2, Inc.
> Mobile - +94712346437
> Email  - chami...@wso2.com
> Blog  -  http://helpfromadhi.blogspot.com/
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Project 240: Communication channel between API Providers and API Consumers

[Nuwan Dias]

>> i have to tell other publishers. And what other publishers can comment
>>>> about my API. Its subscribers who use your APIs and they are the ones who
>>>> should initiate or read comments.
>>>>
>>>
>>> The reason for doing this is to cater colaborative development of APIs.
>>> In such cases, there should be a place for API developers to discuss and
>>> share their thoughts. We thought of developing a seperate UI for this. Also
>>> this will not be implemented for the immediate release. So we don't have to
>>> decide this at this point.
>>>
>> +1. That makes sense.
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>>
>>>>
>>>> Thanks,
>>>> sanjeewa.
>>>>
>>>>>
>>>>> For further clarifications, you can go through the document which I
>>>>> have attached below. It will be hugely appreciated if you can provide your
>>>>> feedback.
>>>>>
>>>>>
>>>>> Until then I will analyze API Manager 3.0 more and will start writing
>>>>> User Stories.
>>>>>
>>>>>
>>>>> Thank you!
>>>>> --
>>>>> Wasura Wattearachchi
>>>>> Software Engineer Intern | WSO2
>>>>>
>>>>> Email: was...@wso2.com 
>>>>> Mobile: +94775396038
>>>>>
>>>>
>>>>
>>>> --
>>>> *Sanjeewa Malalgoda*
>>>> WSO2 Inc.
>>>> Mobile : +94 712933253
>>>>
>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>
>>>>
>>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Technical Lead,*
>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>
>>> *Phone: +94715478185*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> <http://www.linkedin.com/in/bhathiyaj>*
>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
>>> *Blog: http://movingaheadblog.blogspot.com
>>> <http://movingaheadblog.blogspot.com/>*
>>>
>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94 712933253
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>
> --
> Wasura Wattearachchi
> Software Engineer Intern | WSO2
>
> Email: was...@wso2.com 
> Mobile: +94775396038
>


-- 
Nuwan Dias

Director - 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] [IS] Printing Correlation ID on every Request on the logs.

[Nuwan Dias]

How does this particular feature differ from the Message Tracing feature
that is already available in Carbon? Please see blog [1]. Also doesn't IS
call out to any services in any case?

How do we make sure that we can trace the message from APIM for example?

[1] -
https://dinushasblog.blogspot.com/2013/12/message-tracing-with-wso2-api-manager.html

On Wed, Sep 5, 2018 at 10:12 AM Dulanja Liyanage  wrote:

>
>
> On Wed, Sep 5, 2018 at 9:45 AM, Ruwan Linton  wrote:
>
>> +1 for the idea in general, what we need to do is to insert this ID as a
>> MDC value and configure the logging appender pattern to include that ID
>> into the logs printed into the file/console.
>>
>> We are already working on something similar to this for tracing
>> transactions across the products, for that we are using a correlation id
>> (transaction id) between products.
>>
>> This effort has to work seamlessly with that too, in the case of a
>> request that will be initiated by APIM, there will be a correlation id
>> coming in, in the request (as a HTTP header) so the ID generation logic
>> should look at this header, and generate a new ID only if that is not
>> available.
>>
>
> +1. Yes, a new ID should be generated only if an existing one is not
> available.
>
>>
>> Thanks,
>> Ruwan
>>
>> On Tue, Sep 4, 2018 at 6:38 PM Dulanja Liyanage  wrote:
>>
>>> How can we map a particular request between the wso2carbon.log and the
>>> HTTP access log?
>>>
>>> IMO, we should generate this Correlation ID from a custom valve and add
>>> that as a request attribute, and then extend the Access Log valve to print
>>> that ID in the HTTP Access Log as well. (I haven't tried this, but I
>>> believe this approach is feasible)
>>>
>>> Also, by doing this way you don't have to individually add the filter to
>>> each webapp in the product, because valves get engaged for all the contexts.
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> Dulanja
>>>
>>> On Mon, Aug 20, 2018 at 4:53 PM, Thumilan Mikunthan 
>>> wrote:
>>>
>>>> Hi All,
>>>> *Problem*
>>>>
>>>> Whenever an error occurred, analyzing error log line could not give
>>>> enough information to diagnose the error. A mechanism to track each request
>>>> flow  is helpful to diagnose.
>>>>
>>>> *Solution*
>>>> Assign unique id to each request and track it down through log files.
>>>>
>>>>-
>>>>
>>>>Use a Request filter to filter all requests which come to WSO2 IS.
>>>>-
>>>>
>>>>Assign a unique id for each request.
>>>>-
>>>>
>>>>Print the unique id along with log lines in order to diagnose
>>>>errors.
>>>>
>>>> *Solution Diagram*
>>>> [image: UUID Archi.jpg]
>>>>
>>>>
>>>> *Sample Scenario*
>>>> [1] - Sample Scenario (Correlation ID-sample.jpg)
>>>> We can easily understand that above error occurred because of illegal
>>>> access by tracking the unique id.
>>>>
>>>> Please give feedback regarding this architecture.
>>>>
>>>> Best Regards,
>>>> M.Thumilan
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Dulanja Liyanage
>>> Lead, Platform Security Team
>>> WSO2 Inc.
>>>
>>
>>
>> --
>> Ruwan Linton
>> Director - Delivery, WSO2; https://wso2.com
>> Member, Apache Software Foundation; http://www.apache.org
>> <http://adroitlogic.org/>
>>
>> email: ru...@wso2.com; cell: +94 77 341 3097; phone: +94 11 2833 436
>> linkedin: http://www.linkedin.com/in/ruwanlinton
>>
>
>
>
> --
> Thanks & Regards,
> Dulanja Liyanage
> Lead, Platform Security Team
> WSO2 Inc.
>


-- 
Nuwan Dias

Director - 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] Updating 5 star rating to 10 star rating

[Nuwan Dias]

On Tue, Sep 4, 2018 at 9:44 PM Chanaka Jayasena  wrote:

> Hi,
>
> I am updating API rating from 5 star rating to 10 star rating base on the
> set of usability improvements we are planning for store.
>

When migrating from API Manager 2 to 3, this would mean that we have to
multiply the rating value from 2 to fit into the 10 start rating scale.

>
> I am also updating the Rest API to support the same.
>
> Get operation of rating API is returning the following object format.
>
>1. avgRating:"4"
>2. count:1
>3. list:[{…}]
>4. userRating:"4"
>
> Put operation to the Rating api returns the following.
>
>1. rating: 5
>2. ratingId:"5f31ff42-1bc0-4295-8123-189dd34499dc"
>3. username:"admin"
>
> Returning the userRating along with the response of the PUT operation will
> remove the need for a second call to get the average rating to update the
> UI.
>
> Will it break the RESTFull ness of the API, if I do this change?
>

I don't think so. If the GET operation returns the userRating I guess its
fine for the PUT operation to return it too.

Why are the responses of the GET and PUT operations very different? Ex:
count, list are missing in PUT, ratingId is missing in GET.

>
> thanks,
> Chanaka
> --
> Chanaka Jayasena
> Associate Tech Lead,
> email: chan...@wso2.com; cell: +94 77 4464006
> blog: http://chanaka3d.blogspot.com
>


-- 
Nuwan Dias

Director - 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] [APIM][300][Store] Feature to change password of an user

[Nuwan Dias]

I don't think we should decide the priority of the feature based on how
easy it is to implement. The priority should be decided based on its
importance. To me, someone forgetting a password is far more likely than
someone wanting to change it. So I would consider 'Forgot Password' as a
must have feature and 'Change Password' as a good to have one.

The other reason this thread made me think about the 'Forgot Password'
feature is that if we implement that feature, we can address the change
password capability through the same feature. We don't have to implement
two features to address the two use cases. So, two birds with one stone.
Less code, less bugs and less work.

On Tue, Aug 21, 2018 at 1:34 AM Ishara Cooray  wrote:

> +1 to implement change password feature first as it is simpler than forgot
> password feature which involves user verification.
> Also for the forgot password feature we can either send an email with a
> temporary password or redirect to the change password.
> Even if we send a temporary password we will need to ask to change the
> password.
>
> Hi Vithursa,
>
> I would suggest having another required property call *retypeNewPassword *for
> new password verification.
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Mon, Aug 20, 2018 at 5:08 PM, roshan wijesena 
> wrote:
>
>> Do we have any send an email to user feature in apim 3 road map ?
>>
>> On Mon, Aug 20, 2018 at 7:56 PM Sanjeewa Malalgoda 
>> wrote:
>>
>>> Forgot password feature should comes with some sort of user
>>> verification(enter security question or send email verification, sms
>>> verification etc).
>>> That feature need to implement with some extensions as all are not using
>>> same verification process.
>>> So i think we can first complete this and come back to that feature.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>> On Mon, Aug 20, 2018 at 11:42 AM Mushthaq Rumy 
>>> wrote:
>>>
>>>> +1. I too think that forgot password option is more important and it is
>>>> not yet implemented. I would prefer if we start on that first.
>>>>
>>>> Thanks & Regards,
>>>> Mushthaq
>>>>
>>>> On Mon, Aug 20, 2018 at 11:40 AM Nuwan Dias  wrote:
>>>>
>>>>> Do we have a forgot password option on the Store? I would think that
>>>>> is more important for an API Store than a change password functionality.
>>>>>
>>>>> On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah <
>>>>> vithu...@wso2.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>> I am working on $subject in APIM 3.0.0. Planned flow of
>>>>>> implementation is as follows:
>>>>>>
>>>>>> [image: new_password_mail.png]
>>>>>> We have SCIM API [1] for updating user-info. A separate REST API can
>>>>>> be implemented to provide the feature to change password by wrapping
>>>>>> mentioned SCIM API. The sample resource could be as,
>>>>>>
>>>>>> PasswordChangeRequest:
>>>>>> title: Request for changing password
>>>>>> required:
>>>>>>   - username
>>>>>>   - currentPassword
>>>>>>   - newPassword
>>>>>> properties:
>>>>>>   username:
>>>>>> type: string
>>>>>>   currentPassword:
>>>>>> type: string
>>>>>>   newPassword:
>>>>>> type: string
>>>>>>
>>>>>> Please provide your thoughts and feedback on this.
>>>>>>
>>>>>> Thanks,
>>>>>> Vithursa
>>>>>> --
>>>>>> Vithursa Mahendrarajah
>>>>>> Software Engineer
>>>>>> WSO2 Inc. - http ://wso2.com
>>>>>> Mobile  : +947*66695643*
>>>>>>
>>>>>>
>>>>>> * <http://wso2.com/signature> <http://wso2.com/signature>
>>>>>> <http://wso2.com/signature>*
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nuwan Dias
>>>>>
>>>>> Director - WSO2, Inc. http://wso2.com
>>>>> email : nuw...@wso2.com
>&

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

[Nuwan Dias]

Do we have a forgot password option on the Store? I would think that is
more important for an API Store than a change password functionality.

On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah 
wrote:

> Hi all,
> I am working on $subject in APIM 3.0.0. Planned flow of implementation is
> as follows:
>
> [image: new_password_mail.png]
> We have SCIM API [1] for updating user-info. A separate REST API can be
> implemented to provide the feature to change password by wrapping mentioned
> SCIM API. The sample resource could be as,
>
> PasswordChangeRequest:
> title: Request for changing password
> required:
>   - username
>   - currentPassword
>   - newPassword
> properties:
>   username:
> type: string
>   currentPassword:
> type: string
>   newPassword:
> type: string
>
> Please provide your thoughts and feedback on this.
>
> Thanks,
> Vithursa
> --
> Vithursa Mahendrarajah
> Software Engineer
> WSO2 Inc. - http ://wso2.com
> Mobile  : +947*66695643*
>
>
> * <http://wso2.com/signature> <http://wso2.com/signature>
> <http://wso2.com/signature>*
>


-- 
Nuwan Dias

Director - 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] Design First APIs on APIM v3.0

[Nuwan Dias]

Hi Roshan,

Both options you mentioned are available. (1) is actually available even
today and (2) is something we are working on. I'm actually referring to a
3rd option which is where a user starts implementing an API on API Manager
using a Design First approach. In here the user first starts the
development by using our UIs to create the interface and then wants to take
control of the request and response message flows.

Thanks,
NuwanD.

On Thu, Aug 16, 2018 at 10:18 AM Uvindra Dias Jayasinha 
wrote:

> +1 for the approach suggested by NuwanD, this gives us a best of both
> worlds scenario separating user code from generated code.
>
> I believe we can even handle Roshan's requirement for non technical users
> in this way. Uploading Ballerina functions that will be associated with a
> given resource can be an optional step(For injecting custom API logic). By
> default an API will simply act as a pass through API proxy for the endpoint
> that it is fronting. This allows non technical users to define API proxies
> for their existing APIs without writing any code. For all other
> scenarios(mediation, transformation, implementing the API on the Ballerina
> gateway itself, etc.) you will need to get your hands dirty.
>
>
> On 15 August 2018 at 20:12, Nuwan Dias  wrote:
>
>> Hi,
>>
>> This is regarding the implementation of APIs on API Manager v3.0 using a
>> Design First Approach. The API Publisher Portal of API Manager will have
>> the UI constructs required to design the interface of the API including the
>> resource paths, verbs, base paths, etc. This version of API Manager uses
>> Ballerina as its API implementation language. When it comes to implementing
>> the API logic, our plan was to allow users to edit the full Ballerina
>> source of the corresponding API. The sequence of actions in performing this
>> operation would be as follows.
>>
>> 1. User creates API definition (interface) using UI.
>> 2. Server code gens the Ballerina source corresponding to the above
>> definition.
>> 3. User edits the Ballerina source of the corresponding resources.
>>
>> Since this leads to a situation where the user edits an auto generated
>> code and re-auto generation leads to complications related to merging auto
>> generated code with user written code, this has led to rethinking how to
>> want to enable implementation of APIs from the API publisher.
>>
>> An alternative approach is to let the user implement Ballerina functions
>> offline and upload them to the API Manager. These functions should be
>> written according to a function template (signature). They can then be
>> linked to a particular resource. A function each can be linked for
>> processing the request and for processing the response. This is similar to
>> the model that we have today of uploading sequences for a given API, but
>> more powerful in terms of capability due to how the Gateway engine behaves
>> (Synapse vs Ballerina). This way a user does not edit auto generated code.
>> The code gen process would link the auto generated code with the user
>> uploaded code and create a consolidated Ballerina source to be deployed on
>> the Gateways.
>>
>> Another advantage here is that this model does not require us to have a
>> web based Ballerina editor. Users defining functions could use any editor
>> supported by Ballerina offline.
>>
>> I am opening up this idea for thoughts and suggestions.
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> Nuwan Dias
>>
>> Director - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Nuwan Dias

Director - 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

[Architecture] Design First APIs on APIM v3.0

[Nuwan Dias]

Hi,

This is regarding the implementation of APIs on API Manager v3.0 using a
Design First Approach. The API Publisher Portal of API Manager will have
the UI constructs required to design the interface of the API including the
resource paths, verbs, base paths, etc. This version of API Manager uses
Ballerina as its API implementation language. When it comes to implementing
the API logic, our plan was to allow users to edit the full Ballerina
source of the corresponding API. The sequence of actions in performing this
operation would be as follows.

1. User creates API definition (interface) using UI.
2. Server code gens the Ballerina source corresponding to the above
definition.
3. User edits the Ballerina source of the corresponding resources.

Since this leads to a situation where the user edits an auto generated code
and re-auto generation leads to complications related to merging auto
generated code with user written code, this has led to rethinking how to
want to enable implementation of APIs from the API publisher.

An alternative approach is to let the user implement Ballerina functions
offline and upload them to the API Manager. These functions should be
written according to a function template (signature). They can then be
linked to a particular resource. A function each can be linked for
processing the request and for processing the response. This is similar to
the model that we have today of uploading sequences for a given API, but
more powerful in terms of capability due to how the Gateway engine behaves
(Synapse vs Ballerina). This way a user does not edit auto generated code.
The code gen process would link the auto generated code with the user
uploaded code and create a consolidated Ballerina source to be deployed on
the Gateways.

Another advantage here is that this model does not require us to have a web
based Ballerina editor. Users defining functions could use any editor
supported by Ballerina offline.

I am opening up this idea for thoughts and suggestions.

Thanks,
NuwanD.

-- 
Nuwan Dias

Director - 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] Migration approach for APIM 2.6.0 to 3.0.0

[Nuwan Dias]

I would rather go with approach 1. In approach 2 you are suggesting to
develop a separate web app and a separate tool, why do you think it is
better than enhancing the current App and CLI? Its obviously going to be a
lot more work than approach 1, plus at the end of the day we will throw
away one of those tools because we don't need two tools doing the same
thing.

On Tue, Jul 31, 2018 at 10:10 PM Samitha Chathuranga 
wrote:

>
> Hi all,
>>
>> This is regarding the initial design on possible approaches to proceed
>> with upgrading APIM 2.6.0(to be released) to 3.0.0. The migration process
>> has been already decided to implement through an export/import approach as
>> a database migration approach won't be realistic as for older versions. So
>> the simple generic approach is that each artifact specially APIs and
>> Applications would be exported from 2.6.0 environment and then will be
>> imported in to 3.0.0 environment.
>>
>> Below I have listed the possible two approaches for both these two steps
>> (importing & exporting) followed by their pros and cons.
>>
>> Exporting :
>>
>> Approach 1 : Change currently existing Api Import/export web app and CLI
>> tool in 2.6
>>
>>
>>
>>-
>>
>>Can use API Import/export Web app and CLI tool and modify
>>-
>>
>>   (REST APIs for export api/applications is currently provided via
>>   this WEB app. CLI tool uses this web app)
>>   -
>>
>>Required changes:
>>-
>>
>>   For app export: Consumer key, Consumer Secret, Token exporting
>>   should be supported in CLI tool
>>   -
>>
>>   Will have to change admin REST api implementation for above task
>>   and for exporting other artifacts mentioned at the end.
>>   -
>>
>>   Modify CLI tool to support exporting in bulk.
>>
>>
>>
>>-
>>
>>Pros
>>-
>>
>>   Will not have to develop/maintain a Web app and CLI tool from the
>>   scratch
>>   -
>>
>>Cons
>>-
>>
>>   API export flow will change as modifications will be required
>>   -
>>
>>   Have to manage and consider also about normal export feature when
>>   doing changes for migration-exporting.
>>   -
>>
>>   Migration story cannot be done in single step. Exporting and
>>   importing will be 2 step process.
>>
>>
>>
>> Approach 2 : Develop a separate tool without using API Import/export Web
>> app or CLI tool.
>>
>>
>>-
>>
>>Create a WEB App introducing new REST APIs required and develop
>>separate CLI tool.
>>
>>
>>
>>-
>>
>>Pros
>>-
>>
>>   Migration story can be done in single step. (Exporting and
>>   importing can be done in single command.)
>>   -
>>
>>   API/Application import-export tool won’t have any effect or change.
>>   -
>>
>>   Don’t have to manage 2 separate use cases in single tool.
>>   -
>>
>>Cons
>>-
>>
>>   Will have to develop/maintain a Web app and/or CLI tool from the
>>   scratch
>>
>>
>>
>> Importing :
>>
>>
>>-
>>
>>Has to create separate REST APIs for importing 2.6-exported
>>APIs/Applications/other artifacts as 3.0.0 expecting archives in 3.0
>>specific format.
>>
>>
>> Approach 1
>>
>>-
>>
>>Change/improve API Import/export CLI tool in 3.0 to support importing
>>2.6-exported API/application archives.
>>
>> Approach 2
>>
>>-
>>
>>Develop separate CLI tool from the scratch which will be used for
>>exporting from 2.6 also
>>
>>
>>
>> Other artifacts required to be exported/imported (other than
>> APIs/Applications)
>>
>>
>>-
>>
>>Throttling Policies
>>-
>>
>>Custom API Lifecycles
>>-
>>
>>Workflows
>>-
>>
>>User Role Permissions
>>-
>>
>>Custom sequences (at least for reference -> has to decide regarding
>>this)
>>
>>
>>
>> My perception is that proceeding with Approach 2 under both exporting and
>> importing would be better considering the pros and cons of each.
>>
>> Highly appreciate your thoughts on this.
>>
>> Regards,
>>
>> Samitha
>>
>>
>> --
>> *Samitha Chathuranga*
>> *Senior Software Engineer*, *WSO2 Inc.*
>> lean.enterprise.middleware
>> Mobile: +94715123761
>>
>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>
>
>
>

-- 
Nuwan Dias

Director - 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] Old access token cleanup when token generating, renewing and revoking.

[Nuwan Dias]

On Tue, Jul 24, 2018 at 3:17 PM Ishara Cooray  wrote:

> Our objective is to run this clean up process without anyone having to
> configure anything. Even today we have instructions and scripts to clean up
> the tables. But in practice, nobody even notices this and never does these
> kind of stuff until they hit an issue and consult us through support. So if
> we design this in such a way that someone has to turn on something or
> configure something, I am positive our efforts will be in waste.
>
> So by default are we going to enable the token cleanup feature and storing
> old access tokens in audit table?
>

Yes, otherwise there's no point of this feature IMO because we currently
have a solution that cleans data but in reality nobody uses it unless they
hit a issue and request our assistance to find and run this.

>
> *@Nalaka,*
> Have we done a load test to verify whether this feature does not affect to
> the functionalities when there is a high load in a high concurrency
> situation?
> If so appreciate if you can share that details as well.
>

Yes, we did. @Nalaka Senarathna  please point to the
relevant thread.

>
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Fri, Jul 20, 2018 at 10:04 AM, Harshan Liyanage 
> wrote:
>
>> Hi Nuwan,
>>
>> Thanks for your detailed clarifications. Both explanations are perfectly
>> valid.
>>
>> Regards,
>>
>> Harshan Liyanage
>> Mobile: *+94765672894*
>> Email: hars...@wso2.com
>> Blog: http://harshanliyanage.blogspot.com/
>> Medium: https://medium.com/@harshan.dll
>> *WSO2, Inc.:** wso2.com <http://wso2.com/>*
>> lean.enterprise.middleware.
>>
>>
>> On Thu, Jul 19, 2018 at 8:35 PM Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Wed, Jul 18, 2018 at 9:09 PM Harshan Liyanage 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> @Nuwan: That's why I suggested having a configurable cron expression so
>>>> that users can configure the task to run on an optimal schedule instead of
>>>> blocking vital functionalities. Also in that way, we could do a batch
>>>> deletes and insertions instead of single rows. For example, they could let
>>>> it run every mid-night so then the access token tables won't grow for
>>>> millions of records and not affecting the user traffic.
>>>>
>>>
>>> Our objective is to run this clean up process without anyone having to
>>> configure anything. Even today we have instructions and scripts to clean up
>>> the tables. But in practice, nobody even notices this and never does these
>>> kind of stuff until they hit an issue and consult us through support. So if
>>> we design this in such a way that someone has to turn on something or
>>> configure something, I am positive our efforts will be in waste.
>>>
>>>>
>>>> @Nalaka: You could let the task to run only on a manager node in a
>>>> distributed setup using a configuration.
>>>>
>>>
>>> There is no such thing as a "manager" node in our architecture. All
>>> nodes are equal. Plus, we cannot introduce such changes as well due to
>>> numerous complexities such as how to HA the manager node, too many varying
>>> configurations, etc.
>>>
>>>>
>>>> BTW that was just a suggestion. It doesn't mean I'm -1 on this proposed
>>>> design. :)
>>>>
>>>> Thanks,
>>>>
>>>> Harshan Liyanage
>>>> Mobile: *+94765672894*
>>>> Email: hars...@wso2.com
>>>> Blog: http://harshanliyanage.blogspot.com/
>>>> Medium: https://medium.com/@harshan.dll
>>>> *WSO2, Inc.:** wso2.com <http://wso2.com/>*
>>>> lean.enterprise.middleware.
>>>>
>>>>
>>>> On Wed, Jul 18, 2018 at 8:51 PM Nalaka Senarathna 
>>>> wrote:
>>>>
>>>>> hi harshan,
>>>>>
>>>>> Also if there are multiple nodes then those nodes also may attempt to
>>>>> clean up the same access token at the same time.
>>>>>
>>>>> related mail thread:[1]
>>>>> [1]Access token Table cleaning and keeping the access token data for
>>>>> future purposes
>>>>>
>>>>> regards.
>>>>>
>>>>>
>>>>> On Wed, Jul 18, 2018 at 8:28 PM, Nuwan Dias  wrote:
>>&g

Re: [Architecture] [APIM][Microgateway] Stop Alerts support for Micogateway analytics

[Nuwan Dias]

What happens here is that real time analytics on SP is done based on time
batch windows and sliding windows. The query on the events in these windows
are based on the time of the window and not really on the time the actual
event occurred (the time the request was processed on API Manager). If we
can find a way to solve the original problem of the data being queried
based on the actual time of its occurrence, this problem would go away.

Although we argue that this problem exists only for the MG due to its
aggregate and upload architecture, the same issue can occur for any other
client that is sending data to SP after queueing on its side. The
occurrence of the problem you are explaining can be very frequent for the
MG due to its architecture. But really, the actual problem is something
that exists for any client that queues and sends data to SP. I think we
should try and solve that problem first.

And also, one more thing we should do is to send data to SP from the MG
directly when the connection is available. And only write to file when a
connection doesn't exist.

On Thu, Jul 19, 2018 at 11:58 AM Fazlan Nazeem  wrote:

> Hi all,
>
> With Micorgateway Analytics support there is now the option to use the
> same Analytics Server(SP for the upcoming release) for both Synapse based
> gateway and Microgateway. With this being the most possible case, we will
> have to redesign how the alerts will be working. The reason being, for
> micro-gateway we are collecting analytics data into files, and then
> uploading those in batches in predefined time intervals.
>
> This will result in events coming into the analytics server in batches(not
> in real time). Generating alerts for these events will make no sense, as
> these events are inherently not real-time.
>
> Therefore can we all agree on this fact, and stop supporting the alerts
> feature for micro-gateways?
>
>
> Thanks & Regards,
>
> *Fazlan Nazeem*
> Senior Software Engineer
> WSO2 Inc
> Mobile : +94772338839
> fazl...@wso2.com
>


-- 
Nuwan Dias

Director - 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] Old access token cleanup when token generating, renewing and revoking.

[Nuwan Dias]

On Wed, Jul 18, 2018 at 9:09 PM Harshan Liyanage  wrote:

> Hi all,
>
> @Nuwan: That's why I suggested having a configurable cron expression so
> that users can configure the task to run on an optimal schedule instead of
> blocking vital functionalities. Also in that way, we could do a batch
> deletes and insertions instead of single rows. For example, they could let
> it run every mid-night so then the access token tables won't grow for
> millions of records and not affecting the user traffic.
>

Our objective is to run this clean up process without anyone having to
configure anything. Even today we have instructions and scripts to clean up
the tables. But in practice, nobody even notices this and never does these
kind of stuff until they hit an issue and consult us through support. So if
we design this in such a way that someone has to turn on something or
configure something, I am positive our efforts will be in waste.

>
> @Nalaka: You could let the task to run only on a manager node in a
> distributed setup using a configuration.
>

There is no such thing as a "manager" node in our architecture. All nodes
are equal. Plus, we cannot introduce such changes as well due to numerous
complexities such as how to HA the manager node, too many varying
configurations, etc.

>
> BTW that was just a suggestion. It doesn't mean I'm -1 on this proposed
> design. :)
>
> Thanks,
>
> Harshan Liyanage
> Mobile: *+94765672894*
> Email: hars...@wso2.com
> Blog: http://harshanliyanage.blogspot.com/
> Medium: https://medium.com/@harshan.dll
> *WSO2, Inc.:** wso2.com <http://wso2.com/>*
> lean.enterprise.middleware.
>
>
> On Wed, Jul 18, 2018 at 8:51 PM Nalaka Senarathna 
> wrote:
>
>> hi harshan,
>>
>> Also if there are multiple nodes then those nodes also may attempt to
>> clean up the same access token at the same time.
>>
>> related mail thread:[1]
>> [1]Access token Table cleaning and keeping the access token data for
>> future purposes
>>
>> regards.
>>
>>
>> On Wed, Jul 18, 2018 at 8:28 PM, Nuwan Dias  wrote:
>>
>>> A periodic task won't work for this because when the system runs on
>>> tables with millions of records, the task will lock the table for the clean
>>> up process. This will impact other queries being executed on the table and
>>> hence block user flows.
>>>
>>> On Wed, Jul 18, 2018 at 6:17 AM Harshan Liyanage 
>>> wrote:
>>>
>>>> Hi Nalaka,
>>>>
>>>> You could do the same with a configurable periodic task instead of
>>>> modifying existing token request flows. What you have to do is to implement
>>>> the token cleanup feature as a periodic task which scans the token related
>>>> tables and move EXPIRED, INACTIVE and REVOKED tokens to the audit
>>>> table. There will be a configuration to configure the CRON expression for
>>>> that task.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks,
>>>>
>>>> Harshan Liyanage
>>>> Mobile: *+94765672894*
>>>> Email: hars...@wso2.com
>>>> Blog: http://harshanliyanage.blogspot.com/
>>>> Medium: https://medium.com/@harshan.dll
>>>> *WSO2, Inc.:** wso2.com <http://wso2.com/>*
>>>> lean.enterprise.middleware.
>>>>
>>>>
>>>> On Wed, Jul 18, 2018 at 2:45 PM Nalaka Senarathna 
>>>> wrote:
>>>>
>>>>>
>>>>> A solution for the access token table filled up with EXPIRED, INACTIVE
>>>>> and REVOKED tokens in the Access token table, old access token can move to
>>>>> the Audit table when the new token is generating, renewing or token
>>>>> revoking.
>>>>>
>>>>>
>>>>> Old Access tokens will be stored in newly created Audit table for
>>>>> audit purposes.
>>>>>
>>>>>
>>>>> *Token cleanup feature can be turn enable / disable.
>>>>>
>>>>> *When the token cleanup feature is enabled old access token can be
>>>>> stored in the audit table
>>>>>
>>>>>   For audit purposes or can disable that feature too, not to store
>>>>> old access tokens(this also can enable/disable).
>>>>>
>>>>>
>>>>> This project avoids the access token table growing and improve the
>>>>> token lookup. For existing users also can get advantage from this.
>>>>>
>>>>>
>>>&g

Re: [Architecture] Micro Gateway CLI - Hashing Resources (APIs/Policies) for change detection

[Nuwan Dias]

gt;>>>>
>>>>>
>>>>> /**
>>>>>  * WSDL URL if the APIDetailedDTO is based on a WSDL endpoint\n
>>>>>  **/
>>>>> @JsonProperty("wsdlUri")
>>>>> public String getWsdlUri() {
>>>>> return wsdlUri;
>>>>> }
>>>>>
>>>>> public void setWsdlUri(String wsdlUri) {
>>>>> this.wsdlUri = wsdlUri;
>>>>> }
>>>>>
>>>>> *@Hash*
>>>>> @JsonProperty("responseCaching")
>>>>> public String getResponseCaching() {
>>>>> return responseCaching;
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> The methods marked with *@Hash* will be automatically extracted from
>>>>> the code and will be used to generate the hashes for each resource.
>>>>>
>>>>> The generated hashes will be stored inside the CLI's temp folder
>>>>> against each resources' UUID, which will be used to compare the hash
>>>>> changes between next runs.
>>>>>
>>>> What are the fields which we have added to the hash?
>>>>
>>>>>
>>>>>
>>>>> Highly appreciate your ideas on this.
>>>>>
>>>>> Thanks!
>>>>> Malintha
>>>>>
>>>>>
>>>>> --
>>>>> Malintha Amarasinghe
>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>> http://wso2.com/
>>>>>
>>>>> Mobile : +94 712383306
>>>>>
>>>>
>>>>
>>>> --
>>>> Harsha Kumara
>>>> Associate Technical Lead, WSO2 Inc.
>>>> Mobile: +94775505618
>>>> Blog:harshcreationz.blogspot.com
>>>>
>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>>
>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>


-- 
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] APIM CLI simplify endpoint url configs

[Nuwan Dias]

I guess you are referring to the Microgateway CLI and not the APIM CLI.

On Mon, Jun 18, 2018 at 11:11 AM, Rukshan Premathunga 
wrote:

> Hi All,
>
> Currently CLI auto generate endpoints from defautl values and user have to
> edit it in order to work if endpoints are diffrent. As a solution we
> thought to provide urls as arguments for setup command.
> But here we have 4 endpoints(store, publisher, admin and token) to get as
> arguments. But making all of them as  mandatory, user experience may get
> reduce, So we need to have a mechanism to derive them.
>
> One option is to use one host for apps in same node(store, pub, admin). If
> it is changed, provide the optional arguments to override them.
>
> So can you also share some idea please.
>
> Thanks and Regards
> --
>
> Rukshan Chathuranga.
> WSO2, Inc.
> +94711822074
>



-- 
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] Tool to configure changes while starting an API-M profile

[Nuwan Dias]

In the doc, it would be better to put the logs that are being printed while
the optimization happens as an example.

On Wed, Jun 13, 2018 at 12:06 PM, Sarubi Thillainathan 
wrote:

> Hi all,
>
> PR for $Subject can be found in [1].
> Documentation for this can be found in [2]
>
> [1] https://github.com/wso2/product-apim/pull/3350
> [2] https://docs.google.com/document/d/1nB112HRslaqXLQA50lXdHblf42QgM
> TIzTCAPVaOFjrA/edit?usp=sharing
>
>
> On Fri, Jun 8, 2018 at 9:14 AM, Chamila De Alwis 
> wrote:
>
>> Hi Nuwan,
>>
>> Thanks! I understand the context now and I completely agree that some
>> kind of convenience is required to prune the base distribution to profile
>> specific ones. It could very well be automated better than being documented
>> instructions.
>>
>> My idea was that if some kind of automation could be done, it would be
>> better suited on top of what we have already built out (ex: our knowledge
>> on Puppet, what WUM client does with pack building). On the other hand,
>> automation which considers details after a certain point could have to
>> cater for a wider spectrum of requirements, which could make the tool
>> complicated.
>>
>> +1 to make the tool to automate the prunning part of the process.
>>
>> Startup time getting affected by the `-Dprofile` property might not be
>> that much of a concern at all (other than for Containerized scenarios,
>> which could make use of pre-baked optimized packs), because instance
>> downtimes are almost always pre-planned and will be done with back up
>> nodes. So few additional seconds would not be that much of a difference.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Associate Technical Lead | WSO2
>> +94 77 220 7163
>> Blog: https://medium.com/@chamilad
>>
>>
>>
>>
>> On Thu, Jun 7, 2018 at 1:18 AM Nuwan Dias  wrote:
>>
>>> While these concerns are valid, I think we need to step back and look at
>>> this. If you look at are current documentation related to profiles, you
>>> will see that we have lots of manual instructions to optimize the profiles.
>>> What this tool/command does is to simply automate all those manual
>>> instructions. So our "produce" at the end of the day will be exactly the
>>> same as it is today.
>>>
>>> This tool does modify some configs, but I wouldn't consider that as a
>>> config automation. Config automation is supposed to do configs to make the
>>> product work according to a particular deployment architecture. The configs
>>> we're modifying in this case do nothing to do with deployment architecture.
>>> All it does is to remove unnecessary processes and stuff based on the
>>> profile. I would rather consider the outcome/produce of this tool to be
>>> used as the base image on which config automation tools should run on.
>>>
>>> I don't think WUM is a problem because WUM always gives you a fresh
>>> distribution. It does not work/modify your current running instance.
>>> Therefore a WUM user has to run the tool/process on the WUM updated
>>> distribution as they do today. So the pipeline would be
>>>
>>> wum_update --> optimize --> puppet --> run
>>>
>>> As Sinthuja has pointed it would perhaps be good to create a new distro
>>> (.zip) after this process so that one can use it as the base distro. We
>>> have currently focused on making the optimization work seamlessly with the
>>> -Dprofile=x startup command, which is how a majority of of customers using
>>> profiles use the product.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Thu, Jun 7, 2018 at 12:19 PM, Chamila De Alwis 
>>> wrote:
>>>
>>>> Thanks Sarubi for the detailed explanation! I had understood the
>>>> context wrong and this cleared up some of the doubts I had. However, I
>>>> still have a hard time grasping the whole user story.
>>>>
>>>> 1. I assume the changes you mention are the ones at [1]. If that is the
>>>> case, there are indeed configuration changes involved. These are typically
>>>> handled by a configuration automation tool. This is the overlap I'm
>>>> concerned with. With the limited information I have, I guess any config
>>>> automation will have to consider both scenarios where this script is
>>>> present and absent. In other words, a set of scripts that work with a pack
>>>> edited by this script would not work with t

Re: [Architecture] Adding custom attributes to Applications in API Store

[Nuwan Dias]

Its more of a convention. Since our C4 code is tenant aware, we have a
convention to put the tenant id in all the tables so that we can use it for
things outside application logic. Such as tenant data removal/cleanup,
audits, etc.

On Mon, Jun 11, 2018 at 2:15 PM, Vithursa Mahendrarajah 
wrote:

> Hi Godwin,
>
> Sorry, I misunderstood your previous mail. Currently we don't have a
> specific need to use tenant_id from AM_APPLICATION_ATTRIBUTES. We have
> added it for future references.
>
> Thanks,
>
> On Mon, Jun 11, 2018 at 1:28 PM, Godwin Amila Shrimal 
> wrote:
>
>> Hi Vithursa,
>>
>> What I asked is do we really need to keep tenant_id in
>> AM_APPLICATION_ATTRIBUTES table since we already have tenancy in
>> Application level ? I guess Application to application attribute has an one
>> to many relationship.
>>
>> Thanks
>> Godwin
>>
>> On Mon, Jun 11, 2018, 6:43 AM Vithursa Mahendrarajah 
>> wrote:
>>
>>> Hi Godwin,
>>>
>>> Yes, Tenant-awareness is incorporated in this feature and tenant_id is
>>> stored against each attribute (in AM_APPLICATION_ATTRIBUTES).
>>>
>>> Thanks,
>>>
>>> On Mon, Jun 11, 2018 at 10:54 AM, Godwin Amila Shrimal 
>>> wrote:
>>>
>>>> Hi Vithursa/Nuwan,
>>>>
>>>> Sorry for giving my feedback at this moment. Do we have to especially
>>>> think of tenant awareness for the application attributes and add tennat_id
>>>> to AM_APPLICATION_ATTRIBUTES table? Our Application is already tenant
>>>> aware. right? Correct me if I am wrong.
>>>>
>>>> Thanks
>>>> Godwin
>>>>
>>>> On Tue, May 1, 2018 at 7:03 AM Vithursa Mahendrarajah <
>>>> vithu...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> +1 for making this feature tenant aware. I will accommodate it into
>>>>> the design.
>>>>>
>>>>> As discussed with Nuwan, the table AM_APPLICATION_ATTRIBUTES will be
>>>>> modified to have an additional column to store tenant_id.
>>>>>
>>>>> Thanks & Regards,
>>>>>
>>>>>
>>>>> On Sat, Apr 28, 2018 at 6:55 PM, Nuwan Dias  wrote:
>>>>>
>>>>>> One more thought that came to mind is that we have to make this
>>>>>> feature tenant aware. In the sense that each tenant should be able to
>>>>>> decide its own attributes. Let’s change the design to accommodate that.
>>>>>>
>>>>>> On Wed, Apr 25, 2018 at 9:07 PM Vithursa Mahendrarajah <
>>>>>> vithu...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I will remove IS_REQUIRE column from AM_APPLICATION_ATTRIBUTES. We
>>>>>>> can specify in UI as *required* by reading values from xml file.
>>>>>>>
>>>>>>> Thanks & Regards,
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 25, 2018 at 1:05 PM, Nuwan Dias  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 25, 2018 at 12:56 PM, Vithursa Mahendrarajah <
>>>>>>>> vithu...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Please find updated user story in [1]. (Also .pdf is attached).
>>>>>>>>>
>>>>>>>>> As discussed with Nuwan, Following implementation flow is planned
>>>>>>>>> to store custom attributes against an Application.
>>>>>>>>>
>>>>>>>>> 1. In the first step, user needs to configure keys of attributes
>>>>>>>>> in api-manager.xml. Attributes may need to be differentiated as
>>>>>>>>> *required* and *optional*. User should not be able to create an
>>>>>>>>> Application without attributes that marked as *required*.
>>>>>>>>>
>>>>>>>>> For instance, if the required keys were *External Reference Id*
>>>>>>>>> and *Billing Tier *where *External Reference Id* is a mandatory
>>>>>>>>> key, user can configure as,
>>>>>>>>>
>>>>>>>>> 
&

Re: [Architecture] Tool to configure changes while starting an API-M profile

[Nuwan Dias]

ar profile then start the server automatically, otherwise not.
>>>
>>> Please find inline comments for further details:
>>>
>>>
>>> On Tue, Jun 5, 2018 at 4:11 AM, Chamila De Alwis 
>>> wrote:
>>>
>>>> Hi Sarubi,
>>>>
>>>> I have a couple of questions regarding the fit between the changes that
>>>> this script does and the config automation tools.
>>>>
>>>> Is this a tool focused on evaluation part of the product or the
>>>> deployment part? IMO both would require a re-evaluation of the approach.
>>>>
>>>
>>> This is focused on deployment part of product.
>>>
>>>>
>>>> IIUC, this script would alter the startup pack, with file additions and
>>>> removals done to config files, deployable artifacts, and other library
>>>> files. This could be a problematic case for continuous config automation
>>>> story.
>>>>
>>>> Consider a scenario where Puppet (or any other tool) configures a set
>>>> of instances, using the APIM pack as the root. The tool might be configured
>>>> to continuously run (say, with a 30-minute interval). Is there a chance for
>>>> the server to be reconfigured every time the tool is run, because the tool
>>>> detects the changes that this script does at the startup, as changes that
>>>> should be rolled back?
>>>>
>>>
>>> According to the scenario that you have mentioned, Puppet (or any other
>>> tool) can configures a set of instances, using optimized APIM pack as the
>>> root.
>>>
>>>
>>>> In that case, it might be better to have this tool as a separate script
>>>> rather than one which starts up the server as well.
>>>>
>>>
>>> Yes, now we maintain a seperate script which will get executed based on
>>> the user specification for server start-up.
>>>
>>>>
>>>> Another point against such a tool bound to server startup would be the
>>>> mixing of concerns. AFAIU, what this script does falls under what the
>>>> config automation tools do. IMO WSO2 server startup scripts should only
>>>> work on the bootstrapping of the server runtime, rather than the config
>>>> automation part. Also, we would essentially be repeating what the config
>>>> automation tools should do, but in Bash which sometimes is a lot harder.
>>>> Obtaining config values, managing them meaningfully, and applying them to
>>>> files is essentially what a config automation tool does. We may be
>>>> re-inventing the wheel here. For an example, should this tool be concerned
>>>> about the port offset at all since even dev deployments will be done using
>>>> separate VMs/Containers? Or should it be worried about different values for
>>>> the config options in different environments?
>>>>
>>>> Also, this script don't concerned about the port offset things since it
>>> designed only to configure the changes for corresponding profile specified.
>>>
>>>
>>>> Additionally, users who manage config automation usually adhere to one
>>>> set of scripts. Puppet users almost always go for Puppet, Chef users for
>>>> Chef etc. What we would be delivering might step on what they already have,
>>>> or are comfortable working with, and in turn, the adaption rate might take
>>>> a hit.
>>>>
>>>> User can go with first option, run the profile setup script seperatly
>>> before server start up and get optimized API-M pack as the base image
>>>
>>>
>>>> IMO you might benefit from reviewing your approach with the
>>>> Installation Experience effort, as the responsibilities of this tool fall
>>>> close to, if not overlap with, what the Installation Experience scripts
>>>> deliver/would deliver with different providers.
>>>>
>>>> WDYT?
>>>>
>>>>
>>>> Regards,
>>>> Chamila de Alwis
>>>> Committer and PMC Member - Apache Stratos
>>>> Associate Technical Lead | WSO2
>>>> +94 77 220 7163
>>>> Blog: https://medium.com/@chamilad
>>>>
>>>>
>>> Commnets or suggestions are highly appreciated.
>>>
>>> [1]https://docs.wso2.com/display/AM220/Product+Profiles
>>>
>>>
>>> --
>>> *Sarubi Thillainathan *
>>> *Software Engineer - WSO2 Inc.*
>>>
>>> *Mobile : +94 (0) 76 68 49 101*
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> *Sinthuja Rajendran*
>> Senior Technical Lead
>> WSO2, Inc.:http://wso2.com
>>
>> Blog: http://sinthu-rajan.blogspot.com/
>> Mobile: +94774273955
>>
>>
>>


-- 
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] APIM Micro Gateway Cli Functionality and Structure

[Nuwan Dias]

Instead of naming the templates under a directory called 'templates', we
should probably generalize that and say 'resources'.

On Mon, May 28, 2018 at 3:36 PM, Rukshan Premathunga <ruks...@wso2.com>
wrote:

> Hi Harsha,
>
> Where do we store generated policies bals? Since it is not related to
> labels we can put it to separate directory under the projects dir.
>
> Thanks and Regards
>
> On Mon, May 28, 2018 at 3:33 PM, Harsha Kumara <hars...@wso2.com> wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 3:31 PM Bhathiya Jayasekara <bhath...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara <hars...@wso2.com> wrote:
>>>
>>>> *Core Cli Commands*
>>>>
>>>>- *micro-gw setup/init (with inputs username, label name and
>>>>password(*optional
>>>> *)) *
>>>>
>>>> I think the project path shoul be an input for this.
>>>
>> Yes
>>
>>>
>>>
>>>> micro-gw-resources
>>>>
>>>> ├── conf
>>>>
>>>> │   └── config.yaml
>>>>
>>>> └── projects (folder name is same as label name)
>>>>
>>>> ├── accounts
>>>>
>>>> │   ├── src
>>>>
>>>> │   │   ├── companyAccounts_v1.0.0.bal
>>>>
>>>> │   │   └── salesforce_v1.0.0.bal
>>>>
>>>> │   └── target
>>>>
>>>> │   ├── accounts.balx
>>>>
>>>> │   └── accounts.zip
>>>>
>>>> ├── finance
>>>>
>>>> │   ├── src
>>>>
>>>> │   │   ├── invoices_v2.0.0.bal
>>>>
>>>> │   │   └── payments_v2.1.0.bal
>>>>
>>>> │   └── target
>>>>
>>>> │   ├── finance.balx
>>>>
>>>> │   └── finance.zip
>>>>
>>>> ├── gateway-config
>>>>
>>>> │   └── gateway-config.yaml
>>>>
>>>>
>>> Shouldn't this come under every label? f
>>>
>> Yes structure should be as follow.
>> micro-gw-resources
>> ├── conf
>> │   └── config.yaml
>> └── projects
>> ├── accounts
>> │   ├── gateway-config
>> │   │   └── gateway-config.yaml
>> │   ├── src
>> │   │   ├── companyAccounts_v1.0.0.bal
>> │   │   └── salesforce_v1.0.0.bal
>> │   └── target
>> │   ├── accounts.balx
>> │   └── accounts.zip
>> ├── finance
>> │   ├── gateway-config
>> │   │   └── gateway-config.yaml
>> │   ├── src
>> │   │   ├── invoices_v2.0.0.bal
>> │   │   └── payments_v2.1.0.bal
>> │   └── target
>> │   ├── finance.balx
>> │   └── finance.zip
>> └── sales
>> ├── gateway-config
>> │   └── gateway-config.yaml
>> ├── src
>> │   ├── customers_v3.0.0.bal
>> │   └── leads_v4.0.0.bal
>> └── target
>> ├── sales.balx
>> └── sales.zip
>>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>
>>>> └── sales
>>>>
>>>> ├── src
>>>>
>>>> │   ├── customers_v3.0.0.bal
>>>>
>>>> │   └── leads_v4.0.0.bal
>>>>
>>>> └── target
>>>>
>>>> ├── sales.balx
>>>>
>>>> └── sales.zip
>>>>
>>>>
>>>>- *micro-gw build (with inputs label name)*
>>>>   - This command build single balx out of all APIs belongs to
>>>>   given label. If docker/kubernetes configurations specified, then
>>>>   archive will be generated. This archive will embeds bre, generated 
>>>> balx
>>>>   which someone can take and run without configuring anything.
>>>>   - This command also outputs APIs which have updated and commands
>>>>   which are available to run in target folder
>>>>- *micro-gw run (with label name)*
>>>>   - This command will use to run the balx generated for given
>>>>   label.
>>>>
>>>> Please share your suggestions and improvements.
>>>>
>>>>
>>>> Thanks,
>>>> Harsha
>>>> --
>>>> Harsha Kumara
>>>> Associate Technical Lead, WSO2 Inc.
>>>> Mobile: +94775505618
>>>> Blog:harshcreationz.blogspot.com
>>>>
>>>
>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Associate Technical Lead,*
>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>
>>> *Phone: +94715478185*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> <http://www.linkedin.com/in/bhathiyaj>*
>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
>>> *Blog: http://movingaheadblog.blogspot.com
>>> <http://movingaheadblog.blogspot.com/>*
>>>
>>
>>
>> --
>> Harsha Kumara
>> Associate Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
> +94711822074
>



-- 
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] [APIM][API-Manager gateway] REST API to Fetch API Details to APIM-Gateway

[Nuwan Dias]

On Thu, May 17, 2018 at 11:49 AM, Malintha Amarasinghe <malint...@wso2.com>
wrote:

>
>
> On Thu, May 17, 2018 at 10:57 AM Nuwan Dias <nuw...@wso2.com> wrote:
>
>> Using /export might confuse with the api export API we have for API
>> Manager 3.0. We should probably use the GET /apis Resource for this as
>> well.
>>
>> Since we need to search by label, we'll probably need to filter as below
>>
>> GET /apis?query=label:foo
>>
>> Since we need to omit pagination (because in this case we need all
>> results) we may need to do something like this
>>
>> GET /apis?limit=unlimited
>>
> The limit is currently defined as a number. How about limit=-1? Or we have
> to change the limit data type to string.
>

+1

>
>
>> The GET /apis responds with a partial payload for listing purposes. Since
>> that doesn't work in this case we probably need to support a query param
>> named 'expand'. Ex:
>>
>> GET /apis?expand=true
>>
>> We may need to honor the Accept header to decide on compression. Ex:
>>
>> Accept: application/gzip
>>
>> On Wed, May 16, 2018 at 6:38 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Hi Sachini,
>>>
>>> Since the response could have more than 1 APIs you will have to consider
>>> about pagination as well.
>>>
>>> For that, you may use existing *APIList *resource in the
>>> publisher-api.yaml
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Tue, May 15, 2018 at 10:08 AM, Sachini De Silva <sachi...@wso2.com>
>>> wrote:
>>>
>>>> Hi Harsha,
>>>>
>>>> Yes, the response contains the swagger definition of APIs and all
>>>> fields in APIDTO. As for the current implementation labeled apis are
>>>> returned as a json list. (see response.json) To accommodate this I have
>>>> introduced a new DetailedAPIListDTO as below.
>>>>
>>>> DetailedAPIList:
>>>> title: Detailed API List
>>>> properties:
>>>>   list:
>>>> type: array
>>>> items:
>>>>   $ref: '#/definitions/API'
>>>>
>>>> At the moment I am working on compressing the response.
>>>>
>>>> Thanks,
>>>> Sachini
>>>>
>>>>
>>>> On Mon, May 14, 2018 at 5:39 PM, Harsha Kumara <hars...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Sachini,
>>>>>
>>>>> Is swagger definition embed with the response returning from this API?
>>>>>
>>>>> Thanks,
>>>>> Harsha
>>>>>
>>>>> On Wed, May 9, 2018 at 2:49 PM Sachini De Silva <sachi...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> @Harsha Decided to return all information in APIDTO for each API as
>>>>>> the response. (not only swagger definition, name, version, context and
>>>>>> provider)
>>>>>>
>>>>>> Thanks,
>>>>>> Sachini
>>>>>>
>>>>>> On Wed, May 9, 2018 at 1:59 PM, Harsha Kumara <hars...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> @Sachini Can you also add a sample response as well?
>>>>>>>
>>>>>>> On Wed, May 9, 2018 at 8:02 AM, Malintha Amarasinghe <
>>>>>>> malint...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 8, 2018 at 6:10 PM, Sachini De Silva <sachi...@wso2.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Proposed resource structure is as below.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /exports/apis:
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1. I think this looks more like generic export resource which is
>>>>>>>> not really specific for the ballerina gw feature. I think it is okay 
>>>

Re: [Architecture] [APIM][API-Manager gateway] REST API to Fetch API Details to APIM-Gateway

[Nuwan Dias]

t;>
>>>>>>>>> So ideally I should be able to do this by adding a new resource to
>>>>>>>>> publisher-api.yaml to fetch APIs by label. Then this resource call 
>>>>>>>>> has to
>>>>>>>>> be mapped to where the setup command is executed.
>>>>>>>>>
>>>>>>>>> Suggestions are highly appreciated.
>>>>>>>>>
>>>>>>>>> Related mail threads :
>>>>>>>>> [1] [Architecture][APIM] Label feature for API-Manager gateway
>>>>>>>>> [2] [Architecture][APIM][API-Manager gateway] Attaching Labels
>>>>>>>>> for APIs
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Sachini
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> *Sachini De Silva*
>>>>>>>>> Software Engineer - WSO2
>>>>>>>>>
>>>>>>>>> Email : sachi...@wso2.com
>>>>>>>>> Mobile : +94714765495
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>>> Architecture mailing list
>>>>>>>>> Architecture@wso2.org
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Krishan Wijesena*
>>>>>>>> Software Engineer | WSO2
>>>>>>>>
>>>>>>>> Email : krish...@wso2.com
>>>>>>>> Mobile : +94776219923
>>>>>>>> WSO2 Inc : http://wso2.com
>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Sachini De Silva*
>>>>>>> Software Engineer - WSO2
>>>>>>>
>>>>>>> Email : sachi...@wso2.com
>>>>>>> Mobile : +94714765495
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Malintha Amarasinghe
>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>> http://wso2.com/
>>>>>>
>>>>>> Mobile : +94 712383306
>>>>>>
>>>>>> ___
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Sachini De Silva*
>>>> Software Engineer - WSO2
>>>>
>>>> Email : sachi...@wso2.com
>>>> Mobile : +94714765495
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>>
>> --
>>
>> *Sachini De Silva*
>> Software Engineer - WSO2
>>
>> Email : sachi...@wso2.com
>> Mobile : +94714765495
>>
>>
>> ___
>> 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
>
>


-- 
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] [APIM] Label feature for API-Manager gateway

[Nuwan Dias]

The exported artifact (API) should only have a reference to the label name.
The same label may have a different URL on the environment the artifact is
being imported to.

On Fri, May 4, 2018 at 2:30 PM, Krishan Wijesena <krish...@wso2.com> wrote:

> Hi chamin,
>
> On Thu, May 3, 2018 at 10:27 PM, Chamin Dias <cham...@wso2.com> wrote:
>
>> Hi Krishan,
>>
>> On Thu, May 3, 2018 at 3:29 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>>
>>>
>>> On Thu, May 3, 2018 at 2:43 PM, Pubudu Gunatilaka <pubu...@wso2.com>
>>> wrote:
>>>
>>>> Hi Nuwan,
>>>>
>>>> On Thu, May 3, 2018 at 1:07 PM Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, May 3, 2018 at 1:02 PM, Pubudu Gunatilaka <pubu...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Krishan
>>>>>> On Thu, May 3, 2018 at 12:53 PM Harsha Kumara <hars...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 2, 2018 at 6:26 PM, Krishan Wijesena <krish...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>>
>>>>>>>> Currently, I'm working on the Labeling feature for API Manager
>>>>>>>> gateway. API Manager need to allows adding labels to the APIs in
>>>>>>>> create/update phases from the publisher, so that labels help to 
>>>>>>>> grouping
>>>>>>>> APIs into API manager gateway.
>>>>>>>>
>>>>>>>> If the user requests the particular label, then it provides the set
>>>>>>>> of APIs that deploy in the same gateway.
>>>>>>>>
>>>>>>>> As initial phase, labels should be defined by the
>>>>>>>> admin(Super/Tenant) using admin dashboard and the particular label 
>>>>>>>> should
>>>>>>>> have set of properties.
>>>>>>>>
>>>>>>>> To do that I need to introduce AM_LABEL table to the AM database to
>>>>>>>> store the labels and it’s schema as follows.
>>>>>>>>
>>>>>>>> LABEL_ID is the primary key and (NAME & TENANT_ID) is Unique.
>>>>>>>>
>>>>>>>> Label should have separate Http and Https basepath.
>>>>>>>>
>>>>>>> What will be store in base path? Basically we can create labels and
>>>>>>> assigned them to APIs.
>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> We only need label_id and it can be a UUID value.
>>>>>>
>>>>>> HTTP/HTTPS base paths are wrong. This has to be the access urls of
>>>>>> the gateway. For an exmaple we can have the label called Public and it 
>>>>>> can
>>>>>> have the following access urls.
>>>>>>
>>>>>> http://wso2.gw.com
>>>>>> https://wso2.gw.com
>>>>>>
>>>>>>
>> Have we analyzed the impact for import/export tool W.R.T these labels?
>> Eg : How do we deal with these URLs when using the tool
>>
>If user import the APIs, these URLs should be change according to the
> environment and it should be handle in the API import time.
>
>>
>>
>>> Additionally we need to add WebSocket endpoints as well. So we need to
>>>>>> have 4 types of access urls in here.
>>>>>>
>>>>>> Are we not using the endpionts defined in APIGateway section here
>>>>>> after or what is the strategy going forwar?
>>>>>>
>>>>>
>>>>> This 'label' would only be used by the new Ballerina based
>>>>> microgateway we hope to introduce. Our current/old Gateway would still be
>>>>> exposed over the Endpoint defined in the APIGateway section of the
>>>>> api-manager.xml.
>>>>>
>>>>>>
>>>>>> Are we adding a default label for APIs when creating/publishing?
>>>>>>
>>>>>
>&

Re: [Architecture] [APIM][API-Manager gateway] Attaching Labels for APIs

[Nuwan Dias]

I think it should be in the rxt as a field. Storing it as a property seems
like a hack to me. And yes, storing on a separate DB will cause
complications with queries since the rest of the data is in the rxt.

On Fri, May 4, 2018 at 5:45 PM, Malintha Amarasinghe <malint...@wso2.com>
wrote:

> Hi,
>
> On Fri, May 4, 2018 at 11:15 AM, Prasanna Dangalla <prasa...@wso2.com>
> wrote:
>
>>
>> HI,
>>
>>
>>
>> On Fri, May 4, 2018 at 11:07 AM Chamin Dias <cham...@wso2.com> wrote:
>>
>>> On Fri, May 4, 2018 at 9:19 AM, Dinusha Dissanayake <dinus...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>>
>>>>> AFAIU we are going to use labels when downloading a subset of APIs via
>>>>> Microgateway. If it is not mandatory to have the labels, how are we going
>>>>> to handle the APIs without labels in Microgateway? Are we not going to
>>>>> download the APIs without labels?
>>>>>
>>>>> As Sachini has mentioned above if a subset of APIs to be deployed in
>>>> the micro gateway, it needs to have a label. Say if APIs have a default
>>>> label called "def_label". Then if we call "setup def_label", all the APIs
>>>> will be deployed in the micro gateway. Hence I do not think having a
>>>> default label would add a significant value. Only the APIs needed to be
>>>> deployed in the micro gateways will have labels AFAIR. (please correct me
>>>> if I am wrong)
>>>>
>>>
>>> Agree with Dinusha. As per the previous discussions
>>> <http://mail.wso2.org/mailarchive/architecture/2018-May/030704.html>
>>> also this fact has been confirmed. Hence the business value of adding a
>>> default label would be minor IMHO.
>>>
>> Yes IMO too it not mandaory to add a default value to the label.
>>
>> We need to decide, how we are storing the label vales that are attched to
>> a specific label. There are three options as for the discussion had.
>>
>>- Store it as an API RXT filed value.
>>- Add the label as a property to the API reource
>>- Add the label to AM_DB
>>
>> All curent search queries we are running in registry(solr). If we use a
> seperate mapping in AM_DB, we might not be able to use multiple searches at
> the same time, eg: search APIs which have has label "Internal" status:
> "PUBLISHED" or "PROTOTYPED" since we do not keep status in the DB.
>
> So I think we need to go for option 1 or 2. WDYT?
>
> Can we store multivalued attributes in registry properties?
>
> Thanks!
> Malintha
>
>
>> Your thoughts on the above factor is hoghly appreciated.
>>
>> @Chamin: Can you share a digram of the floor that we discussed.
>>
>> Thanks
>> Prasanna
>>
>>
>>>
>>>>
>>>> Thanks,
>>>> DinushaD.
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Chamin Dias
>>> Mobile : 0716097455
>>> Email : cham...@wso2.com
>>> LinkedIn : https://www.linkedin.com/in/chamindias
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
>
> ___
> 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

Re: [Architecture] [APIM][API-Manager gateway] REST API to Fetch API Details to APIM-Gateway

[Nuwan Dias]

Can you also come up with the resource structure and scope for the
suggested functionality?

I guess we would need to search APIs with the corresponding label and
return only the ones in PUBLISHED or PROTOTYPED states.

On Fri, May 4, 2018 at 9:57 AM, Sachini De Silva <sachi...@wso2.com> wrote:

> Hi all,
>
>
> *Design Overview*
> I am working on developing a REST API to fetch API details to APIM gateway
> from the publisher. Fetching of APIs is based on labels, i.e as mentioned
> in [1] a certain set of APIs can be grouped into a certain gateway instance
> by a label. When setting up the gateway the user executes following command
> followed by user credentials.
>
> setup 
>
> Then a request for APIs labeled with  is sent to API publisher. The
> response to this is, API details as a compressed JSON. Then based on the
> retrieved details b7a project  structure for the gateway instance will be
> created and deployed.
>
> So ideally I should be able to do this by adding a new resource to
> publisher-api.yaml to fetch APIs by label. Then this resource call has to
> be mapped to where the setup command is executed.
>
> Suggestions are highly appreciated.
>
> Related mail threads :
> [1] [Architecture][APIM] Label feature for API-Manager gateway
> [2] [Architecture][APIM][API-Manager gateway] Attaching Labels for APIs
>
> Thanks,
> Sachini
>
> --
>
> *Sachini De Silva*
> Software Engineer - WSO2
>
> Email : sachi...@wso2.com
> Mobile : +94714765495
>
>
> ___
> 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

Re: [Architecture] Micro gateway profile for WSO2 EI - 6.3.0

[Nuwan Dias]

Hi,

Why is this being called Microgateway? This will cause huge confusion with
the WSO2 API Manager's Gateway. Is this really a Gateway profile or a
stripped down version of the ESB?

Thanks,
NuwanD.

On Thu, May 3, 2018 at 2:56 PM, Madhawa Gunasekara <madha...@wso2.com>
wrote:

> Hi,
>
> I'm starting working on light weight ESB profile to work on containers. so
> basically we are trying to remove all the ui components and the registry
> for that particular profile. but Tasks are depending on the Registry.
> Therefore We need to find a way to provide tasks functionality for this
> profile.
>
> @Integration team: Any thoughts and suggestions regarding this issue
>
> Thanks,
> Madhawa
>
> --
> *Madhawa Gunasekara*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 719411002 <+94+719411002>
> blog: *http://madhawa-gunasekara.blogspot.com
> <http://madhawa-gunasekara.blogspot.com>*
> linkedin: *http://lk.linkedin.com/in/mgunasekara
> <http://lk.linkedin.com/in/mgunasekara>*
>
> ___
> 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

Re: [Architecture] [APIM] Label feature for API-Manager gateway

[Nuwan Dias]

On Thu, May 3, 2018 at 1:02 PM, Pubudu Gunatilaka <pubu...@wso2.com> wrote:

> Hi Krishan
> On Thu, May 3, 2018 at 12:53 PM Harsha Kumara <hars...@wso2.com> wrote:
>
>>
>>
>> On Wed, May 2, 2018 at 6:26 PM, Krishan Wijesena <krish...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>>
>>> Currently, I'm working on the Labeling feature for API Manager gateway.
>>> API Manager need to allows adding labels to the APIs in create/update
>>> phases from the publisher, so that labels help to grouping APIs into API
>>> manager gateway.
>>>
>>> If the user requests the particular label, then it provides the set of
>>> APIs that deploy in the same gateway.
>>>
>>> As initial phase, labels should be defined by the admin(Super/Tenant)
>>> using admin dashboard and the particular label should have set of
>>> properties.
>>>
>>> To do that I need to introduce AM_LABEL table to the AM database to
>>> store the labels and it’s schema as follows.
>>>
>>> LABEL_ID is the primary key and (NAME & TENANT_ID) is Unique.
>>>
>>> Label should have separate Http and Https basepath.
>>>
>> What will be store in base path? Basically we can create labels and
>> assigned them to APIs.
>>
>>>
>>>
>>>
>>>
> We only need label_id and it can be a UUID value.
>
> HTTP/HTTPS base paths are wrong. This has to be the access urls of the
> gateway. For an exmaple we can have the label called Public and it can have
> the following access urls.
>
> http://wso2.gw.com
> https://wso2.gw.com
>
> Additionally we need to add WebSocket endpoints as well. So we need to
> have 4 types of access urls in here.
>
> Are we not using the endpionts defined in APIGateway section here after or
> what is the strategy going forwar?
>

This 'label' would only be used by the new Ballerina based microgateway we
hope to introduce. Our current/old Gateway would still be exposed over the
Endpoint defined in the APIGateway section of the api-manager.xml.

>
> Are we adding a default label for APIs when creating/publishing?
>

Do we have a need to?

>
> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Senior Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049
>
>
> ___
> 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

Re: [Architecture] Adding custom attributes to Applications in API Store

[Nuwan Dias]

On Thu, Apr 19, 2018 at 11:15 AM, Rajith Roshan <raji...@wso2.com> wrote:

> Hi all
>
> On Thu, Apr 19, 2018 at 9:19 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>> We don't have an application search capability right now right? If so I
>> don't think we should be adding such a feature. Because its unlikely
>> someone will have so many apps to search from.
>>
>> Some of the usages of these properties that I could think are (based on
>> some replies as well).
>>
>> 1. The need to publish these data to third party key managers when
>> generating application keys.
>> 2. The need to publish these data to application/subscription related
>> workflows.
>> 3. The need to access these data at the API Gateway when processing a
>> request (we could probably use the JWT for this).
>>
>
> So based on the usages of these attributes , and analyzing some of the use
> cases , I think better option is to have set of predefined key values for
> these application attributes. Giving the api consumer to add the both key
> , value pairs is meaning less because none of the key manager, gateway,
> workflows etc would not know how to process those values, if api consumer
> add what ever the values they have in mind as keys.
> I think we should have way to configure the set of predefined keys , where
> UI will read the config and render the keys as text fields so api consumer
> can provide values to those keys.
> With fixed set of pre configured attributes and we can also provide
> flexibility to define both key value pairs to the api consumer as well.
>

+1.

>
>> Anyhow, Vithursa let's take these requirements step by step. First lets
>> work on the design and implementation of saving these data against the
>> Application.
>>
>> On Thu, Apr 19, 2018 at 7:12 AM, Prasanna Dangalla <prasa...@wso2.com>
>> wrote:
>>
>>> Hi Vithursa,
>>>
>>> Is there a possibilty of adding a functionality to search applications
>>> using custom attibutes. IMO this will aslo be a valied use case.
>>>
>>> Thanks
>>> Prasanna
>>>
>>> On Thu, Apr 19, 2018 at 5:35 AM Ishara Cooray <isha...@wso2.com> wrote:
>>>
>>>> Hi Vithursa,
>>>>
>>>> IMO you also need to have *another user story to delete applications
>>>> with custom attributes *where you need to make sure application is
>>>> successfully deleted from the application list along with its custom
>>>> attributes.
>>>>
>>>> Thanks & Regards,
>>>> Ishara Cooray
>>>> Senior Software Engineer
>>>> Mobile : +9477 262 9512
>>>> WSO2, Inc. | http://wso2.com/
>>>> Lean . Enterprise . Middleware
>>>>
>>>> On Thu, Apr 19, 2018 at 1:54 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>> Based on what Youcef has mentioned, we would need to include these
>>>>> additional properties on the JWT perhaps so that they can be accessed by
>>>>> the Gateway upon validating an access token.
>>>>>
>>>>> On Wed, Apr 18, 2018 at 11:38 PM, Youcef HILEM <
>>>>> youcef.hi...@laposte.fr> wrote:
>>>>>
>>>>>> Hi,
>>>>>>  for this feature.
>>>>>> I do not have access to the document [1] but we wish to develop
>>>>>> mediations
>>>>>> reinforcing access control to APIs according to these metadata
>>>>>> (example
>>>>>> (key: client-contract, value: contractx), ie : association between
>>>>>> client-id
>>>>>> & client-contract-id).
>>>>>> Thanks
>>>>>> Youcef HILEM
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from: http://wso2-oxygen-tank.10903.
>>>>>> n7.nabble.com/WSO2-Architecture-f62919.html
>>>>>> ___
>>>>>> 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
>>>>>
&

Re: [Architecture] Adding custom attributes to Applications in API Store

[Nuwan Dias]

We don't have an application search capability right now right? If so I
don't think we should be adding such a feature. Because its unlikely
someone will have so many apps to search from.

Some of the usages of these properties that I could think are (based on
some replies as well).

1. The need to publish these data to third party key managers when
generating application keys.
2. The need to publish these data to application/subscription related
workflows.
3. The need to access these data at the API Gateway when processing a
request (we could probably use the JWT for this).

Anyhow, Vithursa let's take these requirements step by step. First lets
work on the design and implementation of saving these data against the
Application.

On Thu, Apr 19, 2018 at 7:12 AM, Prasanna Dangalla <prasa...@wso2.com>
wrote:

> Hi Vithursa,
>
> Is there a possibilty of adding a functionality to search applications
> using custom attibutes. IMO this will aslo be a valied use case.
>
> Thanks
> Prasanna
>
> On Thu, Apr 19, 2018 at 5:35 AM Ishara Cooray <isha...@wso2.com> wrote:
>
>> Hi Vithursa,
>>
>> IMO you also need to have *another user story to delete applications
>> with custom attributes *where you need to make sure application is
>> successfully deleted from the application list along with its custom
>> attributes.
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Thu, Apr 19, 2018 at 1:54 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> Based on what Youcef has mentioned, we would need to include these
>>> additional properties on the JWT perhaps so that they can be accessed by
>>> the Gateway upon validating an access token.
>>>
>>> On Wed, Apr 18, 2018 at 11:38 PM, Youcef HILEM <youcef.hi...@laposte.fr>
>>> wrote:
>>>
>>>> Hi,
>>>>  for this feature.
>>>> I do not have access to the document [1] but we wish to develop
>>>> mediations
>>>> reinforcing access control to APIs according to these metadata (example
>>>> (key: client-contract, value: contractx), ie : association between
>>>> client-id
>>>> & client-contract-id).
>>>> Thanks
>>>> Youcef HILEM
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-
>>>> Architecture-f62919.html
>>>> ___
>>>> 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
>>>
>>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> --
> *Prasanna Dangalla*
> Senior Software Engineer, WSO2, Inc.; http://wso2.com/
> lean.enterprise.middleware
>
>
> *cell: +94 718 11 27 51*
> *twitter: @prasa77*
>
> ___
> 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

Re: [Architecture] Adding custom attributes to Applications in API Store

[Nuwan Dias]

Based on what Youcef has mentioned, we would need to include these
additional properties on the JWT perhaps so that they can be accessed by
the Gateway upon validating an access token.

On Wed, Apr 18, 2018 at 11:38 PM, Youcef HILEM <youcef.hi...@laposte.fr>
wrote:

> Hi,
>  for this feature.
> I do not have access to the document [1] but we wish to develop mediations
> reinforcing access control to APIs according to these metadata (example
> (key: client-contract, value: contractx), ie : association between
> client-id
> & client-contract-id).
> Thanks
> Youcef HILEM
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-
> Architecture-f62919.html
> ___
> 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

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Nuwan Dias]

Thanks for explanations, the scenarios on when this is needed is now clear.

On Wed, Apr 11, 2018 at 12:30 PM, Johann Nallathamby <joh...@wso2.com>
wrote:

> Hi Nuwan,
>
> On Wed, Apr 11, 2018 at 5:43 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>> Provisioning users with a known/proper password would make it possible
>> for them to login/authenticate directly against IS without being
>> authenticated against the federated IDP right?
>>
>
> Yes. The requirement is to allow these users have a password in IS that
> will be governed by the password policies in IS, and allow them to login to
> applications using IS login.
>
>
>> Do we really want to allow that?
>>
>
> Yes, that is the requirement.
>
>
>> If internal admins want to manage their accounts internally, or if we
>> want users to login/authenticate to IS directly, why would they
>> authenticate against a federated IDP in the first place?
>>
>
> There are two use cases that need to have this capability.
>
> 1. Social sign-up - In some websites social signup (not login) is used as
> a means of making the signup process easier, by providing the mandatory
> user attributes, but at the end of it a password must be provisioned. After
> this signup process the user will mostly login using IS. But in some
> scenario social login will also continue to be there, so if the user uses
> social login, we will automatically link that to the already provisioned
> account.
>
> 2. Migrating users from a external IdP - The use case is where a company
> has done an acquisition or merger, or simply has the need to centralize the
> identity management, therefore wants to migrate all the identities from an
> external IdP to IS, and eventually once all identities are migrated may be
> disconnect the IdP even.
>
> Regards,
> Johann.
>
>
>> Why not create their user accounts in IS itself instead of federating?
>>
>
> This won't work for the social signup use case. Even for the external IdP
> migration use case, if it has to be done it has to be a manual bulk import
> process. This is sometimes difficult to do because,
> 1. We cannot get password from the external IdPs
> 2. Even to do it as a bulk admin initiated forced password reset, with the
> recent performance numbers we are seeing it is almost impossible to do it.
>
> Therefore the better option is to do it on the fly when each user wants to
> login to the application.
>
> Regards,
> Johann.
>
>
>> On Wed, Apr 11, 2018 at 9:51 AM, Menaka Jayawardena <men...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> In WSO2 Identity Server, users can be provisioned to the internal User
>>> store when the users are signing up with social accounts. But in this case,
>>> the users should always use the social login option to login to the
>>> application and the identity admins could not manage them as internal users.
>>>
>>> The main idea of this feature is to provision the users with password so
>>> that a proper user account will be created in the identity server so that
>>> they can use the user name and password to login and the identity admins
>>> can manage the users as internal users.
>>>
>>> As per the Flash PC[1], we need to consider following aspects when
>>> implementing this feature.
>>>
>>> *1. Configuring password provisioning in the IDP level.*
>>> A new option can be provided in the Just-In-Time Provision section to
>>> enable/ disable provisioing with password.
>>>
>>> *2. Prompting a page to get the user claims and password*
>>> When a user is using social sign up, in the sign up flow, new page will
>>> be shown with the claims. The claims that are retrieved from the social
>>> signup response will be automatically populated. Users need to fill any
>>> mandatory claims that are missing in the request as well as they need to
>>> provide a valid password.
>>>
>>>
>>> *3. How multiple social accounts can be associated*This applies when we
>>> support multiple social signup options (Facebook, Google, Twitter etc).
>>> When a user has already signed up with one social account, after some
>>> time, he/she again tries to signup using a different account.
>>> As different social accounts use differnt ids for users, there shoul be
>>> a mechanism to map the values to the existing user.
>>>
>>> As a solution for this we can allow users to add their other social
>>> account details in the user profile. So, when the user is trying to sign up
>>> using

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Nuwan Dias]

Provisioning users with a known/proper password would make it possible for
them to login/authenticate directly against IS without being authenticated
against the federated IDP right? Do we really want to allow that? If
internal admins want to manage their accounts internally, or if we want
users to login/authenticate to IS directly, why would they authenticate
against a federated IDP in the first place? Why not create their user
accounts in IS itself instead of federating?

On Wed, Apr 11, 2018 at 9:51 AM, Menaka Jayawardena <men...@wso2.com> wrote:

> Hi,
>
> In WSO2 Identity Server, users can be provisioned to the internal User
> store when the users are signing up with social accounts. But in this case,
> the users should always use the social login option to login to the
> application and the identity admins could not manage them as internal users.
>
> The main idea of this feature is to provision the users with password so
> that a proper user account will be created in the identity server so that
> they can use the user name and password to login and the identity admins
> can manage the users as internal users.
>
> As per the Flash PC[1], we need to consider following aspects when
> implementing this feature.
>
> *1. Configuring password provisioning in the IDP level.*
> A new option can be provided in the Just-In-Time Provision section to
> enable/ disable provisioing with password.
>
> *2. Prompting a page to get the user claims and password*
> When a user is using social sign up, in the sign up flow, new page will be
> shown with the claims. The claims that are retrieved from the social signup
> response will be automatically populated. Users need to fill any mandatory
> claims that are missing in the request as well as they need to provide a
> valid password.
>
>
> *3. How multiple social accounts can be associated*This applies when we
> support multiple social signup options (Facebook, Google, Twitter etc).
> When a user has already signed up with one social account, after some
> time, he/she again tries to signup using a different account.
> As different social accounts use differnt ids for users, there shoul be a
> mechanism to map the values to the existing user.
>
> As a solution for this we can allow users to add their other social
> account details in the user profile. So, when the user is trying to sign up
> using another account he/she will be logged into the existing account.
>
> *4. What are the user claims that we should retrieve from the social
> account and do we allow users to edit those claims.*
> As we show the claims that are retrieved from the signup request, have to
> decide whether we allow users to modify those details. As per the
> discussion [1] we only allow to edit the exact claims that can be edited in
> the user profile.
>
> I have written the use cases that will be involved in this use case and
> attached herewith.
> https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_
> 2F9Ezk_WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing
>
> Any ideas suggestions are highly appreciated.
>
> [1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm
> (IST) (Rapid Response Group)
>
> Thanks and Regards,
> Menaka
> --
> *Menaka Jayawardena*
> Software Engineer
> WSO2 Inc.
>
> Phone: +94 71 350 5470
> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
> Blog   : https://menakamadushanka.wordpress.com/
>
>


-- 
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] Remove Application and user access token concept from API Manager

[Nuwan Dias]

+1. In API Manager 3.0 we did not introduce such a concept anyway. Are you
suggesting we remove this from 2.x as well?

On Thu, 29 Mar 2018 at 1:17 pm, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> Hi All,
> In API Manager we have application access token and user access token
> concept. Application access token is the token obtained using resource
> owner grant type. User access token is the token obtained by user(can be
> application owner or someone else) by using any grant type. Initially we
> introduced this feature to control resource level access of APIs.
>
> As example we can think of one API(camera API) which has 2
> resources(1.View photo 2.Add photo). Then we will need to let users to view
> photos without login to system(means obtain token for user). In that case
> we can limit view resource to application access token and mandate to use
> user token to add photo. This way we can maintain resource access control.
>
> With scopes concept we can still do same. We can give read scope to view
> photo and generate token for that embed with app. If user need to take
> photo then he will have to get token with write(access add photo) scope. In
> oauth spec also we cannot see this type of differentiation. So considering
> all these shall we remove application access token concept from API
> Manager?  Any limitations with this?
>
> Thanks,
> sanjeewa.
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> <http://sanjeewamalalgoda.blogspot.com/>blog
> :http://sanjeewamalalgoda.blogspot.com/
> <http://sanjeewamalalgoda.blogspot.com/>
>
>
> --
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] [APIM] Json Schema Validation

[Nuwan Dias]

AFAIK we can have rxt fields as optional. Or worst case add fields to the
rxt on demand, during update. Let’s try and avoid properties since it
causes data of the same api to be in different places.

On Fri, 16 Mar 2018 at 10:32 am, Megala Uthayakumar <meg...@wso2.com> wrote:

> Hi Nuwan/Sanjeewa/APIM Team,
>
> Since we need a way to keep track of whether json schema validation is
> enabled or not for a particular API, shall we go ahead with a regsitry
> property for this, as we did for publisher access control feature before?
>
> If we are going with an attribute, we may need to modify the RXT and there
> will be a migration for old APIs. What would be the recommended way of
> doing this?
>
> Thanks.
>
> Regards,
> Megala
>
> On Thu, Mar 15, 2018 at 10:39 PM, Chamin Dias <cham...@wso2.com> wrote:
>
>> Hi,
>>
>> On Thu, Mar 15, 2018 at 2:44 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
>> wrote:
>>
>>> Hi Sivaramya,
>>> Its always good to start with complete swagger sample hosted by swagger.
>>> If you look at APIs deployed here then different paths accept different
>>> request payloads.
>>> How are we adding resource accordingly? Is that local entry UUID passed
>>> to class mediator knows resource specific schema? If so there can be
>>> multiple entries per API.
>>>
>>> Also lets think about cleaning local entries when we disable this.
>>> Otherwise they will be remain in gateways.
>>>
>>> [1]
>>> https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v2.0/json/petstore-simple.json
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Wed, Mar 14, 2018 at 4:39 PM, Sivaramya Sivanathan <
>>> sivara...@wso2.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Currently, I'm working on the Json Schema Validation for API manager. When
>>>> we execute a API request,  we need to do the Json schema validation so that
>>>> we can reduce the backend failures and also we can protect the gateways.
>>>> For this feature the proposed method is as follows,
>>>>
>>>>-
>>>>
>>>>Add the Json schema to the swagger file as mentioned below, so that
>>>>we can validate the request using the swagger file.
>>>>
>>>> *"parameters": [*
>>>>
>>>> *  {*
>>>>
>>>> *"name": "Product",*
>>>>
>>>> *"description": "A product from the catalog",*
>>>>
>>>> *"required": false,*
>>>>
>>>> *"in": "body",*
>>>>
>>>> *"schema": {*
>>>>
>>>> *  "type": "object",*
>>>>
>>>> *  "properties": {*
>>>>
>>>> *"id": {*
>>>>
>>>> *  "type": "number",*
>>>>
>>>> *  “Description”: “The unique identifier for a product”*
>>>>
>>>> *},*
>>>>
>>>> *"name": {*
>>>>
>>>> *  "type": "string",*
>>>>
>>>> *  “Description”: “Name of the product”*
>>>>
>>>> *},*
>>>>
>>>> * "price": {*
>>>>
>>>> *  "type": "number",*
>>>>
>>>> *  “minimum”: 0*
>>>>
>>>> *  }*
>>>>
>>>> *}*
>>>>
>>>> *  }*
>>>>
>>>> *],*
>>>>
>>>>
>>>>- Add a new check-box to enable the json-schema in UI in the
>>>>publisher level.
>>>>- If check-box enabled, at the point of generating API synapse
>>>>configuration, we can add the schema to a local entry which the name of 
>>>> the
>>>>local entry will be UUID + api+ resource version.
>>>>- We can add a property to hold the local entry name related with
>>>>UUID and add a class mediator inside each resource definition.
>>>>- Class mediator should make use of that property to get the schema
>>>>
>>>> In this situatio

Re: [Architecture] APIM3 Security For Exposed REST APIs

[Nuwan Dias]

IMO we will need to have two interceptor layers. One for the carbon-apimgt
repo and another for the carbon-auth repo. The interceptor in the
carbon-apimgt layer will have to solely rely on the KeyManager interface.
The default implementation of the KeyManager interface will have to rely on
the functionalities offered by the authenticators in the carbon-auth repo.
The interceptors in the carbon-auth repo will solely rely on the
authenticators in its own repo. It'll be only the authenticators that will
know how to create and validate keys and tokens.

On Fri, Feb 23, 2018 at 1:04 PM, Harsha Kumara <hars...@wso2.com> wrote:

> As per the @Bhathiya, we can separate the IDP and KeyManager interfaces
> separately. With current state, it's possible to plug a third-party key
> manager without affecting to REST API security.
>
> On Thu, Feb 22, 2018 at 6:15 PM, Pubudu Gunatilaka <pubu...@wso2.com>
> wrote:
>
>> Hi Harsha,
>>
>> On Thu, Feb 22, 2018 at 5:33 PM, Harsha Kumara <hars...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> This is to discuss the security of REST APIs exposed from carbon-auth
>>> and carbon-apimgt components. We are mainly using OAuth as primary
>>> protection for the REST APIs and scopes are used as the authorization
>>> purposes. Currently following APIs are exposed from the components lies in
>>> these two main repositories.
>>>
>>> *carbon-apimgt*
>>>
>>> Protected APIs with OAuth
>>> -  /api/am/publisher/v1.0 - Publisher REST APIs
>>> -  /api/am/store/v1.0  - Store REST APIs
>>> - /api/am/admin/v1.0 - Admin REST APIs
>>> - /api/am/analytics/v1.0 - Analytic REST APIs
>>>
>>>
>> We have another REST API called core API (/api/am/core/v1.0) which is for
>> internal server communications. This is planned to secure by mutual ssl.
>>
>> Thank you!
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Senior Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <+94%2077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



-- 
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] [C4] Single location to configure Privacy and Security Policy URL

[Nuwan Dias]

On Wed, Feb 21, 2018 at 3:46 PM, Isura Karunaratne <is...@wso2.com> wrote:

> Hi Ruwan,
>
> On Wed, Feb 21, 2018 at 3:28 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
>
>> Hi All,
>>
>> In order to comply with GDPR regulations, we are planning to incorporate
>> privacy and cookie policy URL configuration into carbon 4 "carbon.xml" .
>> The following element will be added to "carbon.xml", as this needs to be
>> available fr any product based on c4.
>> This configuration will be disabled (commented out) by default, in which
>> hard-coded URL shall be displayed by each UI.
>>
>> 
>> 
>> 
>> 
>> https://your.organozation/privacy/privacy-policy.html
>>
>>
> Shouldn't this be a tenant wise configuration?
>

Since all the web apps we ship by default are SaaS apps (all tenants login
to the same app) I think its fine for this to be a server config.

>
> Thanks
> Isura.
>
>>
>> 
>> 
>> https://your.organozation/privacy/cookie-policy.html
>> 
>>
>>
>> Furthermore, We will add following methods to "CarbonUtils.java" to
>> access the above two properties. These methods may return null, in which,
>> the relevant UI should render a default link for the respective policy URL.
>>
>> String getPrivacyPolicyURL()
>> String getCookiePolicyURL()
>>
>>
>> Cheers,
>> Ruwan
>>
>>
>
>
> --
>
> *Isura Dilhara Karunaratne*
> Associate Technical Lead | WSO2
> Email: is...@wso2.com
> Mob : +94 772 254 810 <+94%2077%20225%204810>
> Blog : http://isurad.blogspot.com/
>
>
>
>


-- 
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] Clearly defining what operations users can perform on a shared application in APIM

[Nuwan Dias]

On Wed, Feb 7, 2018 at 11:14 AM, Uvindra Dias Jayasinha <uvin...@wso2.com>
wrote:

> Hi All,
>
> It seems that currently we do not have a clear definition in regarding
> what users can do with shared applications. This has been highlighted in[1]
> and the plan is to address this as part of the APIM 2.2.0 release.
>
> There are two types of users, the *App owner* who creates the App and the 
> *shared
> user* who is able to view the App that is shared with them by the App
> owner.
>
> *Current issues*
> 1. Product allows shared users to attempt updating Apps that are not owned
> by them, which leads to errors because they do not have the required
> permissions.
>
> 2. Product allows shared users to delete Apps that are not owned by them
> which violate the Application ownership concept.
>
> The plan to address this is as follows
>
> *Solution*
> 1. *App Owner *: Has ability to delete/update Apps owned by them.
>
> 2. *Shared user*: Has only Read only access to Apps shared with
> them(cannot delete/update).
> Deletion and updation of Apps will be restricted at API Store UI level.
> App ownership will be   checked before performing App update/delete from
> server side in  order to   enforce this for REST API calls
>

Shared user needs to view, remove and add subscriptions too IMO.

>
> 3 *Admin shared user* : Has ability to delete/update Apps shared with
> them. The reason for this is to address practical issues that take place
> when the App owner leaves an organization and there needs to be some way to
> delete/update such an Application.
>

+1

>
>
> Please give your feedback on the above.
>
>
> [1] https://github.com/wso2/product-apim/issues/2690
> --
> Regards,
> Uvindra
>
> Mobile: 33962
>



-- 
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] Can we ship Identity Management / Identity Governance features with APIM by default.

[Nuwan Dias]

On Mon, Feb 5, 2018 at 12:36 PM, Asela Pathberiya <as...@wso2.com> wrote:

>
>
> On Mon, Feb 5, 2018 at 12:10 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>> As mentioned on the subject itself, these are Identity Management and
>> Identity Governance features. They don't closely tie in with API
>> Management. Therefore I think its fine to recommend IS for those kind of
>> use cases.
>>
>> Installing these features to APIM at this point in time is also a problem
>> due to its roadmap with 3.0. If we install these features into APIM users
>> will see these as first class features of our APIM offering, they won't see
>> this as something coming from IS.
>>
>
> APIM store is public facing for end users.  It already supports for user
> registration which is also identity management feature.  It is a question,
> why can't it support  features such as  password recovery/policies/email
> activation by default.
>

Its not that it can't. Its a question of where do we draw the line between
IS and APIM. My opinion is that the current user registration (with
workflow support) and password reset options are just enough for the OOTB
product. You can have many more scenarios than listed above. Such as Login
with Facebook, Multifactor Authentication, etc and the list could go on. I
think its fine to ask users to integrate with IS for advanced scenarios.

>
> If product supports for public user registration, it must support for all
> other identity management features as well.
>
> Are we removing the user registration from APIM 3.0 ?
>

No, that would be there. But we don't have plans to support anything else.
Since there's no C5 based IS yet, we are writing all the user management
capabilities from scratch to even get the basic functionality. The need to
support more and more scenarios would create a lot more work than already
planned. Risking its deadlines.

>
> Thanks,
> Asela.
>
>
>> Which means that users would expect the same set of features on 3.0 as
>> well. Therefore I would be -1 to installing these features on APIM.
>>
>> On Mon, Feb 5, 2018 at 9:49 AM, Asela Pathberiya <as...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> There are several customers/users who are looking for $subject with
>>> APIM.  Specially following features
>>>
>>> 1. Account lock/disable
>>> 2. Password/Account recovery
>>> 3. Password policies
>>>
>>> We are usually not recommending the feature installation.  Therefore,
>>> shall we ship these features by default with APIM.
>>>
>>> However, we can suggests to use WSO2IS as KM,  but we need to consider on
>>>
>>> 1.  Cost on running WSO2IS (infra cost)
>>> 2.  All in one deployment
>>> 3.  First impression on the IAM feature list of APIM.
>>>
>>> WDYT ?
>>>
>>> Thanks,
>>> Asela.
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>>      +358 449 228 979
>>>
>>> http://soasecurity.org/
>>> http://xacmlinfo.org/
>>>
>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>



-- 
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] Can we ship Identity Management / Identity Governance features with APIM by default.

[Nuwan Dias]

As mentioned on the subject itself, these are Identity Management and
Identity Governance features. They don't closely tie in with API
Management. Therefore I think its fine to recommend IS for those kind of
use cases.

Installing these features to APIM at this point in time is also a problem
due to its roadmap with 3.0. If we install these features into APIM users
will see these as first class features of our APIM offering, they won't see
this as something coming from IS. Which means that users would expect the
same set of features on 3.0 as well. Therefore I would be -1 to installing
these features on APIM.

On Mon, Feb 5, 2018 at 9:49 AM, Asela Pathberiya <as...@wso2.com> wrote:

> Hi All,
>
> There are several customers/users who are looking for $subject with APIM.
> Specially following features
>
> 1. Account lock/disable
> 2. Password/Account recovery
> 3. Password policies
>
> We are usually not recommending the feature installation.  Therefore,
> shall we ship these features by default with APIM.
>
> However, we can suggests to use WSO2IS as KM,  but we need to consider on
>
> 1.  Cost on running WSO2IS (infra cost)
> 2.  All in one deployment
> 3.  First impression on the IAM feature list of APIM.
>
> WDYT ?
>
> Thanks,
> Asela.
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>



-- 
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] [GDPR] API Manager 3.0.0 GDPR Support

[Nuwan Dias]

Hi all,

When this is done up to some extent let's have a code review. I'm still
struggling to understand the difference between user_id and pseudo name.
And wondering whether we actually need a user_id concept if we implement
something based on a pseudo name or vice versa.

Just to be clear on the GDPR expectations, processing data with usernames
in memory has absolutely no problem in terms of GDPR compliance. The only
problem occurs when/if we persist a username somewhere. So as long as we
don't log a username and don't write to a DB or file, we're good. Since
developers have access to the username at the development time, they can
still log it or write it to a DB or file anyway.

@Shani, GDPR compliance rules apply over other rules. It's not intended to
override other organizational rules. So if a particular organization has a
policy to retain user data for 6 months and the user has consented to that,
the user only has the "right to be forgotten" after the 6 months has
passed. Until then the organization has the right to hold on to that data.

Thanks,
NuwanD.

On Fri, Feb 2, 2018 at 11:11 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> Nuwan, All,
> When we are calling with external systems such as scim we will use user
> ID. But internal flow manly goes with user name. Each time when rest API
> get hit with call we will call getUserName() method with http request and
> it resolve user name. That particular user name passed all through system
> and get recorded in databases, log files etc.
>
> Whenever we call SCIM etc we get relevant user id by calling identity
> provider and do following calls with user id. Still even with SCIM in place
> user name is available all through implementation. Please see below code
> which we use to interact with external identity provider. As you can see we
> use id only when communicate with identity providers. So above suggested
> implementation is a must.
>
> String userId = getIdentityProvider().getIdOfUser(userName);
> roles = new HashSet<>(getIdentityProvider().getRoleIdsOfUser(userId));
>
> What i'm doing is call follwing method before we need actual user name. So
> i had to place this line above code block.
> So i can use pseudo name all over the implementation.
>
> String userName =
> APIUtils.getLoggedInUsernameFromPseudoName(user);
>
> Thanks,
> sanjeewa.
>
> On Fri, Feb 2, 2018 at 10:07 AM, Malintha Amarasinghe <malint...@wso2.com>
> wrote:
>
>> Hi Nuwan,
>>
>> Looks like there are several places we are using usernames as it is. Eg:
>> provider, business owner, technical owner names in API table, CREATED_BY,
>> UPDATED_BY audit columns in all the resource tables. There can be several
>> other places. We need to fix those places to use UUIDs. I guess we can use
>> this UUID itself as the pseudo name.
>>
>> When SCIM comes into place, we will be getting a UUID for each user. We
>> should be able to store it instead of the username in above places. But not
>> sure whether we need to (persist/keep in memory in a map) username - UUID
>> mapping in APIM side too, otherwise we need to give SCIM call to get the
>> real username when needed all the time.
>>
>> On Fri, Feb 2, 2018 at 8:55 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> Hi Sanjeewa,
>>>
>>> Can you post a chunk of code that benefits from this mapping in relation
>>> to GDPR compliance? Basically I want to understand how a chunk of code that
>>> wasn't GDPR compliant before becomes GDPR compliant due to this mapping.
>>>
>>> I was under the impression that APIM v3.0 works on user ids and not on
>>> user names. User names are only used in responses, UIs, for calling other
>>> services, etc. Which means that this user id is anyway a pseudo name. The
>>> reason for this decision was to address a set of problems in C4 products
>>> such as inability to change a username, problems with the same user in
>>> different cases, etc. Meaning that APIM v3 was already GDPR compliant in
>>> that sense. It we now have to build an addition layer to make the code GDPR
>>> compliant, we've basically lost our design objective of using user ids
>>> instead of usernames.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Thu, Feb 1, 2018 at 6:05 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
>>> wrote:
>>>
>>>> Hi All,
>>>> Recently we evaluated GDPR requirement(right to be forgotten) for API
>>>> Manager 3.0.0 development. Our primary focus was to find a way to implement
>>>> "right to be forgotten" without effecting core logic of the system(with
&

Re: [Architecture] [GDPR] API Manager 3.0.0 GDPR Support

[Nuwan Dias]

Hi Sanjeewa,

Can you post a chunk of code that benefits from this mapping in relation to
GDPR compliance? Basically I want to understand how a chunk of code that
wasn't GDPR compliant before becomes GDPR compliant due to this mapping.

I was under the impression that APIM v3.0 works on user ids and not on user
names. User names are only used in responses, UIs, for calling other
services, etc. Which means that this user id is anyway a pseudo name. The
reason for this decision was to address a set of problems in C4 products
such as inability to change a username, problems with the same user in
different cases, etc. Meaning that APIM v3 was already GDPR compliant in
that sense. It we now have to build an addition layer to make the code GDPR
compliant, we've basically lost our design objective of using user ids
instead of usernames.

Thanks,
NuwanD.

On Thu, Feb 1, 2018 at 6:05 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> Hi All,
> Recently we evaluated GDPR requirement(right to be forgotten) for API
> Manager 3.0.0 development. Our primary focus was to find a way to implement
> "right to be forgotten" without effecting core logic of the system(with
> minimum changes). Following is the design we came up. We will be able to
> utilize same design for other products(who used same development
> methodology) as well. In API Manager 3.0.0 we do have set of MSF4J based
> micro services. Then ReactJS based apps developed on top of these APIs.
> Micro services directly call API publisher, store and admin
> implementations(via APIs). So what we did was intercept each API call and
> change user name to pseudo name.
>
> To do this we have utility functions which maps real user to pseudo users
> and vise versa. It works like this.
>
>- If pseudo name/username available in map then get mapping and return
>mapped value.
>- Else check mapping in database and load it to local map. Then return
>mapped value.
>- If mapping is not in database then add it to db and map. Then return
>mapped value.
>
> And if we need to disable GDPR support due to some reason then above
> mentioned utility methods can return same attribute passed. Then it will
> not change anything and real user name will be used inside implementation.
>
> So as you can see in below image, API Manager implementation(boundary
> marked with green dash line) works only with pseudo name. Whenever it
> communicates with API layer or any other external system(two boxes
> connected to green box) we will change pseudo name to real user name. I
> have done a quick test with this implementation and now everything(logs, db
> entries, files etc) getting recorded with pseudo name. So whenever we need
> to delete user we just have to delete user and remove mapping. Our plan is
> to do same for light weight auth framework as well.
>
>
> ​​
>
> I would like to know others opinion on this before move forward.
>
> Thanks,
> sanjeewa.
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.
> blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
>
>
>


-- 
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] [RRT] [IAM] Hash code, access token, refresh token and client secret values before store them in the database

[Nuwan Dias]

On Mon, Jan 29, 2018 at 1:15 PM, Isura Karunaratne <is...@wso2.com> wrote:

>
>
> On Mon, Jan 29, 2018 at 1:10 PM, Dimuthu Leelarathne <dimut...@wso2.com>
> wrote:
>
>> Hi Nuwan,
>>
>> On Mon, Jan 29, 2018 at 1:08 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> Hi Dimuthu,
>>>
>>> I don't think we can regenerate since the client-secret will be hashed
>>> too. So I think we have to completely disable showing the test token and
>>> remove it off from the Swagger Console as well.
>>>
>> Can't we use clientId to regrenate client secret.
>

I was actually referring to regenerating the access token since that's what
the "Regenerate" button does.

>
> Thanks
> Isura.
>
>>
>>> Yes. Or we can get it as input.
>>
>>
>>> We may also have to think of providing a mechanism to renew the
>>> client-secret if/when lost.
>>>
>>
>> I meant regnerate client secret itself, not the access token.
>>
>> thanks,
>> Dimuthu
>>
>>
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>>
>>>
>
>
> --
>
> *Isura Dilhara Karunaratne*
> Associate Technical Lead | WSO2
> Email: is...@wso2.com
> Mob : +94 772 254 810 <+94%2077%20225%204810>
> Blog : http://isurad.blogspot.com/
>
>
>
>


-- 
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] [APIM] CLI support for Importing and Exporting Applications

[Nuwan Dias]

On Thu, 25 Jan 2018 at 10:00 pm, Rajkumar Rajaratnam <rajkum...@wso2.com>
wrote:

> On Thu, Jan 25, 2018 at 10:27 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>>
>> On Thu, 25 Jan 2018 at 9:24 pm, Rajkumar Rajaratnam <rajkum...@wso2.com>
>> wrote:
>>
>>> Hi Nuwan, Randilu,
>>>
>>> Would like to understand this feature a bit.
>>>
>>>- I hope this is about exporting/importing OAuth applications which
>>>subscribers create in dev portal, right? Is this CLI invoking Store REST
>>>API?
>>>
>>> yes it does.
>>
>>>
>>>- If I wish to export the subscription, is there way to pick and
>>>choose the subscriptions I want? If not, what happens if some of these 
>>> APIs
>>>are not available in the upper environment while importing the 
>>> application?
>>>The operation will fail altogether or we print some warnings and proceed?
>>>
>>> You can either export with or without subscriptions. You can’t pick and
>> choose right now.
>>
>>>
>>>- Can I update the existing application, without deleting and
>>>importing it again?
>>>
>>>
>>>- When I import an application with subscriptions, does it
>>>auto-create the consumer key/secrets?
>>>
>>> No. This is intended to move apps across environments. It is unlikely
>> someone would reuse the same credentials across environments.
>>
>
> ​I mean, it doesn't have to be same credential, but does it create
> consumer key/secret for me or I have to create it manually after I import
> the application into an environment for the first time?​
>

At the moment it doesn’t create new credentials as well.

>
>> Thanks.
>>>
>>> On Thu, Jan 25, 2018 at 8:26 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>> Hi Randilu,
>>>>
>>>> I don't think we can expect dev-ops persona to provide the UUID of the
>>>> application when exporting. He/She needs to be able to provide the name and
>>>> owner of the application and export. If we don't have APIs that can
>>>> retrieve Applications with that input we need to introduce them IMO.
>>>>
>>>> I also think we need to export subscriptions by default when we export
>>>> an App. If someone wants to prevent exporting subscriptions then we should
>>>> provide a flag to skip exporting subscriptions.
>>>>
>>>> Thanks,
>>>> NuwanD.
>>>>
>>>> On Thu, Jan 25, 2018 at 5:41 PM, Randilu Soysa <rand...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I’m working on a project to introduce commands to provide application
>>>>> import export support for the import-export-cli for APIM 2.x. I am 
>>>>> planning
>>>>> to introduce commands in order to list available applications of a 
>>>>> specific
>>>>> user, export an application from a desired environment and import an
>>>>> application to a desired environment.
>>>>>
>>>>>
>>>>> The commands are as follows,
>>>>>
>>>>>
>>>>> Exports an Application from a desired environment
>>>>>
>>>>> Commands
>>>>>
>>>>> export-app
>>>>>
>>>>> Flags
>>>>>   Required
>>>>> -n, --name string  Name of the Application to be exported
>>>>> -i, --uuid string  UUID of the Application to be exported
>>>>> -e, --environment string   Environment from which the Application 
>>>>> should be exported
>>>>>   Optional
>>>>> -p, --password string  Password
>>>>> -u, --username string  Username
>>>>>
>>>>> -k, --insecure Allow connections to SSL endpoints 
>>>>> without certs
>>>>> --verbose  Enable verbose mode
>>>>>
>>>>> apimcli export-app (--name  --uuid 
>>>>>  --environment 
>>>>> ) [flags]
>>>>>
>>>>> Examples:
>>>>>
>>>>> apimcli export-app -n SampleApp 
>>>>> 9f6affe2-4c97-4817-bded-717f8b01eee8 -e dev
>>>>> apimcli export-app -n SampleApp 
>

Re: [Architecture] [APIM] CLI support for Importing and Exporting Applications

[Nuwan Dias]

On Thu, 25 Jan 2018 at 9:24 pm, Rajkumar Rajaratnam <rajkum...@wso2.com>
wrote:

> Hi Nuwan, Randilu,
>
> Would like to understand this feature a bit.
>
>- I hope this is about exporting/importing OAuth applications which
>subscribers create in dev portal, right? Is this CLI invoking Store REST
>API?
>
> yes it does.

>
>- If I wish to export the subscription, is there way to pick and
>choose the subscriptions I want? If not, what happens if some of these APIs
>are not available in the upper environment while importing the application?
>The operation will fail altogether or we print some warnings and proceed?
>
> You can either export with or without subscriptions. You can’t pick and
choose right now.

>
>- Can I update the existing application, without deleting and
>importing it again?
>
>
>- When I import an application with subscriptions, does it auto-create
>the consumer key/secrets?
>
> No. This is intended to move apps across environments. It is unlikely
someone would reuse the same credentials across environments.

Thanks.
>
> On Thu, Jan 25, 2018 at 8:26 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>> Hi Randilu,
>>
>> I don't think we can expect dev-ops persona to provide the UUID of the
>> application when exporting. He/She needs to be able to provide the name and
>> owner of the application and export. If we don't have APIs that can
>> retrieve Applications with that input we need to introduce them IMO.
>>
>> I also think we need to export subscriptions by default when we export an
>> App. If someone wants to prevent exporting subscriptions then we should
>> provide a flag to skip exporting subscriptions.
>>
>> Thanks,
>> NuwanD.
>>
>> On Thu, Jan 25, 2018 at 5:41 PM, Randilu Soysa <rand...@wso2.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I’m working on a project to introduce commands to provide application
>>> import export support for the import-export-cli for APIM 2.x. I am planning
>>> to introduce commands in order to list available applications of a specific
>>> user, export an application from a desired environment and import an
>>> application to a desired environment.
>>>
>>>
>>> The commands are as follows,
>>>
>>>
>>> Exports an Application from a desired environment
>>>
>>> Commands
>>>
>>> export-app
>>>
>>> Flags
>>>   Required
>>> -n, --name string  Name of the Application to be exported
>>> -i, --uuid string  UUID of the Application to be exported
>>> -e, --environment string   Environment from which the Application 
>>> should be exported
>>>   Optional
>>> -p, --password string  Password
>>> -u, --username string  Username
>>>
>>> -k, --insecure Allow connections to SSL endpoints 
>>> without certs
>>> --verbose  Enable verbose mode
>>>
>>> apimcli export-app (--name  --uuid 
>>>  --environment 
>>> ) [flags]
>>>
>>> Examples:
>>>
>>> apimcli export-app -n SampleApp 
>>> 9f6affe2-4c97-4817-bded-717f8b01eee8 -e dev
>>> apimcli export-app -n SampleApp 
>>> 7bc2b94e-c6d2-4d4f-beb1-cdccb08cd87f -e prod
>>>
>>>
>>>
>>> <https://github.com/randilu/WatchOver/new/master?readme=1#imports-an-application-to-a-desired-environment>Imports
>>> an Application to a desired environment
>>>
>>> Commands
>>>
>>> import-app
>>>
>>> Flags
>>> Required
>>>   -f, --file string  Name of the Application to be imported
>>>   -e, --environment string   Environment from the which the 
>>> Application should be imported
>>> Optional
>>>   -s, --addSubscriptions Adds subscriptions of the Application
>>>   -o, --perserveOwnerPreserves app owner from the original 
>>> Environment
>>>   -p, --password string  Password
>>>   -u, --username string  Username
>>>
>>>   -k, --insecure Allow connections to SSL endpoints 
>>> without certs
>>>   --verbose  Enable verbose mode
>>>
>>> apimcli import-app (--file  --environment 
>>> ) [flags]
>>>
>>> Examples:
>>>
&g

Re: [Architecture] [APIM] CLI support for Importing and Exporting Applications

[Nuwan Dias]

Hi Randilu,

I don't think we can expect dev-ops persona to provide the UUID of the
application when exporting. He/She needs to be able to provide the name and
owner of the application and export. If we don't have APIs that can
retrieve Applications with that input we need to introduce them IMO.

I also think we need to export subscriptions by default when we export an
App. If someone wants to prevent exporting subscriptions then we should
provide a flag to skip exporting subscriptions.

Thanks,
NuwanD.

On Thu, Jan 25, 2018 at 5:41 PM, Randilu Soysa <rand...@wso2.com> wrote:

> Hi everyone,
>
> I’m working on a project to introduce commands to provide application
> import export support for the import-export-cli for APIM 2.x. I am planning
> to introduce commands in order to list available applications of a specific
> user, export an application from a desired environment and import an
> application to a desired environment.
>
>
> The commands are as follows,
>
>
> Exports an Application from a desired environment
>
> Commands
>
> export-app
>
> Flags
>   Required
> -n, --name string  Name of the Application to be exported
> -i, --uuid string  UUID of the Application to be exported
> -e, --environment string   Environment from which the Application 
> should be exported
>   Optional
> -p, --password string  Password
> -u, --username string  Username
>
> -k, --insecure Allow connections to SSL endpoints without 
> certs
> --verbose  Enable verbose mode
>
> apimcli export-app (--name  --uuid 
>  --environment 
> ) [flags]
>
> Examples:
>
> apimcli export-app -n SampleApp 9f6affe2-4c97-4817-bded-717f8b01eee8 
> -e dev
> apimcli export-app -n SampleApp 7bc2b94e-c6d2-4d4f-beb1-cdccb08cd87f 
> -e prod
>
>
>
> <https://github.com/randilu/WatchOver/new/master?readme=1#imports-an-application-to-a-desired-environment>Imports
> an Application to a desired environment
>
> Commands
>
> import-app
>
> Flags
> Required
>   -f, --file string  Name of the Application to be imported
>   -e, --environment string   Environment from the which the 
> Application should be imported
> Optional
>   -s, --addSubscriptions Adds subscriptions of the Application
>   -o, --perserveOwnerPreserves app owner from the original 
> Environment
>   -p, --password string  Password
>   -u, --username string  Username
>
>   -k, --insecure Allow connections to SSL endpoints 
> without certs
>   --verbose  Enable verbose mode
>
> apimcli import-app (--file  --environment 
> ) [flags]
>
> Examples:
>
> apimcli import-app -f qa/sampleApp.zip -e dev
> apimcli import-app -f staging/sampleApp.zip -e prod -u admin -p admin
> apimcli import-app -f qa/sampleApp.zip --preserveOwner 
> --addSubscriptions -e prod
>
>
>
> <https://github.com/randilu/WatchOver/new/master?readme=1#lists-the-applications-available-for-a-certain-user>Lists
> the Applications available for a certain user
>
> Commands
>
> list apps
>
> Flags
> Required
> -e, --environment
> Optional
> -u, --username
> -p, --password
>
>
> Examples:
>
> apimcli list apps -e dev
> apimcli list apps -e staging
> apimcli list apps -e staging -u admin -p 123456
> apimcli list apps -e staging -u admin
> apimcli list apps -e staging -p 123456
>
>
> Your suggestions and feedback on this is highly appreciated!
>
>
> --
> *Randilu Soysa*
> Software Engineering Intern | WSO2
>
> Email: rand...@wso2.com
> Mobile   : +94 77 197 5078 <+94%2077%20197%205078>
> linkedin : linkedin.com/in/randilusoysa
> Web  : http://wso2.com
>
> <http://wso2.com/signature>
>



-- 
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] OpenAPI 3.0 support for API Manager 2.2.0

[Nuwan Dias]

My concern is on the folks who aren’t even aware of the oas version being
used. When someone is creating an api on the UI, they’ll feel as if the SDK
generation has vanished (if we disable it for v3 ones). Therefore it’ll be
better to make v2 the default and provide a warning on the UI regarding
SDKs when switching to 3.0.

On Thu, 25 Jan 2018 at 11:46 am, Thilini Shanika <thili...@wso2.com> wrote:

> If someone creates an API from the UI, the default swagger doc will be in
> version 3 right? Can a developer switch back to a 2.0 based definition if
> so?
>
> As per the current implementation, the default version of the generation
> swagger doc is a version 3.0.0 supported doc. But the publisher user can
> selectively decide the supported swagger version, in the advanced option
> provided at starting point of API creation.
>
> Initially, we tried to provide the functionality of switching the API spec
> version in API design phase but then we faced some difficulties to handle
> the swagger doc conversion of 2.0 -> 3.0.0 and 3.0.0 -> 2.0 and we could
> not find any third party library to handle this conversion. We can write a
> conversion for the basic swagger definition we generate underneath, but in
> a case where the user edits the swagger doc via the swagger editor, and
> adds some complex definitions to api doc, then we need to consider them as
> handle those complex definition conversions too.
>
> Further, we tried to maintain two swagger definition objects for OAS 3.0
> and Swagger 2.0.0, and as we perform different operations via API design
> phase, both objects will be updated as per the operation (ie: Adding new
> resource, parameters). Once the user switched the swagger version, the
> requested swagger definition will be loaded as the API's swagger doc. But
> that was not a clean way of handling the conversion so that we decided to
> stick to the current approach of specifying the swagger definition at api
> create staring point.
>
>
>
> [image: Inline image 1]
>
>
>
> On Thu, Jan 25, 2018 at 11:07 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>> If someone creates an API from the UI, the default swagger doc will be in
>> version 3 right? Can a developer switch back to a 2.0 based definition if
>> so?
>>
>> On Thu, 25 Jan 2018 at 9:45 am, Thilini Shanika <thili...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> We have been supporting client side SDK generation via API Store and API
>>> Store REST APIs, for swagger 2.0 based definitions. But currently, we are
>>> unable to support this particular feature fo OAS 3 based APIs, since the
>>> swagger codegen 3.x version, which is having OAS 3.0.0 support, is not
>>> released yet.
>>>
>>> Thus, shall we disable this functionality for OAS 3 specific APIs?
>>> Basically, we should disable the SDK generation via API Store and REST
>>> APIs, if it is an OAS 3.0.0 based API.
>>>
>>> WDYT?
>>>
>>>
>>> On Wed, Jan 10, 2018 at 10:54 AM, Thilini Shanika <thili...@wso2.com>
>>> wrote:
>>>
>>>> @Harsha
>>>>
>>>> In this case will our swagger console in store compatible with multiple
>>>> swagger versions? How would be the compatibility of swagger library across
>>>> multiple versions that we currently used in the product?
>>>>
>>>> Yes, it is compatible. We have upgraded Swagger UI to 3.x version,
>>>> which is having support for both Swagger 2.0 and Open API 3.0. Basically,
>>>> the current swagger ui embedded in APIM supports both versions, but we need
>>>> to carefully handle the custom elements that we inject to swagger
>>>> definition before rendering it to API Store ie: gateway environment
>>>> details, security definitions etc (There are differences of specifying API
>>>> endpoints and security definitions Swagger 2.0 and Open API 3.0)
>>>>
>>>>
>>>> @Roshan
>>>>
>>>>
>>>> Do we have a significant difference between swagger and openAPI?
>>>> According to the
>>>> https://swagger.io/blog/difference-between-swagger-and-openapi/,
>>>> swagger is a tool and openAPI is the spec it self.
>>>>
>>>> Yes, there are some significant differences between Swagger 2.0 and
>>>> Open API 3.0 spec. Please refer to [1] to have an overview understanding on
>>>> whats net in Open API 3.0. Basically swagger spec has been renamed as
>>>> OpenAPI as it was donated to Linux foundation and technically OpenAPI 3.0
>>>> is

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

[Nuwan Dias]

t;>>
>>>>>
>>>>> @Lakmal
>>>>> I moved the summery of the conversation to [1] and we can continue the
>>>>> rest of the discussion in the GitHub issue itself.
>>>>>
>>>>> On Tue, Jan 9, 2018 at 9:37 AM, Lakmal Warusawithana <lak...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Thilini,
>>>>>>
>>>>>> Shall we add this discussion into issue [1] itself.  It will be easy
>>>>>> to external party to get involve.
>>>>>>
>>>>>> On Mon, Jan 8, 2018 at 2:28 PM, Thilini Shanika <thili...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> We are planning to provide OpenAPI 3.0 specification support for API
>>>>>>> Manager 2.2.0 [1]. We did a background research on what's new in OpenAPI
>>>>>>> and the feasibility of providing OpenAPI 3.0 support over APIM 2.2.0. As
>>>>>>> per the current architecture of APIM, it is feasible to support OpenAPI 
>>>>>>> 3.0
>>>>>>> spec, parallel with Swagger 2.0 (Swagger 2.0 support is required for
>>>>>>> migrated APIs from previous releases)
>>>>>>>
>>>>>>> Following are the functionalities we are planning to ship with this
>>>>>>> new feature.
>>>>>>>
>>>>>>>1. Supporting OpenAPI 3.0 spec for newly designing/Creating APIs
>>>>>>>(When an API is created from the scratch, the underneath API 
>>>>>>> definition
>>>>>>>will be generated in OpenAPI 3.0)
>>>>>>>2. The API definitions of migrated APIs from previous releases
>>>>>>>are based on Swagger 2.0 spec. Thus, Swagger 2.0 spec support will be
>>>>>>>continued for migrated APIs
>>>>>>>3. Providing support to import OpenAPI 3.0 spec based API
>>>>>>>definitions while creating an API from an existing source.
>>>>>>>4. Swagger editor in APIM 2.2.0 has been upgraded to 3.x version
>>>>>>>so that it will be supporting OpenAPI 3.0 spec while updating API 
>>>>>>> source
>>>>>>>via Swagger Editor in API Publisher.
>>>>>>>5. Swagger UI in APIM 2.2.0 has been upgraded to 3.x version so
>>>>>>>that API Console in API Store will be supporting OpenAPI 3.0 based 
>>>>>>> API
>>>>>>>definitions
>>>>>>>6. Providing the functionality of switching the gateway
>>>>>>>environment endpoints for OpenAPI 3.0 specific APIs (If it is a 
>>>>>>> Swagger 2.0
>>>>>>>based API definition, the relevant gateway endpoint should be 
>>>>>>> specified in
>>>>>>>host, basepath and schema elements of the Swagger definition. But in
>>>>>>>OpenAPI 3.0, the gateway endpoint details should be specified under 
>>>>>>> server
>>>>>>>element of the definition. )
>>>>>>>
>>>>>>>
>>>>>>> Any suggestions to improve the functionalities and usability aspects
>>>>>>> of the feature? Your comments and thoughts on this are highly 
>>>>>>> appreciated.
>>>>>>>
>>>>>>> [1] https://github.com/wso2/carbon-apimgt/issues/4897
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> --
>>>>>>> Thilini Shanika
>>>>>>> Senior Software Engineer
>>>>>>> WSO2, Inc.; http://wso2.com
>>>>>>> 20, Palmgrove Avenue, Colombo 3
>>>>>>>
>>>>>>> E-mail: tgtshan...@gmail.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lakmal Warusawithana
>>>>>> Senior Director - Cloud Architecture; WSO2 Inc.
>>>>>> Mobile : +94714289692 <+94%2071%20428%209692>
>>>>>> Blogs : https://medium.com/@lakwarus/
>>>>>> http://lakmalsview.blogspot.com/
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thilini Shanika
>>>>> Senior Software Engineer
>>>>> WSO2, Inc.; http://wso2.com
>>>>> 20, Palmgrove Avenue, Colombo 3
>>>>>
>>>>> E-mail: tgtshan...@gmail.com
>>>>>
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Harsha Kumara
>>>> Software Engineer, WSO2 Inc.
>>>> Mobile: +94775505618 <+94%2077%20550%205618>
>>>> Blog:harshcreationz.blogspot.com
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>
>>
>> --
>> Thilini Shanika
>> Senior Software Engineer
>> WSO2, Inc.; http://wso2.com
>> 20, Palmgrove Avenue, Colombo 3
>>
>> E-mail: tgtshan...@gmail.com
>>
>>
>
>
> --
> 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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C4[]APIM] REST API for changing Owner of a Application

[Nuwan Dias]

On Wed, Dec 20, 2017 at 4:56 AM, Shazni Nazeer <sha...@wso2.com> wrote:

> Will this also be supported via the store UI?
>

No, this will be a privileged operation with very less usage. Which doesn't
make it useful to have it on the Store UI.

>
> On Sun, Dec 17, 2017 at 10:34 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>>
>>
>> On Mon, Dec 18, 2017 at 5:21 AM, Fazlan Nazeem <fazl...@wso2.com> wrote:
>>
>>> Hi Sam,
>>>
>>> Are we planning to change the ownership of the generated application
>>> token owner as well?  i.e AUTHZ_USER of the token and USERNAME of Oauth
>>> App in the DB tables. Otherwise, for analytics, these changes wouldn't be
>>> reflected right?
>>>
>>
>> Well, tokens are owned by end users. So I don't think its right to change
>> the ownership of tokens which are already created. But we probably check
>> how to change the ownership of the OAuth app (SP).
>>
>>>
>>> On Mon, Dec 18, 2017 at 8:21 AM, Prasanna Dangalla <prasa...@wso2.com>
>>> wrote:
>>>
>>>> Hi Sam,
>>>>
>>>> +1 to have the new scope app_manage.
>>>>
>>>> On Mon, Dec 18, 2017 at 7:59 AM Sam Sivayogam <s...@wso2.com> wrote:
>>>>
>>>>> On Sun, Dec 17, 2017 at 1:22 PM, Malintha Amarasinghe <
>>>>> malint...@wso2.com> wrote:
>>>>>
>>>>>> Hi Sam,
>>>>>>
>>>>>> This overall looks good to me. Added few inline comments.
>>>>>>
>>>>>> On Sun, Dec 17, 2017 at 6:26 AM, Sam Sivayogam <s...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> As discussed in mail thread[1] we had a requirement to add an API
>>>>>>> which allows to change the owner of a created application. During the
>>>>>>> initial discussions we decided to add this api to the existing admin 
>>>>>>> REST
>>>>>>> APIs.
>>>>>>> After going through the APIs I thought to add below 2 resources.
>>>>>>>
>>>>>>>
>>>>>>> 1. The following GET resource will list all the apis created by the
>>>>>>> given user. This will be same as the store application listing API but
>>>>>>> lists application for the given username rather than listing the
>>>>>>> applications created user associated with the provided access token.
>>>>>>>
>>>>>>> This will return the
>>>>>>> GET  /applications
>>>>>>>
>>>>>>> Parameters
>>>>>>> query username
>>>>>>>
>>>>>>
>>>>>> As a usual practice it is better not to mandate username as it is a
>>>>>> query parameter. One option is, if it is not provided, we get the user 
>>>>>> from
>>>>>> the access token. Even if it is sligtly bad that it make not sometimes 
>>>>>> make
>>>>>> sense to get store applications of an admin user, I think it is better 
>>>>>> than
>>>>>> fully mandating the query param and giving an error if user does not
>>>>>> provide it.
>>>>>>
>>>>> +1 for this approach
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sample Response :
>>>>>>> {
>>>>>>>"count": 2,
>>>>>>>"next": "",
>>>>>>>"previous": "",
>>>>>>>"list":[
>>>>>>> {
>>>>>>>  "applicationId": "b16ce8d0-5e0b-4259-96e2-68151cc92489",
>>>>>>>  "name": "AppX",
>>>>>>>  "subscriber": "admin",
>>>>>>>  "throttlingTier": "Unlimited",
>>>>>>>  "description": "",
>>>>>>>  "status": "APPROVED",
>>>>>>>  "groupId": ""
>>>>>>>   },
>>>>>>> {
>>>>>>>

Re: [Architecture] [C4[]APIM] REST API for changing Owner of a Application

[Nuwan Dias]

in admin, I think first approach is better as
>>>> that is the approach we will be following most of the time for 3.0.0 and
>>>> there will be less amount of API changes for a user migrating from 2.x to
>>>> 3.0.0
>>>>
>>> Will follow the first approach.
>>>
>>>>
>>>>
>>>>
>>>> On Sun, Dec 17, 2017 at 1:12 PM, Godwin Shrimal <god...@wso2.com> wrot
>>>> e:
>>>>
>>>>> Hi Sam,
>>>>>
>>>>> Who can change the owner of the application?
>>>>>
>>>>
>>>> *@Godwin*, I think we will be defining a new scope for the API which
>>>> can only be retrieved from an admin user. *@Sam* will we do that?
>>>>
>>> yes thought of having a separate scope like apim:app_manage
>>>
>>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> Godwin
>>>>>
>>>>
>>>>
>>>> Thanks!
>>>> Malintha
>>>>
>>>> POST /applications/change-owner
>>>>>
>>>>> Parameters
>>>>> query application UUID
>>>>> query newOwner
>>>>>
>>>>> Sample Response :
>>>>>
>>>>> {
>>>>>"applicationId": "6edcac5e-4df3-42fe-8a21-07c114085bcb",
>>>>>"name": "AppY",
>>>>>"subscriber": "newOwner",
>>>>>"throttlingTier": "Unlimited",
>>>>>"callbackUrl": null,
>>>>>"description": "",
>>>>>"status": "APPROVED",
>>>>>"groupId": ""
>>>>> }
>>>>>
>>>>> Please let me know your thoughts on this.
>>>>>
>>>>> [1] Application Sharing support for Multiple Groups
>>>>>
>>>>> Thanks,
>>>>> Sam
>>>>>
>>>>>
>>>>> --
>>>>> *Sam Sivayogam*
>>>>>
>>>>> Senior Software Engineer
>>>>> Mobile  : +94 772 906 439
>>>>> Office   : +94 112 145 345
>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>>>> lean.enterprise.middleware.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Malintha Amarasinghe
>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>> http://wso2.com/
>>>>
>>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>>
>>>
>>>
>>>
>>> --
>>> *Sam Sivayogam*
>>>
>>> Senior Software Engineer
>>> Mobile  : +94 772 906 439
>>> Office   : +94 112 145 345
>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>> lean.enterprise.middleware.
>>>
>> --
>> *Prasanna Dangalla*
>> Senior Software Engineer, WSO2, Inc.; http://wso2.com/
>> lean.enterprise.middleware
>>
>>
>> *cell: +94 718 11 27 51*
>> *twitter: @prasa77*
>>
>
>
>
> --
> Thanks & Regards,
>
> *Fazlan Nazeem*
> Senior Software Engineer
> WSO2 Inc
> Mobile : +94772338839
> <%2B94%20%280%29%20773%20451194>
> fazl...@wso2.com
>



-- 
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] [APIM][C5] - Resource Registration Rest API For API Manager

[Nuwan Dias]

On Mon, Dec 11, 2017 at 4:50 AM, roshan wijesena <roshan86...@gmail.com>
wrote:

> Nuwan, When we export the  swagger file, we should be able to get all the
> scopes that are bonded to the Ballerina resource right?
>

Scopes are primarily declared on the Swagger file itself. So if you export
the Swagger file, you can get all the scopes from there. Swagger to
Ballerina is a one-to-one mapping. So a scope declared under a resource in
the Swagger is exactly the same scope attached to the resource in the
Ballerina service.

>
> On Mon, Dec 11, 2017 at 2:44 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>>
>>
>> On Mon, Dec 11, 2017 at 4:31 AM, Harsha Kumara <hars...@wso2.com> wrote:
>>
>>>
>>>
>>> On Fri, Dec 8, 2017 at 11:10 PM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
>>>> Hi Harsha,
>>>>
>>>>
>>>>
>>>> On Fri, Dec 8, 2017 at 10:38 PM, Harsha Kumara <hars...@wso2.com>
>>>> wrote:
>>>>
>>>>> On Tue, Dec 5, 2017 at 12:59 PM, Tharindu Dharmarathna <
>>>>> tharin...@wso2.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> As per the offline discussion today, we going to implement
>>>>>> according to following way.
>>>>>>
>>>>>> *Rest Apis expose*
>>>>>>
>>>>>> /apis/{apiId}/scopes - POST to Create Scope object.
>>>>>> /apis/{apiid}/scopes - GET Get list of scope names
>>>>>> /apis/{apiid}/scopes/{name} -  GET get the detail of Scope
>>>>>> /apis/{apiid}/scopes/{name} - PUT update the existing scope
>>>>>> /apis/{apiid}/scopes/{name} - Delete delete the scope
>>>>>>
>>>>> What are the restrictions for scope name? Having special charactors
>>>>> will cause issues.
>>>>>
>>>>>>
>>>>>> *Scope assign into the resource.*
>>>>>>
>>>>>> This can be done by following two ways.
>>>>>>
>>>>>> 1.  / apis/{apiid} - PUT scope assign it to resource and those
>>>>>> information stored in swagger.json
>>>>>> 2. /apis/{apiid}/swagger  - PUT swagger.json update with scopes will
>>>>>> create/update accoringly.
>>>>>>
>>>>>> So we are going to store the scopes in the swagger itself and the
>>>>> scope to role mappings in database right?
>>>>>
>>>>
>>>> Scopes are only stored in swagger itself and for the scope to role
>>>> mapping it will resides on the Authorization Server Itself. when we going
>>>> to show the scope, we call the Authorization server endpoint and get the
>>>> bindings.
>>>>
>>> When it comes to token generation and validation how efficient is to get
>>> scopes information of a resource when we stored scopes in swagger? Does it
>>> has any effect?
>>>
>>
>> Since Ballerina is tightly linked to Swagger we could probably get the
>> scopes from the Swagger file to the Ballerina service itself, at the point
>> of deploying the API. If the scopes are in the Ballerina resource itself we
>> won't have to read the swagger for scopes.
>>
>>>
>>>>>> On Tue, Dec 5, 2017 at 12:39 PM, Tharindu Dharmarathna <
>>>>>> tharin...@wso2.com> wrote:
>>>>>>
>>>>>>> @Bhathiya,
>>>>>>>
>>>>>>> We are not giving sharing the scopes between APIS as those roles can
>>>>>>> have different definitions as below.
>>>>>>>
>>>>>>> For API1 for resource /menu post need scope1 which have role1 and
>>>>>>> role2.
>>>>>>>
>>>>>>> For API2 for resource /abc POST need scope1 which have role3 and
>>>>>>> role4.
>>>>>>>
>>>>>>> therefore we can't create scope which can cater above 2.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 5, 2017 at 11:33 AM, Bhathiya Jayasekara <
>>>>>>> bhath...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi Tharindu,
>>>>>>>>
>>>>>>>> Have we considered creating scopes in a single place and reusing
>>>>>>>&g

Re: [Architecture] [APIM][C5] - Resource Registration Rest API For API Manager

[Nuwan Dias]

gt;>>>>>
>>>>>>>1. Store under swagger.json as security definition
>>>>>>>2. Store In database schema.
>>>>>>>
>>>>>>> If we are Storing in swagger we have following advantages and
>>>>>>> disadvantages.
>>>>>>> *Advantages*
>>>>>>>
>>>>>>> 1. The scope can easily manage as we can assign the scopes to a
>>>>>>> resource inside the swagger.
>>>>>>>
>>>>>>> *Disadvantages*.
>>>>>>>
>>>>>>> 1. If we have lots of scopes for the API for getting the Details of
>>>>>>> the scope we have to call the Resource Server Endpoint, therefore it may
>>>>>>> lead to high network usage.
>>>>>>> 2. Swagger given by user get changed by injecting our set of
>>>>>>> properties.
>>>>>>>
>>>>>>> I had come up with below set of resources to create scopes and
>>>>>>> assign scopes
>>>>>>>
>>>>>>>
>>>>>>>1. /apis/{apiid}/scopes - post (add scope for api)
>>>>>>>2. /apis/{apiid}/scopes - get (get All the scopes for api)
>>>>>>>3. /apis/{apiid}/scopes/{name} - put update scope
>>>>>>>4. /apis/{apiid}/scopes/{name} - delete scope
>>>>>>>5. /apis/{apiid} - put (Apply scopes(add,update,delete) into
>>>>>>>resources)
>>>>>>>6. /apis/{apiid} - get (get scopes applied to a resources)
>>>>>>>
>>>>>>> Or We can do the below way as Reources are not consider as a sub
>>>>>>> resources of the API
>>>>>>>
>>>>>>>
>>>>>>>1. /api1/{apiid} - (get,put) These two operations used to add
>>>>>>>scope,update scope,delete scope,assign scopes to resources.
>>>>>>>
>>>>>>>
>>>>>>> Please let us know your Ideas on this.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> *Tharindu Dharmarathna*Senior Software Engineer
>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>> lean.enterprise.middleware
>>>>>>>
>>>>>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Bhathiya Jayasekara*
>>>>>> *Associate Technical Lead,*
>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>>
>>>>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>>> <https://twitter.com/bhathiyax>*
>>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Tharindu Dharmarathna*Senior Software Engineer
>>>>> WSO2 Inc.; http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Tharindu Dharmarathna*Senior Software Engineer
>>>> WSO2 Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>>
>>>
>>>
>>>
>>> --
>>> Harsha Kumara
>>> Software Engineer, WSO2 Inc.
>>> Mobile: +94775505618 <+94%2077%20550%205618>
>>> Blog:harshcreationz.blogspot.com
>>>
>>
>>
>>
>> --
>>
>> *Tharindu Dharmarathna*Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>
>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <+94%2077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



-- 
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] [APIM] [C4] [2.1.0] API Gateways with Dedicated Back Ends

[Nuwan Dias]

Hi Akila,

The subject of the mail is not descriptive enough for the feature we're
trying to develop. What we're actually trying to achieve here is the
ability for an API to be moved across environments without having to change
the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <aki...@wso2.com> wrote:

> Hi all,
>
> Sorry for the mistake. This is not the complete mail. The complete mail
> will be sent.
>
> Thanks,
>
> Akila Aroshana
> Software Engineer (Intern)
> WSO2
>
> Mobile : +94702178247 <+94%2070%20217%208247>
> Email : aki...@wso2.com
> LinkedIn : www.linkedin.com/in/akila-amarasinghe
> Web : http://wso2.com
>
> On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <aki...@wso2.com> wrote:
>
>> Hi all,
>>
>> WSO2 API manager currently provides the facility for the user to input a
>> single endpoint to the API when designing it. So every time the API makes
>> requests, the request is directed to the back end defined by the endpoint
>> URL provided. Even if the API has multiple gateways, all the gateways
>> directs the requests to the same back end of the defined URL as the
>> following figure depicts.
>>
>>
>>
>> Problem :
>>
>> Assume a situation like this,
>>
>> Person A designs an API with the endpoint <https://backend-region-1:8280>
>> and works with it. Person B, which is in another region, <
>> https://backend-region-2:8280> with the same back end database needs
>> that API for some purpose. He deploys the API exported by Person A in the
>> gateway of his region and try to use. But the API will never connect with
>> the back end of his region. But in this situation, the API doesn't get
>> connected with the back end of region-2. As the endpoint which the Person A
>> entered is for region-1 back end only.
>>
>> If an already designed API needs to be connected with a back end(same
>> one) with a different endpoint(region) other than the already defined
>> endpoint in the API, the API won't be able to connect with it. Simply, a
>> designed API cannot be deployed in a region with a different back end
>> *URL *(not a different back end).
>>
>> Solution :
>>
>> The proposed solution is to enter a *dynamic endpoint* at the time the
>> API is designed. This endpoint should only be resolved at the run time so
>> the API so the gateway would point a dedicated back end. This also applies
>> when an API has more than one gateway.
>>
>>
>> ​
>>
>>
>>
>> ​
>>
>>
>>
>


-- 
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] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Nuwan Dias]

This design looks good. Please send a sample of the synapse config (only
the portion that gets modified) so that users get a good picture of how
this is supposed to be injected to the Gateway handler.

On Mon, Nov 27, 2017 at 10:43 AM, Viduranga Gunarathne <vidura...@wso2.com>
wrote:

> Hi,
>
> APIs in APIM 2.1.0 are secured with OAuth2 access tokens. In order to
> access an API, the consumers should generate an access token and the
> particular request should contain the generated token as an HTTP header.
>
> *Eg: "Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a"*
>
>
> *Problems:*
>
> i) As per the current implementation of API-M 2.1.0 the structure of the
> access token is as above and the header field is hard coded  to be
> *"Authorization"*. When the Gateway receives a request to access a
> resource, it looks for the access token by referring to the
>  header field "Authorization". The proposed implementation is to give each
> and every tenant in the system, the capability to have a, "per tenant"
> based customized authorization header field.
>
>
>Eg:
>
> Tenant 1 : hr.lk --> "HR_Auth : Bearer
> NtBQkXoKElu0H1a1fQ0DWfo6IX4a"
>
> Tenant 2 : eng.lk  --> "ENG_Auth : Bearer
> NtBQkXoKElu0H1a1fQ0DWfo6IX4a"
>
>
>NB: This feature also supports the current implementation of
> "Authorization" as the header field, so that it doesn't affect the existing
> API-Ms in production.
>
>
> ii) In API-M 2.1.0 there is a feature to restrict the access token, that
> is being sent in the request, to be passed through to the production
> endpoint from the Gateway. The configuration relevant to this is in the
> "api-manager.xml" and it is as follows;
>
> *
> true*
>
> If the value is set to *true *then the Gateway will not pass the
> access token to the back end and if it's *false*, then it will. Since
> this configuration resides in the *"api-manager.xml"*, it applies in a
> "per server" basis. The proposal is to migrate it to the *"tenant-conf.json"
>   *so that this configuration can be applied in a "per tenant" basis.
>
>
>
> *Solutions:*
> The design of the proposed solutions for the two problems are as follows:
>
> i) Proposed workflow for custom header field:
>
> a) Read a configuration from the "tenant-conf.json" for a customized
> OAuth2 header field.
> b) Insert the config into the synapse config file that is generated once
> an API is published, so that it gets deployed in the Gateway.
> c) Use the custom header when checking the access token from
> "APIAuthenticationHandler" for authentication.
>
> d) If no configuration exists in the "tenant-conf.json", then check for a
> config in "api-manager.xml" and follow step (b) and (c). This config will
> act as global config for the server.
>
> e) If no configuraton exists in the api-manager.xml then the existing
> workflow will execute using the "Authorization" header field.
>
>
> ii) Proposed workflow for restricting the access token from being passed
> to the backend.
>
> a) Read the "RemoveOAuthHeadersFromOutMessage" config from the
> "tenant-conf.json"
>
> b) If no config exists in tenant-conf.json, then read it from the
> "api-manager.xml"
>
>
> Any ideas and suggestions are highly appreciated!
>
> Thanks,
> Viduranga.
>
> [1] https://docs.wso2.com/display/AM210/Working+with+Access+Tokens
> --
> Regards,
>
> *Viduranga Gunarathne*
>
> *Software Engineer Intern*
>
>
> *WSO2*
> Email : vidura...@wso2.com
> Mobile : +94712437484 <+94%2071%20243%207484>
> Web : http://wso2.com
> [image: https://wso2.com/signature] <https://wso2.com/signature>
>



-- 
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 Configuration Lookup from Environment Variables

[Nuwan Dias]

>>>>> an effect is not an overhead IMO. Especially since we already do that 
>>>>>> now,
>>>>>> we request for possible environmental factors, at least after all other
>>>>>> efforts are exhausted. When this change is introduced, we would not
>>>>>> additionally ask for anything.
>>>>>>
>>>>>> Furthermore, environment variables would mainly be used in scenarios
>>>>>> where Container Cluster Management systems are used, in which case there 
>>>>>> is
>>>>>> a clear cut definition of which environment variables with what values 
>>>>>> are
>>>>>> being applied to Containers. This is how most systems are debugged in 
>>>>>> CMSs
>>>>>> like Kubernetes even now, where commands like `kubectl describe` would 
>>>>>> give
>>>>>> you all the runtime information.
>>>>>>
>>>>>> Non-Containerized environments like VMs would mostly use the file
>>>>>> based approach where it is easy to be coupled with Config Automation 
>>>>>> tools
>>>>>> like Puppet.
>>>>>>
>>>>>> The concern of troubleshooting can be tackled by enabling a verbose
>>>>>> log that would display the environment variable name from which a certain
>>>>>> value was retrieved, at the time configs are loaded. This would obviously
>>>>>> have to be verbose than INFO, however it would greatly help any debugging
>>>>>> process. This is how tools like Puppet handle environment variable 
>>>>>> injected
>>>>>> configs.
>>>>>>
>>>>>> The argument for file-less environment variables in the lookup
>>>>>> hierarchy is how quickly it becomes cumbersome to handle configuration
>>>>>> files across different Container images. Having files would soon present 
>>>>>> us
>>>>>> with a situation similar to what we handle now in C4 with configuration
>>>>>> repositories for different "patterns" of deployment in Containers, that
>>>>>> requires a separate effort to be maintained for different releases. 
>>>>>> Having
>>>>>> low-config convention-based environment variables support is a valuable
>>>>>> addition to the C5 configuration lookup model since we've already reduced
>>>>>> the number of configuration files. deployment.yaml will anyway be there,
>>>>>> and I'm willing to bet that most clients would use that to make
>>>>>> configuration changes. However, there are a set of clients who would
>>>>>> require the convention-based environment variables for a
>>>>>> smoother integration to Containerization than others.
>>>>>>
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Chamila de Alwis
>>>>>> Committer and PMC Member - Apache Stratos
>>>>>> Senior Software Engineer | WSO2
>>>>>> Blog: https://medium.com/@chamilad
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 23, 2017 at 1:03 PM, Jayanga Dissanayake <
>>>>>> jaya...@wso2.com> wrote:
>>>>>>
>>>>>>> @Nuwan, configs should be able to inject via environment properties.
>>>>>>> What I am saying is all these configs should be specified the in the
>>>>>>> deployment.yaml as {env:placeholder name}.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jayanga.
>>>>>>>
>>>>>>> *Jayanga Dissanayake*
>>>>>>> Associate Technical Lead
>>>>>>> WSO2 Inc. - http://wso2.com/
>>>>>>> lean . enterprise . middleware
>>>>>>> email: jaya...@wso2.com
>>>>>>> mobile: +94772207259 <+94%2077%20220%207259>
>>>>>>> <http://wso2.com/signature>
>>>>>>>
>>>>>>> On Wed, Aug 23, 2017 at 12:51 PM, Nuwan Dias <nuw...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> @Jayanga, how do you make the server run elegantly on containers
>>>>>>>> without being able to inject properties via env variables?
>>&g