Re: [Architecture] API Revision Feature

[Amila De Silva]

Hi Sampath,

Looks like both AM_DEPLOYMENT and AM_LABELS tables are serving the same
purpose. Are we planning to keep the both?

If it's the working copy that'll be shown in the DevPortal, why is it
needed to have the column DISPLAY_ON_DEVPORTAL? Even if we have to keep
that column, shouldn't it come under AM_REVISION rather than
AM_DEPLOYMENT_REVISION_MAPPING?

On Wed, Nov 25, 2020 at 10:28 AM Sampath Rajapakshe 
wrote:

> Hi All,
>
> We are planning to add the feature in $subject to the next API-M release
> and this is to initiate a discussion on feature implementation design.
>
> The purpose of the feature from a high level point of view is as follows.
>
> API creator/publisher should be able to create an API revision(copy of the
> current API state) from the current working copy of the API and should be
> able to deploy that revision to multiple runtime gateway environments and
> also if something breaks should be able to restore to a previous revision.
>
> Therefore, the following functionalities will be provided to the API
> creator/publisher.
>
>-
>
>Create/Delete revisions.
>-
>
>Deploy revision to runtime gateway environments.
>-
>
>Reset the current working copy to a previous revision.
>-
>
>Can deploy a different revision to an already revision deployed
>runtime gateway environment. Here, the previously deployed revision will
>get un-deployed and newly selected revision will get deployed to that
>particular environment. Users will be prompted for approval before this
>task.
>-
>
>Revisions are also immutable but once you revert back to a previous
>revision, the user can work on top of that revision(which will be
>considered as the working copy of API) and create a new revision and then
>can deploy.
>
>
> Once a revision is created we will be storing that particular API’s
> registry artifacts to a new different path inside the registry.
>
> For example:
> /system/governance/applicationdata/apis//revisions//
>
> As per the initial discussion, the proposed database structure to cater
> above requirements is as follows,
>
>
> Key Points are as follows,
>
>
>
>-
>
>ID and API_UUID are composite primary key for AM_REVISION table.
>
> Ex:
>
> ID= 1, API_UUID = 12345
>
> ID= 2, API_UUID = 12345
>
> ID=1, API_UUID = 98765
>
>
>-
>
>Single API can have multiple revisions.
>-
>
>One revision should be able to be deployed to multiple runtime
>deployments.
>-
>
>REVISION_UUID is the registry revisioned API artifacts ID.
>-
>
>DISPLAY_ON_DEVPORTAL field is a flag to keep track of which runtime
>deployment to be shown on the devportal.
>-
>
>REVISION_ID field in AM_DEPLOYMENT_REVISION_MAPPING table refers to
>the composite primary key(ID and API_UUID) in AM_REVISION table.
>-
>
>The REVISION_ID field in the AM_REVISION_HISTORY_EVENTS table refers
>to the composite primary key(ID and API_UUID) in the AM_REVISION table.
>-
>
>One revision can have multiple related revision history events.
>
>
> Also tables such as below which keep data related to API will be changed
> accordingly to keep revision details by adding a revision id field.
>
> URL Mapping, AM_GRAPHQL_COMPLEXITY, AM_CERTIFICATE_METADATA,
> AM_API_CLIENT_CERTIFICATE
>
> Appreciate your inputs on the current proposed database table structure.
>
> Thanks,
>
> Sampath
>
> --
>
> *Sampath Rajapakse* | Software Engineer | WSO2 Inc.
>
> +94717313761 | samp...@wso2.com
>
>
>

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

Re: [Architecture] [APIM][Intern Project]- Application Level Mutual TLS support for API Manager

[Amila De Silva]

Hi Sanjeewa,
The way it is supported for REST APIs right now, the feature operates as if
there was a subscription. The Tier which is typically captured in
Subscription needs to be captured while uploading the certificate. And when
a consumer needs to access the API, a certificate needs to be added against
the API which basically triggers a change in the API. So a change that
needs to happen on Devportal is now happening on the Publisher side. By
supporting uploading certs through the Application;
1. A Certificate is used as another key for identifying an Application.
2. API Subscription is enabled uniformly for APIs with Mutual TLS.
3. APIs can be consumed without changing the API.

Giving the ability to directly add a certificate to Gateways through
Devportal is a risk, which can be solved through a Workflow. Either through
a Subscription Approval or by triggering a new workflow while uploading the
certificate, wouldn't it be possible to mitigate the risk?

On Thu, Nov 19, 2020 at 1:14 PM Dulangi Gamage (Intern) 
wrote:

> Thank you very much for sharing your feedback. We'll take more
> consideration on those matters before proceeding further.
>
> Thank You,
> Dulangi
>
>
> On Thu, Nov 19, 2020 at 12:43 PM Sanjeewa Malalgoda 
> wrote:
>
>> As I understand, mutual TLS has nothing to do with the place we upload
>> cerths (application and subscription).
>> If we take mutual SSL enabled soap messages then what we do is get a
>> header block with NS URL after checking cert object. Then from the header
>> block we get the user name. In mutual SSL whatever username send by client
>> is trusted as long as it comes with proper format and along with cert.
>> Similar to that, can't we just let subscribers send those information along
>> with the certificate?
>>
>> On the other hand if we let subscribers upload certs that affect the
>> gateway they can simply upload any certificate with host names and override
>> certificates added by maintainers. Isn't it a problem?
>>
>> Thanks,
>> sanjeewa.
>>
>> On Tue, Nov 17, 2020 at 1:06 PM Dulangi Gamage (Intern) 
>> wrote:
>>
>>> Hi All,
>>>
>>> *Project Description*
>>>
>>> Currently, the API Manager supports mutual TLS at the API level. In the
>>> current implementation application subscription is not permitted for APIs
>>> that are only protected with Mutual SSL. Therefore, subscription or
>>> application-level throttling is not applicable to these types of APIs.
>>> Hence, now the Mutual TLS support needs to be implemented at the
>>> application level so that all the applications subscribed to that API will
>>> have mutual TLS enabled. So my project is to enhance the Mutual TLS support
>>> to the application level and enhance the application developer portal
>>> UI to support mutual TLS.
>>>
>>> Please refer to the attached google doc for more details.
>>>
>>> https://drive.google.com/file/d/1tiB2xkuopKGWWYJYEqTlRztfFiCenl19/view?usp=sharing
>>>
>>> Your feedback and suggestions are greatly appreciated. Thank You.
>>>
>>>
>>> --
>>> Dulangi Gamage | Intern | WSO2 Inc.
>>> (m) +94766697385 | Email: dula...@wso2.com
>>> <http://wso2.com/signature>
>>> ___
>>> 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
>>
>
>
> --
> Dulangi Gamage | Intern | WSO2 Inc.
> (m) +94766697385 | Email: dula...@wso2.com
> <http://wso2.com/signature>
> ___
> 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

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

[Amila De Silva]

Hi Ziyam,
The reason to ask about uploading client certificates was to know whether
we already identified an approach to do so. Even if there's a management
API, IMO it should be invoked by a DevOps who has permission to change
configuration.

One suggestion would be :
>From the Devportal side it'll be sufficient to provide an option to attach
a certificate to the Application. So in order to consume the Kafka API,
Developers need to create an Application and Subscribe to the API, but
instead of creating Consumer Key/Secret, in this instance they'd have to
attach a certificate. At the time of subscribing, Devportal would also
generate the relevant rules associated with the client.  Then as a part of
the Subscription approval flow, an admin can verify the cert and apply it
to Kafka with the relevant ACLs. (Admins can either use the exact rules or
define their own rules by looking at the generated rules. The idea behind
generating rules is to save the trouble of going through API definition and
identifying the needed access levels.)  Approval will only be completed
once the new certs has been applied properly.


On Wed, Aug 12, 2020 at 10:09 AM Ziyam Santhosh (Intern) 
wrote:

> Hi Amila,
>
> Sorry for the late reply. I did some research regarding your question.
> Yes, client authentication is achieved using mutual SSL. As far as I know,
> there isn't any management APIs in Kafka to apply ACLs and uploading
> certificates. But [1]
> <https://github.com/simplesteph/kafka-security-manager> This may help us
> to do that. I am still not sure about the functionalities of this tool. I
> will update you soon.
>
> [1] https://github.com/simplesteph/kafka-security-manager
>
> On Thu, Aug 6, 2020 at 12:46 PM Amila De Silva  wrote:
>
>> Hi Ziyam,
>>
>> Thanks for the clarification. As I understand [1],Client Authentication
>> is achieved through Mutual SSL, which means that when creating a
>> subscription each client app should be able to upload their certificate,
>> isn't it? And are there any management APIs in Kafka that allows applying
>> ACLs and uploading certificates, or do we plan to do it manually?
>>
>> [1]
>> https://kafka.apache.org/20/documentation/streams/developer-guide/security.html
>>
>> On Wed, Aug 5, 2020 at 3:39 PM Ziyam Santhosh (Intern) 
>> wrote:
>>
>>> Hi Amila!
>>> Basically Kafka topics and streams have their own security policies
>>> applied through certificates which determine what users can do with those
>>> topics such as read-only or read and write authorities. Our developer
>>> portal will be the issuer of these certificates. These certificates will be
>>> issued to people who have a valid subscription to the API.
>>>
>>> On Wed, Aug 5, 2020 at 8:04 AM Nuwan Dias  wrote:
>>>
>>>> [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) <
>>>>>> zi...@wso2.com> 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
>&

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

[Amila De Silva]

Hi All,

Tested Artifact Synchroniser in Tenant and Super Tenant modes
- for Basic flows
- With multiple Labels assigned to APIs
- Startup Delay configured
- with No Shared DBs configured (in Super Tenant mode only)
- for failover scenarios
No issues found.

+1 to proceed with the release.

On Thu, Aug 13, 2020 at 7:58 AM Arshardh Ifthikar  wrote:

> Hi All,
>
> We are pleased to announce the fourth 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-12>
>- 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-rc4
> 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
>
> --
> *Arshardh Ifthikar*
> Senior Software Engineer | WSO2 Inc.
>
> Email: arsha...@wso2.com
> Mobile: +94777218551
> Web: http://wso2.com
>
> <http://wso2.com/signature>
>


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

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

[Amila De Silva]

Tested Artifact Synchroniser for Super Tenant mode
- for Basic flows
- With multiple Labels assigned to APIs
- Startup Delay configured
- for failover scenarios (On a Setup with GWs without DB access and TMs in
Failover mode)
No issues found.

+1 to proceed with the release.

On Sat, Aug 8, 2020 at 12:25 PM 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
>
> <https://github.com/wso2/product-apim/issues?q=is%3Aissue+is%3Aclosed+closed%3A2020-03-20..2020-08-06>
>- 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-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
>
> <http://wso2.com/signature>
>


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

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

[Amila De Silva]

Hi Akshitha,
Is the ultimate plan to let developers export APIs directly from AWS API
Gateway and import those to APIM only using apictl (like it's done for
k8s)? The steps you've described are  for how it can be achieved right now
(without any changes on apictl), isn't it?


On Thu, Aug 6, 2020 at 1:40 PM 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
>


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

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

[Amila De Silva]

Hi Ziyam,

Thanks for the clarification. As I understand [1],Client Authentication is
achieved through Mutual SSL, which means that when creating a subscription
each client app should be able to upload their certificate, isn't it? And
are there any management APIs in Kafka that allows applying ACLs and
uploading certificates, or do we plan to do it manually?

[1]
https://kafka.apache.org/20/documentation/streams/developer-guide/security.html

On Wed, Aug 5, 2020 at 3:39 PM Ziyam Santhosh (Intern) 
wrote:

> Hi Amila!
> Basically Kafka topics and streams have their own security policies
> applied through certificates which determine what users can do with those
> topics such as read-only or read and write authorities. Our developer
> portal will be the issuer of these certificates. These certificates will be
> issued to people who have a valid subscription to the API.
>
> On Wed, Aug 5, 2020 at 8:04 AM Nuwan Dias  wrote:
>
>> [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

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

[Amila De Silva]

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

Re: [Architecture] [APIM] [APIM-Analytics] Removing APIM database(AM_DB) dependency for analytics

[Amila De Silva]

 This could cause memory and performance issues
>> when the data load increases. However, if we introduce analytics specific
>> REST APIs tailor made to return the information required by these widgets,
>> we could move the data processing burden to the backend/database level.
>>
>> *Ease of introducing new REST APIs*
>>
>> When introducing new widgets which require data from AM_DB, if there is
>> no existing API to get the required information, we can easily add a new
>> REST API to the analytics webapp to get the required information.
>>
>> Appreciate your thoughts on the above.
>>
>> Regards,
>> Ruwini
>> --
>> Ruwini Wijesiri
>> Senior Software Engineer,
>> WSO2 Inc.
>>
>> Mobile : +94716133480
>>
>> <http://wso2.com/signature>
>>
>
>
> --
> *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
>


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

Re: [Architecture] [APIM] Multiple Key Manager support

[Amila De Silva]

Hi Tharindu,

On Tue, Apr 14, 2020 at 10:12 PM Tharindu Dharmarathna 
wrote:

> Hi All,
>
> We are going to implement Multiple Oauth provider support to WSO2 API
> Management. From this feature, dev portal users can create their Oauth
> Application on Pre-Defined OAuth providers.
>
> 1. Tenant Admin Create Oauth Provider from the Admin portal by providing
> OAuth provider details.
>
>- Client Registration endpoint
>- Introspection Endpoint
>- Scope Management Endpoint
>- Token Endpoint
>- Revoke Endpoint
>- Endpoint Security Details
>- Token Validation Regex.
>
> Isn't Scope Management a custom endpoint? Is it that we are only
specifying it when connecting with IS?

2. Application developer creates the application defining the Oauth
> Provider type.
> 3. Application developer Generates the keys from UI.
>
>- Checks for the Consumer Key Generation can be done in the Specific
>Oauth Provider.
>-  Generate the Oauth App on Oauth Provider and retrieves the Oauth
>Application Details.
>
> 4. Application Developer Retrieves the Application details from the UI.
>
>- Check for the Oauth provider selected.
>- Retrieve the Oauth App details from the Respective OAuth Provider
>selected.
>
> 5. Generating Oauth Token
>
>- Token Generation call will directly proxy into the token endpoint of
>Respective Oauth Provider.
>
> Wondering if App Developers will use this at all. Isn't the more likely
case to get the token directly from an OAuth provider? In case we support
this, how about making this configurable (so Tenant Admin can decide
whether or not to proxy the request). Currently the Token endpoint is a
passthrough, but with this some changes will be needed to find the OAuth
provider from CK. Most probably this would include making a service call
from the GW. If it's likely to make unnecessary burden on the KM nodes,
better to provide an option to disable it.


> 6. Validating the Token.
>
>- Generated Token from Oauth Providers contains a specific change
>related to the Token.
>
> So two OAuth providers can co-exist (within a single tenant space) if
their issued tokens can be separated by some property - Is this the case?

>
>- Before validating the token we checking the Token was resided to
>which Oauth provider by checking from the Token Validation Regex given.
>- Token get validate from elected Oauth Provider and then retrieve the
>information related to the Token.
>
> 7. Delete the Application
>
>- Oauth Application will remove from Respective Oauth Provider
>assigned.
>
>
> I appreciate any thoughts and feedback on this.
>

Are we only supporting this for subscriptions within the same tenant?

>
>
> Thanks
>
> *Tharindu Dharmarathna*Technical Lead
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
> mobile: *+94779109091*
>


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

Re: [Architecture] [Intern Project] Management Dashboard for MIcrogateways

[Amila De Silva]

Hi Kavindi,

As you have correctly stated, this will be useful while managing large
Microgateway deployments and especially those that run on a pure Ballerina
runtime (without any containers). For deployments that are created on
K8/Docker Swarm we should be able to pull some health/uptime stats from the
underlying framework itself.

Need to clarify certain points regarding your approach.

In the Push Method you describe, which party is responsible for pushing
Data? If it's the MicroGateway why does the Admin Dashboard (or let's say
the Node that hosts Admin Dashboard) need to maintain active connections
with individual MGs?
Maybe you can explain a bit about the two endpoints you mentioned in the
second point.

Out of the two approaches you propose,DB approach would work better because;
1. In a High Available deployment multiple Admin nodes can be running, and
having them pull information from a single database would preserve the
consistency.
2. Writing and Reading can be separated.
3. MG nodes won't have to know about different nodes that run Admin
Dashboard (with in memory option, each MG would have to push data to all
Dashboard nodes, to preserve consistency)
4. DB approach is resilient to failures.

If we go with the DB approach, depending on how we implement it, we might
also have to think about purging Data.

On Wed, Feb 12, 2020 at 5:33 PM Kavindi Gunasinghe  wrote:

> Hi all,
>
> I am currently working on the first phase of the project creating a
> Management Dashboard for Micro-gateways.
>
> Introduction
>
> The WSO2 API microgateway is a  lightweight message processor which is
> used for message security , transport security, routing and other common
> API management services. So that it is important to have a management
> dashboard for these micro gateways to keep track of the micro services.
>
> Issue
>
> Currently up and running micro-gateways can not be monitored from a
> dashboard. When there are plenty of microgateways exposing several
> APIs/microservices , there should be a dashboard available in API manager
> Admin portal in order to know the state and details of these
> micro-gateways. We can use either push or pull method in order to notify
> about the up and running microgateways.
>
> Push Method
>
> Pros :
>
>-
>
>No unnecessary traffic. The data is pushed only when the data becomes
>available.
>-
>
>In this scenario , both endpoints stay idle until some information is
>sent to the admin portal.
>-
>
>The admin portal keeps the connection to the other endpoint (micro
>gateway) constantly active, so get the new information instantly.
>
>
> Cons :
>
>-
>
>Sometimes the data will arrive at an unwanted time when the admin
>portal is not ready for it. However this can be remedied by using a
>dependency constraint.
>
>
> Option 1:
> We can store the data that we receive from the mocrogateways in a database
> and then push those data to be displayed in the Management Dashboard.
>
> Option 2:
>
> Otherwise we can keep those data in memory and then push those to be
> displayed in the management dashboard.
>
>
> Solution
>
> We can implement a User Interface(dashboard) in the APIM Admin portal to
> monitor the micro gateways and push or pull (REST API) mechanism support of
> notifying in Micro gateway side. When considering the push and pull method,
> it will be efficient to use the Push method for this due to the above
> mentioned pros and cons. In the dashboard it will be useful to display some
> of the following features.
>
>
>-
>
>Currently up and running microservices
>
>
>
>-
>
>Status of the microservices (up or down)
>
>
>
>-
>
>The uptime of the exposed micro services
>
>
>
>-
>
> Request Counter (No.of requests served , No.of failed requests, No.of
>successful requests)
>
>
>
>-
>
>Request Failure rate
>
>
>
>-
>
>No.of requests per second(Throughput)
>
>
>
> Rough sketch of a dashboard
>
> [image: dasboard.png]
> I have created a  swagger specification for this. Please find it attached
> below. And highly appreciate your thoughts on this $subject.
>
> Thanks!
>
>
> --
> *Kavindi Gunasinghe* | Intern - Engineering | WSO2 Inc. <http://wso2.com/>
> (M)+94 773058210 | (E) kavi...@wso2.com 
> <https://wso2.com/signature>
>
>
>
>

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

Re: [Architecture] [APIM] Support Global OAuth2 Scopes and Attaching Multiple Scopes per API Resource

[Amila De Silva]

---
>>>>
>>>> post:
>>>>   security:
>>>> - OAuth2Security:
>>>>   - apim:global_scope_manage
>>>>   summary: Add a new global scope
>>>>   description: |
>>>> This operation can be used to add a new global scope.
>>>>   parameters:
>>>> - in: body
>>>>   name: body
>>>>   description: |
>>>> Scope object that needs to be added
>>>>   required: true
>>>>   schema:
>>>> $ref: '#/definitions/Scope'
>>>>   responses:
>>>> 201:
>>>>   description: |
>>>> Created.
>>>> Successful response with the newly created Scope object as
>>>> an entity in the body.
>>>>   schema:
>>>> $ref: '#/definitions/Scope'
>>>>   headers:
>>>> Content-Type:
>>>>   description: |
>>>> The content type of the body.
>>>>   type: string
>>>> 400:
>>>>   description: |
>>>> Bad Request.
>>>> Invalid request or validation error
>>>>   schema:
>>>> $ref: '#/definitions/Error'
>>>> 415:
>>>>   description: |
>>>> Unsupported media type.
>>>> The entity of the request was in a not supported format.
>>>>
>>>>
>>>> ##
>>>>
>>>> # The "Individual Global Scope" resource APIs
>>>>
>>>> ##
>>>>
>>>>   /global-scopes/{scopeId}
>>>>
>>>>
>>>> #-
>>>>
>>>> # Retrieve the details of a global scope
>>>>
>>>> #-
>>>>
>>>>
>>>> get:
>>>>
>>>>   security:
>>>>
>>>> - OAuth2Security:
>>>>
>>>>   - apim:api_view
>>>>
>>>>   summary: Get details of a global scope
>>>>
>>>>   parameters:
>>>>   - $ref: '#/parameters/scopeId'
>>>>
>>>>   responses:
>>>>
>>>> 200:
>>>>
>>>>   description: |
>>>>
>>>> OK.
>>>>
>>>> Requested Global Scope is returned.
>>>>
>>>>   schema:
>>>>
>>>> $ref: '#/definitions/Scope'
>>>>
>>>>   headers:
>>>>
>>>> Content-Type:
>>>>
>>>>   description: |
>>>>
>>>> The content type of the body.
>>>>
>>>>   type: string
>>>>
>>>> 404:
>>>>   description: |
>>>> Not Found.
>>>> Requested Global Scope does not exist.
>>>>   schema:
>>>> $ref: '#/definitions/Error'
>>>>
>>>>
>>>> #-
>>>>
>>>> # Update a global scope
>>>>
>>>> #-
>>>>
>>>> put:
>>>>
>>>>   security:
>>>>
>>>> - OAuth2Security:
>>>>
>>>>   - apim:global_scope_manage
>>>>
>>>>   summary: Update an API
>>>>
>>>>   description: |
>>>>
>>>> This operation can be used to update an existing Global Scope.
>>>>
>>>>   parameters:
>>>>
>>>> - $ref: '#/parameters/scopeId'
>>>>
>>>> - in: body
>>>>
>>>>   name: body
>>>>
>>>>   description: |
>>>>
>>>> Scope object that needs to be updated
>>>>
>>>>   required: true
>>>>
>>>>   schema:
>>>>
>>>> $ref: '#/definitions/Scope'
>>>>
>>>>   responses:
>>>>
>>>> 200:
>>>>
>>>>   description: |
>>>>
>>>> OK.
>>>>
>>>> Successful response with updated Scope object
>>>>
>>>>   schema:
>>>>
>>>> $ref: '#/definitions/Scope'
>>>>
>>>>   headers:
>>>>
>>>> Content-Type:
>>>>
>>>>   description: |
>>>>
>>>> The content type of the body.
>>>>
>>>>   type: string
>>>>
>>>> 400:
>>>>
>>>>   description: |
>>>>
>>>> Bad Request.
>>>>
>>>> Invalid request or validation error
>>>>
>>>>   schema:
>>>>
>>>> $ref: '#/definitions/Error'
>>>>
>>>> 404:
>>>>
>>>>   description: |
>>>>
>>>> Not Found.
>>>>
>>>> The resource to be updated does not exist.
>>>>
>>>>   schema:
>>>>
>>>> $ref: '#/definitions/Error'
>>>>
>>>>
>>>> #-
>>>>
>>>> # Delete the definition of an API
>>>>
>>>> #-
>>>>
>>>> delete:
>>>>
>>>>   security:
>>>>
>>>> - OAuth2Security:
>>>>
>>>>   - apim:global_scope_manage
>>>>
>>>>   summary: Delete an API
>>>>
>>>>   description: |
>>>>
>>>> This operation can be used to delete an existing Global Scope
>>>> proving the Id of the scope.
>>>>
>>>>   parameters:
>>>>
>>>> - $ref: '#/parameters/scopeId
>>>>
>>>>   responses:
>>>>
>>>> 200:
>>>>
>>>>   description: |
>>>>
>>>> OK.
>>>>
>>>> Resource successfully deleted.
>>>>
>>>> 404:
>>>>
>>>>   description: |
>>>>
>>>> Not Found.
>>>>
>>>> Resource to be deleted does not exist.
>>>>
>>>>   schema:
>>>>
>>>> $ref: '#/definitions/Error'
>>>>
>>>> *FLOW*
>>>>
>>>> 1. A privileged user/administrative user logs into Publisher Portal and
>>>> creates a global scope providing name, description and role bindings.
>>>> 2. Upon checking whether the scope key is not duplicated in the
>>>> IDN_OAUTH2_SCOPE table, this scope will be added to the IDN_OAUTH2_SCOPE,
>>>> IDN_OAUTH2_SCOPE2_BINDING and AM_GLOBAL_SCOPE tables.
>>>> 3. An API developer creates an API and visits the resources page. The
>>>> list of scopes to add per resource is populated using the per-API scopes
>>>> from the API object and from the "GET /global-scopes" backend service call.
>>>> 4. The developer selects a set of global/per-API scopes for the
>>>> resource. The swagger is updated with the scopes list and resource scope
>>>> list. The backend service "PUT apis/{apiId}/swagger" updates the
>>>> IDN_OAUTH2_RESOURCE_SCOPE and AM_API_SCOPES table.
>>>> 5. App Developer will generate a token with the scopes and invoke the
>>>> API. During the KeyValidation service, when the scopes are validated for
>>>> the resource using the JDBCScopeValidator, it will check whether token
>>>> bears any of the given resource scopes.
>>>>
>>>> This is a draft design for the implementation. Hence appreciate your
>>>> suggestions/comments to improve the above. Once the above is finalized, we
>>>> will work on the UI design.
>>>>
>>>> Thanks
>>>>
>>>> *Dushani Wellappili*
>>>> Senior Software Engineer - WSO2
>>>>
>>>> Email : dusha...@wso2.com
>>>> Mobile : +94779367571
>>>> Web : https://wso2.com/
>>>>
>>>>
>>>>

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

Re: [Architecture] [APIM] Support Global OAuth2 Scopes and Attaching Multiple Scopes per API Resource

[Amila De Silva]

a:
>>>>>
>>>>> $ref: '#/definitions/ScopeList'
>>>>>
>>>>>   headers:
>>>>>
>>>>> Content-Type:
>>>>>
>>>>>   description: |
>>>>>
>>>>> The content type of the body.
>>>>>
>>>>>   type: string
>>>>>
>>>>> 500:
>>>>>
>>>>>description: Internal server error while retrieving global
>>>>> scope list
>>>>>
>>>>>schema:
>>>>>
>>>>> $ref: '#/definitions/Error'
>>>>>
>>>>>
>>>>> #-
>>>>>
>>>>> # Create a new global scope
>>>>>
>>>>> #-
>>>>>
>>>>> post:
>>>>>   security:
>>>>> - OAuth2Security:
>>>>>   - apim:global_scope_manage
>>>>>   summary: Add a new global scope
>>>>>   description: |
>>>>> This operation can be used to add a new global scope.
>>>>>   parameters:
>>>>> - in: body
>>>>>   name: body
>>>>>   description: |
>>>>> Scope object that needs to be added
>>>>>   required: true
>>>>>   schema:
>>>>> $ref: '#/definitions/Scope'
>>>>>   responses:
>>>>> 201:
>>>>>   description: |
>>>>> Created.
>>>>> Successful response with the newly created Scope object as
>>>>> an entity in the body.
>>>>>   schema:
>>>>> $ref: '#/definitions/Scope'
>>>>>   headers:
>>>>> Content-Type:
>>>>>   description: |
>>>>> The content type of the body.
>>>>>   type: string
>>>>> 400:
>>>>>   description: |
>>>>> Bad Request.
>>>>> Invalid request or validation error
>>>>>   schema:
>>>>> $ref: '#/definitions/Error'
>>>>> 415:
>>>>>   description: |
>>>>> Unsupported media type.
>>>>> The entity of the request was in a not supported format.
>>>>>
>>>>>
>>>>> ##
>>>>>
>>>>> # The "Individual Global Scope" resource APIs
>>>>>
>>>>> ##
>>>>>
>>>>>   /global-scopes/{scopeId}
>>>>>
>>>>>
>>>>> #-
>>>>>
>>>>> # Retrieve the details of a global scope
>>>>>
>>>>> #-
>>>>>
>>>>>
>>>>> get:
>>>>>
>>>>>   security:
>>>>>
>>>>> - OAuth2Security:
>>>>>
>>>>>   - apim:api_view
>>>>>
>>>>>   summary: Get details of a global scope
>>>>>
>>>>>   parameters:
>>>>>   - $ref: '#/parameters/scopeId'
>>>>>
>>>>>   responses:
>>>>>
>>>>> 200:
>>>>>
>>>>>   description: |
>>>>>
>>>>> OK.
>>>>>
>>>>> Requested Global Scope is returned.
>>>>>
>>>>>   schema:
>>>>>
>>>>> $ref: '#/definitions/Scope'
>>>>>
>>>>>   headers:
>>>>>
>>>>> Content-Type:
>>>>>
>>>>>   description: |
>>>>>
>>>>> The content type of the body.
>>>>>
>>>>>   type: string
>>>>>
>>>>> 404:
>>>>>   description: |
>>>>> Not Found.
>>>>> Requested Global Scope does not exist.
>>>>>   schema:
>>>>> $ref: '#/definitions/Error'
>>>>>
>>>>>
>>>>> #-
>>>>>
>>>>> # Update a global scope
>>>>>
>>>>> #-
>>>>>
>>>>> put:
>>>>>
>>>>>   security:
>>>>>
>>>>> - OAuth2Security:
>>>>>
>>>>>   - apim:global_scope_manage
>>>>>
>>>>>   summary: Update an API
>>>>>
>>>>>   description: |
>>>>>
>>>>> This operation can be used to update an existing Global Scope.
>>>>>
>>>>>   parameters:
>>>>>
>>>>> - $ref: '#/parameters/scopeId'
>>>>>
>>>>> - in: body
>>>>>
>>>>>   name: body
>>>>>
>>>>>   description: |
>>>>>
>>>>> Scope object that needs to be updated
>>>>>
>>>>>   required: true
>>>>>
>>>>>   schema:
>>>>>
>>>>> $ref: '#/definitions/Scope'
>>>>>
>>>>>   responses:
>>>>>
>>>>> 200:
>>>>>
>>>>>   description: |
>>>>>
>>>>> OK.
>>>>>
>>>>> Successful response with updated Scope object
>>>>>
>>>>>   schema:
>>>>>
>>>>> $ref: '#/definitions/Scope'
>>>>>
>>>>>   headers:
>>>>>
>>>>> Content-Type:
>>>>>
>>>>>   description: |
>>>>>
>>>>> The content type of the body.
>>>>>
>>>>>   type: string
>>>>>
>>>>> 400:
>>>>>
>>>>>   description: |
>>>>>
>>>>> Bad Request.
>>>>>
>>>>> Invalid request or validation error
>>>>>
>>>>>   schema:
>>>>>
>>>>> $ref: '#/definitions/Error'
>>>>>
>>>>> 404:
>>>>>
>>>>>   description: |
>>>>>
>>>>> Not Found.
>>>>>
>>>>> The resource to be updated does not exist.
>>>>>
>>>>>   schema:
>>>>>
>>>>> $ref: '#/definitions/Error'
>>>>>
>>>>>
>>>>> #-
>>>>>
>>>>> # Delete the definition of an API
>>>>>
>>>>> #-
>>>>>
>>>>> delete:
>>>>>
>>>>>   security:
>>>>>
>>>>> - OAuth2Security:
>>>>>
>>>>>   - apim:global_scope_manage
>>>>>
>>>>>   summary: Delete an API
>>>>>
>>>>>   description: |
>>>>>
>>>>> This operation can be used to delete an existing Global Scope
>>>>> proving the Id of the scope.
>>>>>
>>>>>   parameters:
>>>>>
>>>>> - $ref: '#/parameters/scopeId
>>>>>
>>>>>   responses:
>>>>>
>>>>> 200:
>>>>>
>>>>>   description: |
>>>>>
>>>>> OK.
>>>>>
>>>>> Resource successfully deleted.
>>>>>
>>>>> 404:
>>>>>
>>>>>   description: |
>>>>>
>>>>> Not Found.
>>>>>
>>>>> Resource to be deleted does not exist.
>>>>>
>>>>>   schema:
>>>>>
>>>>> $ref: '#/definitions/Error'
>>>>>
>>>>> *FLOW*
>>>>>
>>>>> 1. A privileged user/administrative user logs into Publisher Portal
>>>>> and creates a global scope providing name, description and role bindings.
>>>>> 2. Upon checking whether the scope key is not duplicated in the
>>>>> IDN_OAUTH2_SCOPE table, this scope will be added to the IDN_OAUTH2_SCOPE,
>>>>> IDN_OAUTH2_SCOPE2_BINDING and AM_GLOBAL_SCOPE tables.
>>>>> 3. An API developer creates an API and visits the resources page. The
>>>>> list of scopes to add per resource is populated using the per-API scopes
>>>>> from the API object and from the "GET /global-scopes" backend service 
>>>>> call.
>>>>> 4. The developer selects a set of global/per-API scopes for the
>>>>> resource. The swagger is updated with the scopes list and resource scope
>>>>> list. The backend service "PUT apis/{apiId}/swagger" updates the
>>>>> IDN_OAUTH2_RESOURCE_SCOPE and AM_API_SCOPES table.
>>>>> 5. App Developer will generate a token with the scopes and invoke the
>>>>> API. During the KeyValidation service, when the scopes are validated for
>>>>> the resource using the JDBCScopeValidator, it will check whether token
>>>>> bears any of the given resource scopes.
>>>>>
>>>>> This is a draft design for the implementation. Hence appreciate your
>>>>> suggestions/comments to improve the above. Once the above is finalized, we
>>>>> will work on the UI design.
>>>>>
>>>>> Thanks
>>>>>
>>>>> *Dushani Wellappili*
>>>>> Senior Software Engineer - WSO2
>>>>>
>>>>> Email : dusha...@wso2.com
>>>>> Mobile : +94779367571
>>>>> Web : https://wso2.com/
>>>>>
>>>>>
>>>>>
>
> --
> *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
>


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

Re: [Architecture] [Dev] [VOTE] Release WSO2 API Manager 2.0.0 RC5

[Amila De Silva]

Tested workflows. No issues found.

[+] Stable - go ahead and release

On Thu, Jul 28, 2016 at 2:02 AM, Abimaran Kugathasan <abima...@wso2.com>
wrote:

> *WSO2 API Manager 2.0.0-RC5 Released*
>
> This is the 5th Release Candidate of the WSO2 API Manager 2.0.0
>
> Source & binary distribution files of API Manager 2.0.0-RC5 :
>
>  Runtime : 
> *https://github.com/wso2/product-apim/releases/tag/v2.0.0-rc5
> <https://github.com/wso2/product-apim/releases/tag/v2.0.0-rc5>*
>  Analytics : 
> *https://github.com/wso2/analytics-apim/releases/tag/v2.0.0-rc5
> <https://github.com/wso2/analytics-apim/releases/tag/v2.0.0-rc5>*
>
> Please download, test the product and vote. Vote will be open for 72
> hours or as needed.
> Refer to github readme for guides.
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-]  Broken - do not release (please explain why)
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer - API Technologies
>
> Email : abima...@wso2.com
> Mobile : +94 773922820
>
> <http://stackoverflow.com/users/515034>
> <http://lk.linkedin.com/in/abimaran>
> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
> <https://twitter.com/abimaran>
>
>
> _______
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Amila De Silva]

Tested integrating a Third Party Key Manager, for both Super Tenant and
Tenant modes. Tests were carried out by calling the Jaggery APIs. No issues
were found.

[+] Go ahead and release.

On Thu, Jul 21, 2016 at 12:21 AM, Abimaran Kugathasan <abima...@wso2.com>
wrote:

>
> *WSO2 API Manager 2.0.0-RC3 Released*
>
> This is the 3rd Release Candidate of the WSO2 API Manager 2.0.0
>
> Source & binary distribution files of API Manager 2.0.0-RC3 :
>
>  Runtime :
> https://github.com/wso2/product-apim/releases/tag/v2.0.0-rc3
>  Analytics :
> https://github.com/wso2/analytics-apim/releases/tag/v2.0.0-rc3
>
> Please download, test the product and vote. Vote will be open for 72
> hours or as needed.
> Refer to github readme for guides.
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-]  Broken - do not release (please explain why)
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer
>
> Email : abima...@wso2.com
> Mobile : +94 773922820
>
> <http://stackoverflow.com/users/515034>
> <http://lk.linkedin.com/in/abimaran>
> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
> <https://twitter.com/abimaran>
>
>
> _______
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release WSO2 API Manager 2.0.0 RC1

[Amila De Silva]

Hi Malith,

For 1.10.0 the reported results have been obtained on an older setup. Will
obtain those on the new setup and report the values.

On Mon, Jul 18, 2016 at 2:44 PM, Malith Jayasinghe <mali...@wso2.com> wrote:

> Hi Abimaran,
>
> I am looking at the performance report of RC1 pack that you have attached.
>
> I notice that for scenario 3 there is a degradation performance (TPS and
> latency) in 2.0.0 RC1 compared to 1.10.0?
> Do we know why this is happening?
>
> Also did we notice this behaviour in 2.0.0 beta 2 pack?.
>
> I  notice that you have done detailed analysis of the performance (i.e.
> latency percentiles etc) for scenario 1 and scenario 2 but no such analysis
> for scenario 3?
>
> Thanks
>
> Malith
>
> On Mon, Jul 18, 2016 at 12:06 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>> We have encountered two issues [1] and [2] which need to be fixed. We
>> will cancel this vote and call for a RC2.
>>
>> [1] - https://wso2.org/jira/browse/APIMANAGER-5271
>> [2] - https://wso2.org/jira/browse/APIMANAGER-5270
>>
>> Thanks,
>> NuwanD.
>>
>> On Sat, Jul 16, 2016 at 11:24 PM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> *Tested Scenarios*
>>>
>>> Throttling - 4 levels in tenant and super tenant.
>>>
>>> Black listing
>>>
>>> +1
>>>
>>> Go ahead and release.
>>>
>>> Thanks
>>>
>>> On Sat, Jul 16, 2016 at 11:11 AM, Abimaran Kugathasan <abima...@wso2.com
>>> > wrote:
>>>
>>>> Hi All,
>>>>
>>>> Please find the Reformance Report for above RC pack.
>>>>
>>>> On Sat, Jul 16, 2016 at 5:25 AM, Abimaran Kugathasan <abima...@wso2.com
>>>> > wrote:
>>>>
>>>>> Hi Devs,
>>>>>
>>>>> *WSO2 API Manager 2.0.0-RC1 Released*
>>>>>
>>>>> This is the 1st Release Candidate of the WSO2 API Manager 2.0.0
>>>>>
>>>>> Please download, test the product and vote. Vote will be open for 72
>>>>> hours or as needed.
>>>>> Refer to github readme for guides.
>>>>>
>>>>> The distribution is available to download at [1]
>>>>>
>>>>> [1] : https://github.com/wso2/product-apim/releases/tag/v2.0.0-rc1
>>>>>
>>>>> *WSO2 **API Manager Analytics 2.0.0 RC1** Released*
>>>>>
>>>>> Please download, test the product and vote. Vote will be open for 72
>>>>> hours or as needed.
>>>>> Refer to github readme for guides.
>>>>>
>>>>> The distribution is available to download  [2]
>>>>>
>>>>> Fixed Issue in [3], known issues [4]
>>>>>
>>>>> [2] :
>>>>> https://github.com/wso2/analytics-apim/releases/download/v2.0.0-rc1/wso2am-analytics-2.0.0.zip
>>>>> [3] : https://wso2.org/jira/issues/?filter=13138
>>>>> [4] : https://wso2.org/jira/issues/?filter=13139
>>>>> <https://www.google.com/url?q=https%3A%2F%2Fwso2.org%2Fjira%2Fissues%2F%3Ffilter%3D13139=D=1=AFQjCNFtMhxKzEHrn2xHK4fm8d7VBx9VvQ>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks
>>>>> Abimaran Kugathasan
>>>>> Senior Software Engineer
>>>>>
>>>>> Email : abima...@wso2.com
>>>>> Mobile : +94 773922820
>>>>>
>>>>> <http://stackoverflow.com/users/515034>
>>>>> <http://lk.linkedin.com/in/abimaran>
>>>>> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
>>>>> <https://twitter.com/abimaran>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks
>>>> Abimaran Kugathasan
>>>> Senior Software Engineer
>>>>
>>>> Email : abima...@wso2.com
>>>> Mobile : +94 773922820
>>>>
>>>> <http://stackoverflow.com/users/515034>
>>>> <http://lk.linkedin.com/in/abimaran>
>>>> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
>>>> <https://twitter.com/abimaran>
>>>>
>>>>
>>>> ___
>>>> Dev mailing list
>>>> d...@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Tharindu Dharmarathna*Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94779109091 <%2B94779109091>*
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Technical Lead - 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
>>
>>
>
>
> --
> Malith Jayasinghe
>
>
> WSO2, Inc. (http://wso2.com)
> Email   : mali...@wso2.com
> Mobile : 0770704040
> Lean . Enterprise . Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Changing the interface for generating JWTs

[Amila De Silva]

Hi Abimaran,

If someone extends TokenGenerator interface, overriding other methods won't
have any effect. But by making signing and encoding public, users have the
option of only extending those steps (say that while using the default
generator) and create the JWT as needed.

On Fri, Jun 24, 2016 at 3:50 PM, Abimaran Kugathasan <abima...@wso2.com>
wrote:

> Hi Amila/Sanjeewa
>
>
> But, what is the usage of making encoding and signing as public method,
> they are supposed to withing token generation? If somebody customizes
> generating token, they have to write their own encoding and signing withing 
> generateToken
> method.
>
> Why need to give separate method for them?
>
> On Fri, Jun 24, 2016 at 3:46 PM, Amila De Silva <ami...@wso2.com> wrote:
>
>> Encoding part has now been changed to a public method. Can do the same
>> for signing too.
>>
>> On Fri, Jun 24, 2016 at 3:35 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
>> wrote:
>>
>>> @Amila, while doing this shouldn't we move encoding and signing part
>>> also to JWT generator?
>>> Then users will get more flexibility to customize those behavior as well.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Fri, Jun 24, 2016 at 3:26 PM, Amila De Silva <ami...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> In API Gateway , while generating a JWT in the request path,
>>>> TokenGenerator interface is used. Currently it supports the following two
>>>> method overloads;
>>>>
>>>> String generateToken(APIKeyValidationInfoDTO keyValidationInfoDTO,
>>>> String apiContext, String version) throws APIManagementException;
>>>>
>>>> String generateToken(APIKeyValidationInfoDTO keyValidationInfoDTO,
>>>> String apiContext, String version,
>>>> String accessToken) throws
>>>> APIManagementException;
>>>>
>>>> The topmost one was the first method added to the interface, and second
>>>> one was only added to address a limitation in the first one (As of now
>>>> first method is marked as a deprecate one).
>>>>
>>>> I suggest that we add the following method and deprecate both the
>>>> existing two methods;
>>>>
>>>> String generateToken(TokenValidationContext validationContext) throws
>>>> APIManagementException;
>>>>
>>>> Reasons for suggesting this change are
>>>>
>>>> 1. TokenValidationContext contain all the parameters used in the first
>>>> two methods.
>>>>
>>>> 2. JWT Generation happens at the KeyManager while executing
>>>> KeyValidationHandler. JWT Generation is the final phase of that handler,
>>>> and if we pass a TokenValidationContext to generateToken method, then
>>>> whatever the parameters that have been set in previous phases can be made
>>>> available at the JWT Generator (It's an object of the type
>>>> TokenValidationContext, that is passed across other phases in
>>>> KeyValidationHandler)
>>>>
>>>> Please share your thoughts on this.
>>>>
>>>> --
>>>> *Amila De Silva*
>>>>
>>>> WSO2 Inc.
>>>> mobile :(+94) 775119302
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779
>>>
>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>
>>>
>>>
>>
>>
>> --
>> *Amila De Silva*
>>
>> WSO2 Inc.
>> mobile :(+94) 775119302
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer
>
> Email : abima...@wso2.com
> Mobile : +94 773922820
>
> <http://stackoverflow.com/users/515034>
> <http://lk.linkedin.com/in/abimaran>
> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
> <https://twitter.com/abimaran>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Changing the interface for generating JWTs

[Amila De Silva]

Encoding part has now been changed to a public method. Can do the same for
signing too.

On Fri, Jun 24, 2016 at 3:35 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> @Amila, while doing this shouldn't we move encoding and signing part also
> to JWT generator?
> Then users will get more flexibility to customize those behavior as well.
>
> Thanks,
> sanjeewa.
>
> On Fri, Jun 24, 2016 at 3:26 PM, Amila De Silva <ami...@wso2.com> wrote:
>
>> Hi All,
>>
>> In API Gateway , while generating a JWT in the request path,
>> TokenGenerator interface is used. Currently it supports the following two
>> method overloads;
>>
>> String generateToken(APIKeyValidationInfoDTO keyValidationInfoDTO,
>> String apiContext, String version) throws APIManagementException;
>>
>> String generateToken(APIKeyValidationInfoDTO keyValidationInfoDTO,
>> String apiContext, String version,
>> String accessToken) throws
>> APIManagementException;
>>
>> The topmost one was the first method added to the interface, and second
>> one was only added to address a limitation in the first one (As of now
>> first method is marked as a deprecate one).
>>
>> I suggest that we add the following method and deprecate both the
>> existing two methods;
>>
>> String generateToken(TokenValidationContext validationContext) throws
>> APIManagementException;
>>
>> Reasons for suggesting this change are
>>
>> 1. TokenValidationContext contain all the parameters used in the first
>> two methods.
>>
>> 2. JWT Generation happens at the KeyManager while executing
>> KeyValidationHandler. JWT Generation is the final phase of that handler,
>> and if we pass a TokenValidationContext to generateToken method, then
>> whatever the parameters that have been set in previous phases can be made
>> available at the JWT Generator (It's an object of the type
>> TokenValidationContext, that is passed across other phases in
>> KeyValidationHandler)
>>
>> Please share your thoughts on this.
>>
>> --
>> *Amila De Silva*
>>
>> WSO2 Inc.
>> mobile :(+94) 775119302
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> <http://sanjeewamalalgoda.blogspot.com/>blog
> :http://sanjeewamalalgoda.blogspot.com/
> <http://sanjeewamalalgoda.blogspot.com/>
>
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] Changing the interface for generating JWTs

[Amila De Silva]

Hi All,

In API Gateway , while generating a JWT in the request path, TokenGenerator
interface is used. Currently it supports the following two method overloads;

String generateToken(APIKeyValidationInfoDTO keyValidationInfoDTO,
String apiContext, String version) throws APIManagementException;

String generateToken(APIKeyValidationInfoDTO keyValidationInfoDTO,
String apiContext, String version,
String accessToken) throws
APIManagementException;

The topmost one was the first method added to the interface, and second one
was only added to address a limitation in the first one (As of now first
method is marked as a deprecate one).

I suggest that we add the following method and deprecate both the existing
two methods;

String generateToken(TokenValidationContext validationContext) throws
APIManagementException;

Reasons for suggesting this change are

1. TokenValidationContext contain all the parameters used in the first two
methods.

2. JWT Generation happens at the KeyManager while executing
KeyValidationHandler. JWT Generation is the final phase of that handler,
and if we pass a TokenValidationContext to generateToken method, then
whatever the parameters that have been set in previous phases can be made
available at the JWT Generator (It's an object of the type
TokenValidationContext, that is passed across other phases in
KeyValidationHandler)

Please share your thoughts on this.

-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Fwd: WSO2 API Manager 2.0.0 BETA Released!

[Amila De Silva]

*WSO2 API Manager 2.0.0 BETA Released!*


We are pleased to announce the BETA release of WSO2 API Manager 2.0.0.

WSO2 API Manager is a complete solution for designing and publishing APIs,
securing and routing API traffic in a scalable way, whilst nurturing a
developer community around the API ecosystem.

This release comes with both the runtime and analytics, providing
out-of-the-box support for API usage and performance analysis. You can
download these distributions below.

Runtime  - wso2am-2.0.0-BETA.zip

Analytics - wso2analytics-apim-1.0.0-beta.zip




*Improvements and Bug Fixes*

Improvements

   -

   [APIMANAGER-3816 ] - Admin
   Dashboard URL to be included in the list of services available on the
   carbon message console
   -

   [APIMANAGER-4475 ] - API
   authentication error response should bear the message type provided the
   Accept header of the request
   -

   [APIMANAGER-4595 ] -
   Message type of "invalid token" error message should change based on the
   Content-Type Header
   -

   [APIMANAGER-4600 ] -
   Provide a configuration to allow for disabling the Forum in the API Store UI
   -

   [APIMANAGER-4719 ] - Error
   message doesn't convey it's purpose in API Versioning
   -

   [APIMANAGER-4737 ] -
   Remove the ( ) brackets when a description is not given for an
   applicationlevel tier
   -

   [APIMANAGER-4740 ] -
   Remove Exception thrown when subscribing to blocked subscription
   -

   [APIMANAGER-4852 ] -
   system should allow to delete alerts that are shown on admin dashboard
   -

   [APIMANAGER-4893 ] -
   Revisit the UI of "Add Subscription Tier"
   -

   [ANLYAPIM-20 ] - New theme
   needed for API Analytics
   -

   [ANLYAPIM-20 ] - New theme
   needed for API Analytics

Bug Fixes

   -

   [APIMANAGER-2522 ] - Wrong
   rights for the Implement Stage for creator role
   -

   [APIMANAGER-2688 ] - Forum
   topic search issue
   -

   [APIMANAGER-2703 ] - Blank
   drop down menu and wrong caption in the absence of tier permission for the
   logged in user
   -

   [APIMANAGER-2922 ] - JWT
   TokenGeneration Certificate Header Parameter x5t encoding.
   -

   [APIMANAGER-4117 ] - exp
   claim in JWT does not comply with rfc7519
   -

   [APIMANAGER-4242 ] - API
   Custom Mediation Sequences Doesn't Foward the Call To Taget Endpoint When a
   Call Mediator is Used
   -

   [APIMANAGER-4325 ] -
   Carbon console shows inconsistent error log for subsequent invocations when
   access token is expired.
   -

   [APIMANAGER-4468 ] - ERROR
   - NativeWorkerPool Uncaught exception
   -

   [APIMANAGER-4534 ] -
   APIConsole is not showing response content type,even we set a value for
   'produces' attribute in APIPublisher
   -

   [APIMANAGER-4554 ] -
   grant_type=refresh_token fails on 1.10 with message Error decoding
   authorization header. Space delimited " " format
   violated.
   -

   [APIMANAGER-4583 ] -
   AddComment in Store is not working with MySQL
   -

   [APIMANAGER-4584 ] -
   Environment dropdown of API Console does not appear in IE11
   -

   [APIMANAGER-4590 ] -
   Invalid Access Token, if RemoveOAuthHeader is false
   -

   [APIMANAGER-4621 ] - API
   resource name contains "*" character and not validate that in the design
   phase (UI level)
   -

   [APIMANAGER-4625 ] - Links
   to documents and in Readme should be 2.0.0 (Latest documents)
   -

   [APIMANAGER-4630 ] -
   Rename Tier Availability in API Wizard manage page to Subscription Tiers
   -

   [APIMANAGER-4640 ] - Forum
   does not show all the 

[Architecture] [APIM] CEP Based Throttling Implementation - Non clustered mode for MB Components

[Amila De Silva]

Hi All,

APIM 2.0.0 will have a new profile named Decision Engine , which will be
solely used for determining whether a request is throttled out  or not and
to propagate that decision across a Gateway cluster.
Decision engine is nothing more than CEP and MB components bundled into a
single profile. Throttling decision is taken by CEP components and is
published to a topic created by MB components.

In an HA setup of Decision Engine,
1. CEP components will have to stay clustered.
2. MB components will have to remain in isolation.

Since it's the CEP components which maintain the throttling counts, those
have to be shared between components running in both nodes. Clustering CEP
components is the way to do that.
But when enabling clustering in axis2.xml with the intention of getting CEP
components clustered, it would automatically put MB components into
clustering mode.
But to form a proper HA cluster with MB components, there have to be at
least three nodes and only having two clustered MB components can lead to
certain runtime issues. To keep the setup simple, the plan is to run MB
components in isolation (as two independent Message Brokers).
For this to happen, there should be a way to keep MB components
non-clustered even when clustering is enabled in axis2.xml.

What should be the proper way to do this?

-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][Analytics] Health monitor for APIM as a separate Java client

[Amila De Silva]

Hi Maheshakya,

How will the responses from APIs be used to determine health state of an
API. For example,would a 401 Unauthorized response be an indication of
particular API being healthy (sine the API is actually running and
accepting requests ) or is simply dis-regarded because it doesn't complete
the full round trip through the backend?

Is this tool used only to give an idea about the uptime of an API to public
users? Or does this also allow Dev Ops to get an idea like which APIs
deployed on which GW nodes are working properly, which are not...

On Tue, Feb 16, 2016 at 4:47 AM, Maheshakya Wijewardena <mahesha...@wso2.com
> wrote:

> Hi,
>
> Following points elaborates further about the considerations on which Java
> client for API health monitoring is based.
>
>- This will be implemented as a separate java client which pings the
>APIs periodically.
>- This will incorporate full life cycle of an API tries to demonstrate
>end-to-end behavior from client perspective.
>- This consumes quota from the whole API, therefore client needs to
>manage it.
>- In deployment, DAS resides inside the firewall and it needs to have
>a port open for the health monitor to publish. This will be done via a
>secured channel with HTTPS.
>- Health monitor will provide statuses such as for time intervals
>like, last hour, last week and  summarizations.
>- Error codes from endpoints will be tracked separately and will
>provide drilled down descriptions based on those codes.
>- A list of APIs that needs to be monitored will be obtained from the
>user as a config.
>- The DAS dashboard is similar to
>http://apimetrics.io/check-api-health/ .
>
> Best regards.
>
>
> On Tue, Feb 16, 2016 at 5:06 AM, Dilan Udara Ariyaratne <dil...@wso2.com>
> wrote:
>
>> Hi Maheshakya,
>>
>> Can you also briefly explain how is this client going to monitor the
>> health of an API and
>> what considerations are being made to check the health?
>>
>> Thanks.
>>
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94725197942
>> lean . enterprise . middleware
>>
>> On Mon, Feb 15, 2016 at 12:34 PM, Lahiru Sandaruwan <lahi...@wso2.com>
>> wrote:
>>
>>> Hi Maheshakya,
>>>
>>>
>>> On Mon, Feb 15, 2016 at 11:59 AM, Maheshakya Wijewardena <
>>> mahesha...@wso2.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> After discussing with API analytics team, the health monitor component
>>>> for API analytics has been decided to be implemented as a separate java
>>>> client.
>>>>
>>>
>>> What is the reason for this decision? The load on the APIM server if a
>>> stat publishing agent is run?
>>>
>>> Thanks.
>>>
>>>> This is essentially a scheduled program which pings the APIs to check
>>>> their statuses.
>>>> The conventional way of implementing this is by adding it as a
>>>> scheduled task in the ESB. But in the point view of deployment, this adds
>>>> the complexity of having an ESB just to host the health monitor for APIM.
>>>>
>>>> What would be the most appropriate solution to implement this health
>>>> monitor, considering both the intricacy of deployment and the standards.
>>>>
>>>> Best regards.
>>>> --
>>>> Pruthuvi Maheshakya Wijewardena
>>>> mahesha...@wso2.com
>>>> +94711228855
>>>>
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Lahiru Sandaruwan
>>> Committer and PMC member, Apache Stratos,
>>> Senior Software Engineer,
>>> WSO2 Inc., http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> phone: +94773325954
>>> email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/
>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Pruthuvi Maheshakya Wijewardena
> mahesha...@wso2.com
> +94711228855
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

[Amila De Silva]

Hi Tharika,

Since *"**saasApp"* is not a common parameter as per the spec, you might
have to emphasise the usage of it.

Just noticed that in the excerpt you've provided request is sent to a
resource named oauthdcr. Better if we can name it as /regsiter to show the
conformity with the spec.

On Thu, Feb 4, 2016 at 9:52 PM, Tharika Madurapperuma <thar...@wso2.com>
wrote:

> Hi All,
>
> We are planning of $subject.
>
> In some use cases, it is desirable or necessary to allow OAuth clients to
> obtain authorization from an authorization server without the two parties
> having previously interacted. Therefore in order for the authorization
> server to accurately represent to end users which client is seeking
> authorization to access the end user’s resources, a method for automatic
> and unique registration of clients is needed. This is where the Dynamic
> Client Registration protocol comes into play.
>
> The RFC related to this feature can be found in [1]
>
> *Problem*
>
> Currently, we have implementations for DCR in products like WSO2 API
> Manager and WSO2 Enterprise Mobility Manager. This leads to a duplication
> of the functionality. Since this feature should ideally reside in the WSO2
> Identity Server, we are trying to move it to their code base so that it
> will be available to the entire WSO2 platform.
>
> *Solution*
>
> We are trying to implement it so that the endpoint for registering and
> unregistering an OAuth client will be available through the oauth2 web app
> being deployed through the Identity Server.
>
>
> This feature is implemented as an OSGi service. The endpoint details will
> be as follows.
>
>
> Registering an OAuth 2.0 client application will take place through a POST
> request to the registration endpoint. For example see the following sample
> request,
>
>
> POST *oauth2/oauthdcr* HTTP/1.1
> Content-Type: application/json
>
> {
> "callbackUrl": "www.google.lk",
> "clientName": "MyApp",   //OAuth application name
> "tokenScope": "Production",
> "owner": "admin",   //User name of application owner
> "grantType": "password refresh_token",   //space separated grant-type
> list
> "saasApp" :true  //indicates whether this is a SaaS app or not
> }
>
>
> Upon successful registration you'll receive a json payload including the
> client-name, client-id, client-secret and the callback-url.
>
>
> Similarly unregistering an OAuth 2.0 client application will take place
> through a DELETE request to the registration endpoint with the
> applicationName, userId(username of the application owner) and the
> consumerKey taken in as query parameters in the request.
>
> [1] https://tools.ietf.org/html/rfc7591
>
>
> Tharika Madurapperuma
> Intern - Software Engineering
> WSO2, Inc.
> Mobile : +94777-875-624
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] API Manager REST API separation for store and publisher.

[Amila De Silva]

Hi Sanjeewa,

On Tue, Oct 13, 2015 at 10:46 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> Hi All,
> API Manager team planned to add complete REST API support for API
> Management operations available in product.
> Since initial implementation is done we are thinking about next steps of
> REST service.
> In this mail we need to discuss about separating API Manager store and
> publisher operations.
>
> *Improvement*
> In current REST API is developed as single web application.
> It will be deployed in API Management server and it can perform both
> store/ publisher operations.
> But so far we had clear separation between API store and
> publisher(Publisher to create/manage APIs and store to manage subscriptions
> etc).
> With new REST API we need to do something similar to manage same behavior.
> This will be important if we deploy API Manager in fully distributed
> deployment. In that case API store will be deployed in DMZ and we shouldn't
> allow publisher operations from that(API create publish should not possible
> from outside).
> To have this kind of separation we may need 2 web applications or single
> web application with 2 contexts.
>
> *Suggested solutions*
> 01. Deploy API Manager store and publisher as 2 separate applications.
>   Then we will have 2 applications named api#am#store#v1.war and
> api#am#publisher#v1.war.
>   These 2 applications will be deployed in contexts api/am/store/v1
> and api/am/publisher/v1.
>   If we deploy store profile we can remove publisher web service and
> if its publisher we can remove store web service.
>
> 02. Have single Applications(web service) which register 2 sub contexts.
>   We can define mapped classes according to each context(here contexts
> are api/am/store/v1 and api/am/publisher/v1 ).
>   We can add service beans(service beans like apis, applications, tags
> etc) on top of these two base contexts.
>   If we deploy store profile we need to disable service bean group for
> publisher. To do this we need to edit beans.xml and redeploy .war file.
>
> If we go for first approach we will have 2 applications and it do not
> require web application modifications.
>
> *Challenges*
> When we implement 2 different services for API store and publisher there
> will be some duplicates.
> As example we can consider following
> /apis GET in publisher will return complete API details with back end urls
> etc.
> But /apis GET in store will return us only detail required for store
> functionality(in this case back end user will not present in response
> instead it will have gateway API URL).
> Same applies for tiers as well(we can edit tiers in publisher but in store
> we can see available tier name list when we subscribe to API).
> So we need to carefully separate these functionalities.
>

If I understood correctly, difference in object models will only come into
effect when creating the output/accepting inputs at the REST API layer. But
when performing a core operation (persisting an API or retrieving it,
publishing an API etc...), the App specific model will be converted to a
single format (a domain specific model).
For example, the API model used in Publisher REST API, will have more
fields than the one used in Store REST API. So outputs when called a GET on
/publisher/apis/{apiId}  and a GET on /store/apis/{apiId} will be
different. But from the point where the API is retrieved from the
database/registry, to the point where it's handed over to REST API, the API
will be represented using one model.

So AFAIU even there are duplicates, those duplicates will only exist at the
REST API layer. Core operations won't get duplicated.

Even from a security point of view, it's good to have two different models
(since it minimises the risk of exposing unwanted information Publicly, for
example revealing backend endpoints at Store App) +1 for the keeping two
Apps, which uses two different models.

>
> If we go for 2 different applications sometimes we may need 2 different
> api.yaml files to maintain operation isolation.
> Main reason for that is API object return from publisher API may different
> from API object return from store API.
> So there will be 2 models for API object based on service
> type(store/publisher).
> Or other option is maintain single data model and fill required data based
> on used service(if its publisher back end URL parameter will present with
> value but if its store then back end URLs will not be there).
> We need to discuss this and come to conclusion.
>
> I'm sure we need to focus on this when we implement ES REST API.
> Appreciate your suggestions and comments on this.
>
> Thanks,
> sanjeewa.
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> <h

Re: [Architecture] [APIM] Hard Throttling limit for APIs

[Amila De Silva]

On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> I also believe we should use existing handler without writing new one.
>
> And regarding registry decoupling, publisher may be able to push API to
> gateway as we do now.
> And just before we call rest API admin service we may call registry admin
> service(may be we need to write simple service for this as flow continue
> with super admin - super tenant deployed multi tenanted service) and push
> tiers.xml file.
> With that we may keep registry separation between gateway and publisher.
> That would be valuable when we have MZ and DMZ pattern and gateway in DMZ.
>
> Thanks,
> sanjeewa.
>
>
> On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva <ami...@wso2.com> wrote:
>
>> Hi Nuwan,
>>
>>
>>
>> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> This design brings on a hard (mandatory) dependency to the registry from
>>> the API Gateway right? If each API is to have its own policy definition,
>>> the publisher and gateway must connect to a single registry. This will
>>> cause problems in some deployment patterns which have the Gateway in DMZ
>>> and publisher in the LAN. Can our throttling engine work if we just feed it
>>> the request count and unit time without feeding it a policy definition?
>>>
>>
>> Not in a very straightforward way. The API exposed by throttle.core only
>> allows passing ThrottleContext, a key and the Tier name. When going through
>> the usages of ThrottleContext it seems that it can only be created out from
>> a policy file. But need to check if it's possible to create ThrottleContext
>> only using unit time and MaxRequest count.
>>
>>> If that works then we can survive without the registry for this.
>>>
>> We can keep max request count and unit time in the API itself. While
initialising the APIThrottleHandler, a policy.xml has to be created out of
these values and the generated policy will be used to create the
ThrottleContext. Dynamic policy won't be stored anywhere, so when moving
the API from one environment to another, there won't be a risk of losing
anything.

For the scope of this feature, should be consider about providing
capability to specify hard throttling limits per each resource verb
combination.

>
>> Another option is to use the same tiers.xml that is being used for other
>> throttling cases and refer to a role defined there. If needed to update/add
>> a new tier it will have to be done through tier edit UI. Even with this
>> approach, the problem won't be completely solved.
>>
>>>
>>> Why would we need a new handler? What would be the drawbacks of using
>>> the existing handler?
>>>
>> We can use the existing one.
>>
>>>
>>> The location to get the limit would be on the API Implement section IMO.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Sep 8, 2015 at 9:40 PM, Amila De Silva <ami...@wso2.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Current Throttling capabilities of API Manager only allows defining
>>>> user wise and Application wise Access Quotas.
>>>>
>>>>
>>>> For example when considering an Application and a set of APIs
>>>> Subscribed, like below (tier limit is shown next to the API)
>>>>
>>>> Application-1 (1000 Req/min)
>>>> |
>>>> +-+API-1 (10 Req/min)
>>>> |
>>>> +-+API-2 (1 Req/min)
>>>> |
>>>> +-+API-3 (5 Req/min)
>>>>
>>>> each new token would allow end-users to make the number of requests
>>>> defined by the tier. Using a token generated for Application-1, API1 can be
>>>> invoked at a rate of 10 Req/min, API-2 - 1Req/min and likewise. So when a
>>>> new user signs in, there'd be a potential increase in the traffic on the
>>>> API.
>>>>
>>>> As of now there isn't a way to limit the total number of calls made on
>>>> an API. Tiers defined at the API Level, doesn't reflect the global limit of
>>>> the backend; which means that, as an API keeps gathering users, hits on the
>>>> Backend would also keep increasing without being controlled.
>>>>
>>>> With API Manager 1.10.0, the plan is to provide the capability to
>>>> define Hard Throttling limits for APIs. The limit will be defined per API
>>>> basis, and this usually will reflect the number of requests the actual
>>>> backend can handle.
&g

Re: [Architecture] [APIM] Hard Throttling limit for APIs

[Amila De Silva]

On Wed, Sep 16, 2015 at 1:42 PM, Amila De Silva <ami...@wso2.com> wrote:

>
> On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>
>> I also believe we should use existing handler without writing new one.
>>
>> And regarding registry decoupling, publisher may be able to push API to
>> gateway as we do now.
>> And just before we call rest API admin service we may call registry admin
>> service(may be we need to write simple service for this as flow continue
>> with super admin - super tenant deployed multi tenanted service) and push
>> tiers.xml file.
>> With that we may keep registry separation between gateway and publisher.
>> That would be valuable when we have MZ and DMZ pattern and gateway in DMZ.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>> On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva <ami...@wso2.com> wrote:
>>
>>> Hi Nuwan,
>>>
>>>
>>>
>>> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>> This design brings on a hard (mandatory) dependency to the registry
>>>> from the API Gateway right? If each API is to have its own policy
>>>> definition, the publisher and gateway must connect to a single registry.
>>>> This will cause problems in some deployment patterns which have the Gateway
>>>> in DMZ and publisher in the LAN. Can our throttling engine work if we just
>>>> feed it the request count and unit time without feeding it a policy
>>>> definition?
>>>>
>>>
>>> Not in a very straightforward way. The API exposed by throttle.core only
>>> allows passing ThrottleContext, a key and the Tier name. When going through
>>> the usages of ThrottleContext it seems that it can only be created out from
>>> a policy file. But need to check if it's possible to create ThrottleContext
>>> only using unit time and MaxRequest count.
>>>
>>>> If that works then we can survive without the registry for this.
>>>>
>>> We can keep max request count and unit time in the API itself. While
> initialising the APIThrottleHandler, a policy.xml has to be created out of
> these values and the generated policy will be used to create the
> ThrottleContext. Dynamic policy won't be stored anywhere, so when moving
> the API from one environment to another, there won't be a risk of losing
> anything.
>
> For the scope of this feature, should be consider about providing
> capability to specify hard throttling limits per each resource verb
> combination.
>

Accidentally sent the mail halfway :)

What I was going to highlight was need of having different hard limits for
each resource + verb combination.

Not every resource of an API, consume the same amount of server resources.
For example, when sending response to an OPTIONS call, the backend might be
sending a cached (or a static) response, whilst when responding to a POST,
it might be doing several DB calls back and forth. Actually, it might be an
overflow of POST requests that can take the back-end down. So while
specifying a quota, heavy weight resources should be given less quota, and
lightweight (but more frequently accessed resources) should be given a
higher quota.

Another option is to use the same tiers.xml that is being used for other
>>> throttling cases and refer to a role defined there. If needed to update/add
>>> a new tier it will have to be done through tier edit UI. Even with this
>>> approach, the problem won't be completely solved.
>>>
>>>>
>>>> Why would we need a new handler? What would be the drawbacks of using
>>>> the existing handler?
>>>>
>>> We can use the existing one.
>>>
>>>>
>>>> The location to get the limit would be on the API Implement section IMO.
>>>>
>>>> Thanks,
>>>> NuwanD.
>>>>
>>>> On Tue, Sep 8, 2015 at 9:40 PM, Amila De Silva <ami...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Current Throttling capabilities of API Manager only allows defining
>>>>> user wise and Application wise Access Quotas.
>>>>>
>>>>>
>>>>> For example when considering an Application and a set of APIs
>>>>> Subscribed, like below (tier limit is shown next to the API)
>>>>>
>>>>> Application-1 (1000 Req/min)
>>>>> |
>>>>> +-+API-1 (10 Req/min)
>>>>> |
>>>>> +-+API-2 (1 Req/min)
>>>>> |
>>

Re: [Architecture] [APIM] Hard Throttling limit for APIs

[Amila De Silva]

On Wed, Sep 16, 2015 at 5:08 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> Yes what you said have value actually.
> But wont it make things complicated? For the initial implementation we may
> go with configuration per API/Endpoint.
> May be later we need to implement something to have multiple back end
> services for same API(endpoint per resource).
> And at that point we need to have something like you mentioned.
>
> And did we checked DMZ/MZ problem here.
> What do you mean by having max count inside API. Is it meant in synapse
> configuration?
>
Yes, as two properties of APIThrottleHandler.

>
> Thanks,
> sanjeewa.
>
> On Wed, Sep 16, 2015 at 2:11 PM, Amila De Silva <ami...@wso2.com> wrote:
>
>>
>>
>> On Wed, Sep 16, 2015 at 1:42 PM, Amila De Silva <ami...@wso2.com> wrote:
>>
>>>
>>> On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
>>> wrote:
>>>
>>>> I also believe we should use existing handler without writing new one.
>>>>
>>>> And regarding registry decoupling, publisher may be able to push API to
>>>> gateway as we do now.
>>>> And just before we call rest API admin service we may call registry
>>>> admin service(may be we need to write simple service for this as flow
>>>> continue with super admin - super tenant deployed multi tenanted service)
>>>> and push tiers.xml file.
>>>> With that we may keep registry separation between gateway and publisher.
>>>> That would be valuable when we have MZ and DMZ pattern and gateway in
>>>> DMZ.
>>>>
>>>> Thanks,
>>>> sanjeewa.
>>>>
>>>>
>>>> On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva <ami...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Nuwan,
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>>
>>>>>> This design brings on a hard (mandatory) dependency to the registry
>>>>>> from the API Gateway right? If each API is to have its own policy
>>>>>> definition, the publisher and gateway must connect to a single registry.
>>>>>> This will cause problems in some deployment patterns which have the 
>>>>>> Gateway
>>>>>> in DMZ and publisher in the LAN. Can our throttling engine work if we 
>>>>>> just
>>>>>> feed it the request count and unit time without feeding it a policy
>>>>>> definition?
>>>>>>
>>>>>
>>>>> Not in a very straightforward way. The API exposed by throttle.core
>>>>> only allows passing ThrottleContext, a key and the Tier name. When going
>>>>> through the usages of ThrottleContext it seems that it can only be created
>>>>> out from a policy file. But need to check if it's possible to create
>>>>> ThrottleContext only using unit time and MaxRequest count.
>>>>>
>>>>>> If that works then we can survive without the registry for this.
>>>>>>
>>>>> We can keep max request count and unit time in the API itself. While
>>> initialising the APIThrottleHandler, a policy.xml has to be created out of
>>> these values and the generated policy will be used to create the
>>> ThrottleContext. Dynamic policy won't be stored anywhere, so when moving
>>> the API from one environment to another, there won't be a risk of losing
>>> anything.
>>>
>>> For the scope of this feature, should be consider about providing
>>> capability to specify hard throttling limits per each resource verb
>>> combination.
>>>
>>
>> Accidentally sent the mail halfway :)
>>
>> What I was going to highlight was need of having different hard limits
>> for each resource + verb combination.
>>
>> Not every resource of an API, consume the same amount of server
>> resources. For example, when sending response to an OPTIONS call, the
>> backend might be sending a cached (or a static) response, whilst when
>> responding to a POST, it might be doing several DB calls back and forth.
>> Actually, it might be an overflow of POST requests that can take the
>> back-end down. So while specifying a quota, heavy weight resources should
>> be given less quota, and lightweight (but more frequently accessed
>> resources) should be given a higher quota.
>>
>> Another op

Re: [Architecture] [APIM] Hard Throttling limit for APIs

[Amila De Silva]

For displaying at Publisher, throttling limits have to persisted on a DB in
some format (either in the registry artifact, in the swagger definition or
in AM_API table). But at the runtime, values will be picked from the
synapse definition.

Plan is to enforce the hard limit on a particular version of the API. For
example if there are two APIs having two versions v1 and v2, the hard limit
defined on v1 only ensures requests flowing through v1 version doesn't
exceed the specified limit.

On Wed, Sep 16, 2015 at 5:11 PM, Amila De Silva <ami...@wso2.com> wrote:

>
>
> On Wed, Sep 16, 2015 at 5:08 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>
>> Yes what you said have value actually.
>> But wont it make things complicated? For the initial implementation we
>> may go with configuration per API/Endpoint.
>> May be later we need to implement something to have multiple back end
>> services for same API(endpoint per resource).
>> And at that point we need to have something like you mentioned.
>>
>> And did we checked DMZ/MZ problem here.
>> What do you mean by having max count inside API. Is it meant in synapse
>> configuration?
>>
> Yes, as two properties of APIThrottleHandler.
>
>>
>> Thanks,
>> sanjeewa.
>>
>> On Wed, Sep 16, 2015 at 2:11 PM, Amila De Silva <ami...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Sep 16, 2015 at 1:42 PM, Amila De Silva <ami...@wso2.com> wrote:
>>>
>>>>
>>>> On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
>>>> wrote:
>>>>
>>>>> I also believe we should use existing handler without writing new one.
>>>>>
>>>>> And regarding registry decoupling, publisher may be able to push API
>>>>> to gateway as we do now.
>>>>> And just before we call rest API admin service we may call registry
>>>>> admin service(may be we need to write simple service for this as flow
>>>>> continue with super admin - super tenant deployed multi tenanted service)
>>>>> and push tiers.xml file.
>>>>> With that we may keep registry separation between gateway and
>>>>> publisher.
>>>>> That would be valuable when we have MZ and DMZ pattern and gateway in
>>>>> DMZ.
>>>>>
>>>>> Thanks,
>>>>> sanjeewa.
>>>>>
>>>>>
>>>>> On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva <ami...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Nuwan,
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>>>
>>>>>>> This design brings on a hard (mandatory) dependency to the registry
>>>>>>> from the API Gateway right? If each API is to have its own policy
>>>>>>> definition, the publisher and gateway must connect to a single registry.
>>>>>>> This will cause problems in some deployment patterns which have the 
>>>>>>> Gateway
>>>>>>> in DMZ and publisher in the LAN. Can our throttling engine work if we 
>>>>>>> just
>>>>>>> feed it the request count and unit time without feeding it a policy
>>>>>>> definition?
>>>>>>>
>>>>>>
>>>>>> Not in a very straightforward way. The API exposed by throttle.core
>>>>>> only allows passing ThrottleContext, a key and the Tier name. When going
>>>>>> through the usages of ThrottleContext it seems that it can only be 
>>>>>> created
>>>>>> out from a policy file. But need to check if it's possible to create
>>>>>> ThrottleContext only using unit time and MaxRequest count.
>>>>>>
>>>>>>> If that works then we can survive without the registry for this.
>>>>>>>
>>>>>> We can keep max request count and unit time in the API itself. While
>>>> initialising the APIThrottleHandler, a policy.xml has to be created out of
>>>> these values and the generated policy will be used to create the
>>>> ThrottleContext. Dynamic policy won't be stored anywhere, so when moving
>>>> the API from one environment to another, there won't be a risk of losing
>>>> anything.
>>>>
>>>> For the scope of this feature, should be consi

Re: [Architecture] [APIM] Extend Subscription Workflow

[Amila De Silva]

Does this mean that depending on the outcome of running 'execute' method,
Subscription workflow should be able change the HTTP response code (302 if
a re-direct) sent back to the invoker?



On Mon, Sep 14, 2015 at 12:02 PM, Nuwan Dias <nuw...@wso2.com> wrote:

> IMO, checking the user information, payment information, etc are
> implementation details of the workflow. What the WorkflowExecutor lacks
> today is the ability to do http redirections when a workflow has been
> executed/completed. We shouldn't worry about the implementation details of
> the workflow but focus on extending its capability to support those
> implementations.
>
> The 'execute' and 'complete' functions have no return type ATM. We should
> probably introduce something like a "WorkflowResponse" abstract type. This
> could be HttpResponses or any other form of responses. The response type
> implementation should take care of what happens after the 'execute' and
> 'complete' actions.
>
> Thanks,
> NuwanD.
>
>
>
> On Mon, Sep 14, 2015 at 9:48 AM, Madusanka Premaratne <madusan...@wso2.com
> > wrote:
>
>> Hi All,
>> I am going to implement the $subject for WSO2 API manager to enable the
>> capability of handling paid APIs. The data flow diagram can be seen as
>> follows.
>>
>>
>> ​
>> ​
>>
>> As described in the figure above if there are no payment plans set for
>> the subscriber the workflow will redirect to third party/inbuilt web page
>> to collect those information. If those are already defined it will just
>> continue the subscription process.
>>
>> To fulfil the above task, I am going to change the existing *execute*
>> method of *WorkflowExecutor* to handle the redirection process and to
>> receive the feedback. After the operation from the webpage/ the required
>> details are already collected the webpage will send a response back to
>> workflow executer to complete the execution and complete the subscription.
>>
>> Suggestions and feedbacks are welcome.
>>
>> Thanks,
>> Madusanka
>>
>> --
>> *Madusanka Premaratne* | Associate Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 71 835 70 73| Work: +94 112 145 345
>> Email: madusan...@wso2.com | Web: www.wso2.com
>>
>> [image: Facebook] <https://www.facebook.com/maduzanka> [image: Twitter]
>> <https://twitter.com/rmmpremaratne> [image: Google Plus]
>> <https://plus.google.com/u/0/+MadusankaPremaratnemaduz/about/p/pub> [image:
>> Linkedin] <http://lk.linkedin.com/in/madusanka/> [image: Instagram]
>> <http://instagram.com/madusankapremaratne> [image: Skype]
>> <http://@rmmpremaratne>
>>
>>
>
>
> --
> Nuwan Dias
>
> Technical Lead - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>



-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Authenticator support for REST APIs exposed in API Manager, AF, CloudMgt applications

[Amila De Silva]

+ Ranga

On Fri, Sep 11, 2015 at 10:42 AM, Amila De Silva <ami...@wso2.com> wrote:

>
>
> On Friday, September 11, 2015, Manjula Rathnayake <manju...@wso2.com>
> wrote:
>
>> Hi all,
>>
>> Above REST APIs are secured with username/password login. But there are
>> scenarios, where client(AF or any other server) do not have the password of
>> the user to login and invoke these APIs. One mechanism introduced was to
>> make use of SAML token of the logged in user of AF(another server) to
>> authenticate to REST APIs and invoke.
>>
>> We recently faced another issue with above SAML token based login
>> approach when we test the REST APIs with curl, http clients etc because we
>> do not have the password of the user or the SAML token of the user.
>>
>> So we need to allow clients to choose different authentication mechanism
>> based on different requirements. One such requirement is to authenticate on
>> behalf of another user(say on behalf on currently logged in user to one
>> server). To provide this requirement, we need to introduce new login method
>> similar to login(username, password), loginWithSAMLToken(token) as
>> loginWthSignedJWTToken(token) etc.
>>
>> Do we have another authentication mechanism implemented for REST APIs
>> similar to Carbon authenticators? As a quick fix, we can include above
>> method and get it done, But we need to come  up with a proper
>> authentication mechanism, where we can configure multiple authentication
>> options etc for REST APIs. WDYT?
>>
>  +1.
> Apart from the ones shipped with the product, currently the capability is
> not there to plug in a new authenticator for REST APIs.
>
> IIRC, while doing the Key Manager separation, a new authentication method
> was provided to sign in using an id_token.But not sure to what extent this
> would be helpful for your scenario.
>
>> thank you.
>>
>> --
>> Manjula Rathnayaka
>> Associate Technical Lead
>> WSO2, Inc.
>> Mobile:+94 77 743 1987
>>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] Authorization server decoupling - Changes in configurations and in Server Profiles

[Amila De Silva]

Hi All,

Objective of this mail is to highlight the changes that needs to be done in
server profiles and in configuration files while implementing this feature.

As of now when Gateway receives a request, it talks to a server which
performs the following operations;

1. Get details of the access token by querying the Database.
2. Check the validity of the token.
3. Check if the user is subscribed to the API.
4. Check if the token has necessary scopes to access the resource.
5. Generate JWT using details derived from the token.

In this design, the server to which GW calls is the same entity which
manages tokens. So calling this entity as Key Manager suits in this
scenario.

After decoupling the Authorization server, the server to which GW calls,
will not be the same entity that manages tokens. To make this distinction
clear, a new profile will be introduced (which we'll refer to as Key
Validator for now). Basically GW calls to Key Validator which performs all
the above operations except 1st and 2nd. To complete its validation, Key
Validator obtains token details by calling to a Key Manager (Authorization
Server) - which can either be the one shipped with APIM or else a third
party one.


1st Diagram illustrates the interaction between server profiles we
currently have and the second diagram shows the interactions after adding
the new profile.



​
Boxes in the diagram represent the profiles, not the server instances in a
deployment. When using the inbuilt KM, a typical deployment will have
KeyValidator and KeyManager profiles in the same JVM. All the server roles
except Gateway, will have to know about Key Manager.

These are the changes happening in configuration files;

1. Key-Manager section in api-manager.xml will be changed as Key-Validator
a. TokenEndPointName and RevokeAPIURL elements will be removed from
Key-Validator section.
b. Two new elements ApplicationTokenScope 
KeyValidationHandlerClassName will be introduced.

2. A new config named key-manager.xml will be introduced.
Purpose of having this file is to provide a single location to keep all the
settings, configs used by a KeyManager implementation.

This is the structure of the key-manager.xml to be shipped with APIM by
default.

KeyManager class=org.wso2.carbon.apimgt.keymgt.AMDefaultKeyManagerImpl
xmlns=http://wso2.org/projects/apimgt/key-manager.xml;
Configuration
  AuthorizationServerURLhttps://localhost:9443/services/
/AuthorizationServerURL
  TokenURLhttps://localhost:8243/token/TokenURL
  RevokeURLhttps://localhost:8243/revoke/RevokeURL
/Configuration
/KeyManager

Since generating/revoking tokens are done by the class implementing
KeyManager interface, those urls have been moved in to this config.

Contents inside the Configuration block can change based on the
implementing class. For example, when plugging in an third party Key
Manager (Authorization Server), introspect endpoint might have to be
provided.

Please share your thoughts.

-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Authorization server decoupling - Changes in configurations and in Server Profiles

[Amila De Silva]

Hi Colin,

On Mon, Apr 6, 2015 at 8:09 PM, Colin Roy-Ehri col...@wso2.com wrote:

 Hi,

 Adding an additional server profile adds additional complexity, and
 separating the config files may help clarify this.  I highly recommend
 extensive comments describing the different configurations within the new
 xml file.  Also, adding comments to the renamed api-validator section of
 the api-manager file would also be helpful.

+1. Would have to specifically mention about the changes in official docs.


 In this new model, where would the authorize, revoke, and token gateway
 APIs point?

These APIs should point to Key Manager. When using a third party Key
Manager, these APIs need to be changed providing the correct OAuth
endpoints. In the default case, APIs will point to endpoints in oauth2.war.



 Thanks,
 Colin Roy-Ehri
 Software Engineer
 *WSO2, Inc. : wso2.com http://wso2.com/*
 *Mobile*  : 812-219-6517

 On Mon, Apr 6, 2015 at 5:14 AM, Amila De Silva ami...@wso2.com wrote:

 Hi All,

 Objective of this mail is to highlight the changes that needs to be done
 in server profiles and in configuration files while implementing this
 feature.

 As of now when Gateway receives a request, it talks to a server which
 performs the following operations;

 1. Get details of the access token by querying the Database.
 2. Check the validity of the token.
 3. Check if the user is subscribed to the API.
 4. Check if the token has necessary scopes to access the resource.
 5. Generate JWT using details derived from the token.

 In this design, the server to which GW calls is the same entity which
 manages tokens. So calling this entity as Key Manager suits in this
 scenario.

 After decoupling the Authorization server, the server to which GW calls,
 will not be the same entity that manages tokens. To make this distinction
 clear, a new profile will be introduced (which we'll refer to as Key
 Validator for now). Basically GW calls to Key Validator which performs all
 the above operations except 1st and 2nd. To complete its validation, Key
 Validator obtains token details by calling to a Key Manager (Authorization
 Server) - which can either be the one shipped with APIM or else a third
 party one.


 1st Diagram illustrates the interaction between server profiles we
 currently have and the second diagram shows the interactions after adding
 the new profile.



 ​
 Boxes in the diagram represent the profiles, not the server instances in
 a deployment. When using the inbuilt KM, a typical deployment will have
 KeyValidator and KeyManager profiles in the same JVM. All the server roles
 except Gateway, will have to know about Key Manager.

 These are the changes happening in configuration files;

 1. Key-Manager section in api-manager.xml will be changed as Key-Validator
 a. TokenEndPointName and RevokeAPIURL elements will be removed from
 Key-Validator section.
 b. Two new elements ApplicationTokenScope 
 KeyValidationHandlerClassName will be introduced.

 2. A new config named key-manager.xml will be introduced.
 Purpose of having this file is to provide a single location to keep all
 the settings, configs used by a KeyManager implementation.

 This is the structure of the key-manager.xml to be shipped with APIM by
 default.

 KeyManager class=org.wso2.carbon.apimgt.keymgt.AMDefaultKeyManagerImpl
 xmlns=http://wso2.org/projects/apimgt/key-manager.xml;
 Configuration
   AuthorizationServerURLhttps://localhost:9443/services/
 /AuthorizationServerURL
   TokenURLhttps://localhost:8243/token/TokenURL
   RevokeURLhttps://localhost:8243/revoke/RevokeURL
 /Configuration
 /KeyManager

 Since generating/revoking tokens are done by the class implementing
 KeyManager interface, those urls have been moved in to this config.

 Contents inside the Configuration block can change based on the
 implementing class. For example, when plugging in an third party Key
 Manager (Authorization Server), introspect endpoint might have to be
 provided.

 Please share your thoughts.

 --
 *Amila De Silva*

 WSO2 Inc.
 mobile :(+94) 775119302


 ___
 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




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Fwd: [APIM] Decoupling Authorization Server - Additional features needed from IS to completely decouple Authorization Server from APIManager.

[Amila De Silva]

Hi All,

While carrying out development, we came through several gaps that prevents
IS to be seamlessly used as an Authorization Server.
1. Ability for subscribers to invoke OAuthAdminService.
Subscribers log into the store create Applications , Subscribe to API and
then Register the applications with Authorization Server (at this point an
OAuth app is created in IS) to get Consumer Key/Secret pair. Until now API
Manager has been registering Apps by directly writing to DB
(IDN_OAUTH_CONSUMER_APPS , a table that should be written only through IS).
But in future we’ll be creating the OAuthApp by calling OAuthAdminService.
The problem  is, this being an admin service, only the users with admin
privileges can invoke this. But subscribers log into the store are only
required to have subscribe permission. Two options are available to solve
this ;

a. Reducing permission of the Admin Service.

b. Changing the Service in such a way that an authenticated admin user
can create an OAuth App behalf of another user.

This issue is discussed in the thread [APIM] Decoupling Authorization
Server - Authenticating with Identity Server from API Store

2. Need an additional grant handler for creating Application Access Tokens.
Plans is to create Application Access Token using an extended grant type.
For API Manager to work seamlessly with IS (without any feature
installation), this new grant type needs to be shipped with IS.

3. Exposing a service to register scopes  resources
At the time of creating an API, creators have the ability to indicate which
scopes are needed for accessing a given resource. These scopes are referred
when issuing an access token. Currently we are saving the scopes in
IDN_OAUTH2_SCOPE table and resource-scope mapping in
IDN_OAUTH2_RESOURCE_SCOPE table through a direct DB write. Since writing to
these tables is the responsibility of the Authorization Server, a service
should be provided for creating scopes  resources.


4. Checking whether the user is allowed to have a requested scope when
issuing tokens
API Manager has extended the default behaviour of issuing tokens. When a
token is requested for a scope, IS issues the token without performing
additional checks. In API Manager, a scope can be associated with a role,
so that only the users having the particular role will be given access
tokens generated for that scope. This implementation should also be shipped
with IS.

-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: [APIM] Decoupling Authorization Server - Additional features needed from IS to completely decouple Authorization Server from APIManager.

[Amila De Silva]

Hi Colin,

On Wed, Mar 11, 2015 at 12:09 AM, Colin Roy-Ehri col...@wso2.com wrote:

 +1 for option 1.a. Because this admin feature should be accessible by the
 Subscriber role.  Preventing that role from accessing the admin services
 would complicate the use of the service.

 Also, for point 3. Exposing a service to register scopes  resources,
 the new admin service access should be accessible by the Creator and/or
 Publisher roles.

Yes, the new service should be accessible by the Creator. Thanks for
bringing this up.


 Thanks,
 Colin Roy-Ehri
 Software Engineer
 *WSO2, Inc. : wso2.com http://wso2.com/*
 *Mobile*  : 812-219-6517

 On Tue, Mar 10, 2015 at 1:39 PM, Amila De Silva ami...@wso2.com wrote:

 Hi All,

 While carrying out development, we came through several gaps that
 prevents IS to be seamlessly used as an Authorization Server.
 1. Ability for subscribers to invoke OAuthAdminService.
 Subscribers log into the store create Applications , Subscribe to API and
 then Register the applications with Authorization Server (at this point an
 OAuth app is created in IS) to get Consumer Key/Secret pair. Until now API
 Manager has been registering Apps by directly writing to DB
 (IDN_OAUTH_CONSUMER_APPS , a table that should be written only through IS).
 But in future we’ll be creating the OAuthApp by calling OAuthAdminService.
 The problem  is, this being an admin service, only the users with admin
 privileges can invoke this. But subscribers log into the store are only
 required to have subscribe permission. Two options are available to solve
 this ;

 a. Reducing permission of the Admin Service.

 b. Changing the Service in such a way that an authenticated admin
 user can create an OAuth App behalf of another user.

 This issue is discussed in the thread [APIM] Decoupling Authorization
 Server - Authenticating with Identity Server from API Store

 2. Need an additional grant handler for creating Application Access
 Tokens.
 Plans is to create Application Access Token using an extended grant type.
 For API Manager to work seamlessly with IS (without any feature
 installation), this new grant type needs to be shipped with IS.

 3. Exposing a service to register scopes  resources
 At the time of creating an API, creators have the ability to indicate
 which scopes are needed for accessing a given resource. These scopes are
 referred when issuing an access token. Currently we are saving the scopes
 in IDN_OAUTH2_SCOPE table and resource-scope mapping in
 IDN_OAUTH2_RESOURCE_SCOPE table through a direct DB write. Since writing to
 these tables is the responsibility of the Authorization Server, a service
 should be provided for creating scopes  resources.


 4. Checking whether the user is allowed to have a requested scope when
 issuing tokens
 API Manager has extended the default behaviour of issuing tokens. When a
 token is requested for a scope, IS issues the token without performing
 additional checks. In API Manager, a scope can be associated with a role,
 so that only the users having the particular role will be given access
 tokens generated for that scope. This implementation should also be shipped
 with IS.

 --
 *Amila De Silva*

 WSO2 Inc.
 mobile :(+94) 775119302



 ___
 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




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Decoupling Authorization Server - Configuring Application Token Generation

[Amila De Silva]

Hi Nuwan,
Yes token is generated through a method provided through the interface.
Until now we have been calling that method and returning the token with the
output. Will change the behaviour such that if the token response is null,
the token details will be omitted from the output (rather than sending null
for token details).

On Saturday, March 7, 2015, Nuwan Dias nuw...@wso2.com wrote:



 On Fri, Mar 6, 2015 at 5:58 PM, Amila De Silva ami...@wso2.com wrote:

 Hi,

 Currently in API Store when a user clicks on Generate button after
 subscribing to an API, following two operations happen in a single call,

 a. Getting a Consumer key and a secret for the application.
 b. Generating an Access Token.

 However when integrating with external Authorization Servers, there can
 be scenarios where the Authorization Server doesn’t allow generating
 Application Tokens. As there won’t be  an access token to be shown in the
 UI in such cases, an option should be given to configure creating the
 Access Token.

 Two options can be provided to control this behaviour;

 1. Creating client details and Access Token using two separate calls

 When the user clicks on Generate button, only the Consumer ID and Secret
 will be generated. Then the user would have to click on another button to
 get the Access Token. If the user doesn’t need the Access Token they can
 simply remove the second button from the UI.

 2. Provide a configuration to control Application Token Creation

 When configuring the Key Manager, users can specify whether they want to
 create an Application Token. When it’s enabled a token will be generated as
 the Consumer Key/Secret is created, and when it’s disabled Tokens won’t be
 created or displayed in the UI.

 Planning to go with option 2, since it involves less changes. Please
 share your thoughts on this approach.

 Does the access token generation at this point happen through a particular
 interface function? If so we can generate it always. If someone doesn't
 want it to be generated, they could just override that function in the
 interface and return nothing (so that field in the UI would be blank). This
 way, we can avoid introducing new configs.

 --
 *Amila De Silva*

 WSO2 Inc.
 mobile :(+94) 775119302




 --
 Nuwan Dias

 Associate Tech Lead - 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] Improve ESB OAuth Mediator to automatically renew token

[Amila De Silva]

Hi Madusanka,

I think it's better to provide an option to store an Access Token Obtained
from an Authorization Server.
From what I understood, in this scenario, the API acts as a client and the
token generated or provided is only another form of credential used to
access the backend. If this is the case, is it correct to put this under
the OAuth Mediator? The OAuth Mediator seems to validating the Token before
sending it to the backend, but here what we need is a way of embedding a
token.

On Thu, Feb 12, 2015 at 11:25 AM, Madusanka Premaratne madusan...@wso2.com
wrote:

 Hi,
 We need to add a property to the messageContext to store the access token.
 Planning to use the property name as *oauth.accessToken*.
 The OAuth Mediator configuration changes are as below.

 Current OAuth configurations for the token verification,
 oauthService

 remoteServiceUrl=https://10.100.5.179:9444/services/;
 username=user
 password=user/

 ​The new configuration for both token generation and validation​. Newly
 added ones are bolded to identify easily.
 oauthService

 *mode=tokenGenerate*

 remoteServiceUrl=https://10.100.5.179:9444/services/;
 username=user
 password=user

 *tokenServer /consumerKey /consumerSecret /*

 /oauthService

 ​Thanks,​


 On Thu, Feb 12, 2015 at 10:23 AM, Nuwan Dias nuw...@wso2.com wrote:

 Hi Madusanka,

 Shall we come up with the OAuth mediator configuration changes
 (additions) we'll be coming up with to support this feature?

 Thanks,
 NuwanD.

 On Wed, Feb 11, 2015 at 4:44 PM, Madusanka Premaratne 
 madusan...@wso2.com wrote:

 Hi All,
 In API Manager, we only support secure endpoints through basic auth. To
 improve it to use OAuth, we are going to use ESB OAuth Mediator. But
 currently the above mediator only validates the keys and the consumer.

 Improvement :

- Feed client key, secret and *token endpoint* to the mediator from
the UI.
- Generate a token for the consumer and stores it to use with API
Manager (or any other product)
- Store the lifetime / remaining time of the token
- If token expires, generate a token automatically and store it for
future use

 Please see the attachment below for graphical representation[1]

 [1] -
 https://drive.google.com/a/wso2.com/file/d/0B6h6rqrZ11fFQWZ5UkJXZ1JZX2c/view?usp=sharing

 Your feedback and suggestions are welcome.
 ​Thanks,​

 --
 *Madusanka Premaratne* | Associate Software Engineer
 WSO2, Inc | lean. enterprise. middleware.
 #20, Palm Grove, Colombo 03, Sri Lanka
 Mobile: +94 71 835 70 73| Work: +94 112 145 345
 Email: madusan...@wso2.com | Web: www.wso2.com

 [image: Facebook] https://www.facebook.com/rmmpremaratne [image:
 Twitter] https://twitter.com/rmmpremaratne [image: Google Plus]
 https://plus.google.com/u/0/+MadusankaPremaratnemaduz/about/p/pub [image:
 Linkedin] http://lk.linkedin.com/in/madusanka/ [image: Instagram]
 http://instagram.com/madusankapremaratne [image: Skype]
 http://@rmmpremaratne




 --
 Nuwan Dias

 Associate Tech Lead - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729




 --
 *Madusanka Premaratne* | Associate Software Engineer
 WSO2, Inc | lean. enterprise. middleware.
 #20, Palm Grove, Colombo 03, Sri Lanka
 Mobile: +94 71 835 70 73| Work: +94 112 145 345
 Email: madusan...@wso2.com | Web: www.wso2.com

 [image: Facebook] https://www.facebook.com/rmmpremaratne [image:
 Twitter] https://twitter.com/rmmpremaratne [image: Google Plus]
 https://plus.google.com/u/0/+MadusankaPremaratnemaduz/about/p/pub [image:
 Linkedin] http://lk.linkedin.com/in/madusanka/ [image: Instagram]
 http://instagram.com/madusankapremaratne [image: Skype]
 http://@rmmpremaratne


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




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store

[Amila De Silva]

Yes, there are some SP 1 fixes, on which some KM features depend on.

On Mon, Feb 23, 2015 at 4:15 PM, Samisa Abeysinghe sam...@wso2.com wrote:



 On Mon, Feb 23, 2015 at 4:07 PM, Amila De Silva ami...@wso2.com wrote:

 Hi Samisa,

 Should be compatible with IS 5.0.


 ​With the SP I suppose?
 ​


 On Mon, Feb 23, 2015 at 3:38 PM, Samisa Abeysinghe sam...@wso2.com
 wrote:

 Which WSO2 IS server version will API-M 1.9 support?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Delivery

 WSO2 Inc.
 http://wso2.com


 On Mon, Feb 16, 2015 at 4:23 PM, Amila De Silva ami...@wso2.com wrote:

 Hi All,

 With API Manager 1.9.0, capability will be provided to plug in an
 External Authorization server. With this change, Authorization Server will
 be the only entity creating OAuth clients, and issuing access tokens.

 In order to seamlessly support some of the existing APIM features,
 certain changes should be done on the Store:

 1. Generating Application Token using an Extended Grant Type

 As of now, Store UI allows to specify a validity period when Generating
 an Application Access Token. In the previous releases this was possible,
 since KeyManager component could directly access the tables where tokens
 are kept. So after generating a token through UI, Store could update the
 newly generated token giving a preferred validity period. After decoupling
 Authorization Server, Store would no longer be able to do this, through a
 direct DB call. Solution to overcome this problem would be to use an
 entirely new Grant Type to Generate the Application Access Token. The new
 Grant type would accept validity period as a new parameter and use it when
  generating the Application Access Token.


 2. Using a Separate Table to store Application Access Tokens

 Currently, when rendering the UI, Store gets the Access Token by
 querying the Database directly. After decoupling AS, if we are to Display
 the Application Token, we would have to Keep the token in a separate Table.
 In this scenario, Store would act as another client App created on the AS
 and the Table for storing tokens will be used as a temporary storage. This
 means that only the most recent Access Token will be kept in, and the table
 won’t be used to obtain token meta data (such as validity period , Consumer
 Key) during an API invocation.


 3. Generate the token only using /token, /authorize endpoints

 First time when creating an Application Access Token, Store calls
 APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token.
 This method, simply creates a token and write it down to
 IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when
 moving forward, we would have to obtain the the Application Access Token
 only using standard OAuth endpoints.


 4. Determining the type of a token using a scope

 In API Manager, the type of the token (whether it is Application or
 Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token.
 Token Type is used when validating API Invocations (When defining a
 resource, the type of token required to access it can be specified, and a
 resource can be only accessed with a token of the specified type). Since
 the type of the token is tightly coupled with our implementation of Tokens,
 to make it usable across different Authorization Servers, Token type will
 be mapped to a scope. So Application Tokens will have a scope like
 am:application_token (we can make the scope name configurable). When a
 token is generated through the Store UI, Store will request the token with
 this scope.


 These are the major changes required for the Store to function
 properly. Would appreciate your feedback on these.

 --
 *Amila De Silva*

 WSO2 Inc.
 mobile :(+94) 775119302


 ___
 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




 --
 *Amila De Silva*

 WSO2 Inc.
 mobile :(+94) 775119302


 ___
 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




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store

[Amila De Silva]

Hi Samisa,

Should be compatible with IS 5.0.

On Mon, Feb 23, 2015 at 3:38 PM, Samisa Abeysinghe sam...@wso2.com wrote:

 Which WSO2 IS server version will API-M 1.9 support?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Delivery

 WSO2 Inc.
 http://wso2.com


 On Mon, Feb 16, 2015 at 4:23 PM, Amila De Silva ami...@wso2.com wrote:

 Hi All,

 With API Manager 1.9.0, capability will be provided to plug in an
 External Authorization server. With this change, Authorization Server will
 be the only entity creating OAuth clients, and issuing access tokens.

 In order to seamlessly support some of the existing APIM features,
 certain changes should be done on the Store:

 1. Generating Application Token using an Extended Grant Type

 As of now, Store UI allows to specify a validity period when Generating
 an Application Access Token. In the previous releases this was possible,
 since KeyManager component could directly access the tables where tokens
 are kept. So after generating a token through UI, Store could update the
 newly generated token giving a preferred validity period. After decoupling
 Authorization Server, Store would no longer be able to do this, through a
 direct DB call. Solution to overcome this problem would be to use an
 entirely new Grant Type to Generate the Application Access Token. The new
 Grant type would accept validity period as a new parameter and use it when
  generating the Application Access Token.


 2. Using a Separate Table to store Application Access Tokens

 Currently, when rendering the UI, Store gets the Access Token by querying
 the Database directly. After decoupling AS, if we are to Display the
 Application Token, we would have to Keep the token in a separate Table. In
 this scenario, Store would act as another client App created on the AS and
 the Table for storing tokens will be used as a temporary storage. This
 means that only the most recent Access Token will be kept in, and the table
 won’t be used to obtain token meta data (such as validity period , Consumer
 Key) during an API invocation.


 3. Generate the token only using /token, /authorize endpoints

 First time when creating an Application Access Token, Store calls
 APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token.
 This method, simply creates a token and write it down to
 IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when
 moving forward, we would have to obtain the the Application Access Token
 only using standard OAuth endpoints.


 4. Determining the type of a token using a scope

 In API Manager, the type of the token (whether it is Application or
 Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token.
 Token Type is used when validating API Invocations (When defining a
 resource, the type of token required to access it can be specified, and a
 resource can be only accessed with a token of the specified type). Since
 the type of the token is tightly coupled with our implementation of Tokens,
 to make it usable across different Authorization Servers, Token type will
 be mapped to a scope. So Application Tokens will have a scope like
 am:application_token (we can make the scope name configurable). When a
 token is generated through the Store UI, Store will request the token with
 this scope.


 These are the major changes required for the Store to function properly.
 Would appreciate your feedback on these.

 --
 *Amila De Silva*

 WSO2 Inc.
 mobile :(+94) 775119302


 ___
 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




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store

[Amila De Silva]

Hi Colin,

Thanks for bringing this up.

Yes, we could do with an existing Grant Type. When generating an
Application Access Token we allow specifying validity period through Store
UI. It's because none of the existing Grant Types accept validity period as
a parameter, we are thinking of doing it through an extended Grant Type.
Even WSO2 Identity Server might support changing validity period , other
Authorization Servers might not allow that, as validity period is more like
a server configuration and not something that can be changed per token. If
someone doesn't need to change validity period through UI, then they can
use an existing Grant Type.

On Wed, Feb 18, 2015 at 9:07 AM, Colin Roy-Ehri col...@wso2.com wrote:

 +1 for these enhancements.

 I wonder if #1 the Extended Grant Type could cause unnecessary complexity
 for the External Authorization server?  I think #1 is a necessary feature,
 but we could make simple grant types an option.  For initial configuration
 of an External Authorization server, it may be easier to work with the
 default Oauth2 Grant Types.  Perhaps we could have a configuration point
 for the External Authorization server, i.e. useExtendedGrantTypes .  Just
 an idea.

 -Colin

 Thanks,
 Colin Roy-Ehri
 Software Engineer
 *WSO2, Inc. : wso2.com http://wso2.com/*
 *Mobile*  : 812-219-6517

 On Mon, Feb 16, 2015 at 5:53 AM, Amila De Silva ami...@wso2.com wrote:

 Hi All,

 With API Manager 1.9.0, capability will be provided to plug in an
 External Authorization server. With this change, Authorization Server will
 be the only entity creating OAuth clients, and issuing access tokens.

 In order to seamlessly support some of the existing APIM features,
 certain changes should be done on the Store:

 1. Generating Application Token using an Extended Grant Type

 As of now, Store UI allows to specify a validity period when Generating
 an Application Access Token. In the previous releases this was possible,
 since KeyManager component could directly access the tables where tokens
 are kept. So after generating a token through UI, Store could update the
 newly generated token giving a preferred validity period. After decoupling
 Authorization Server, Store would no longer be able to do this, through a
 direct DB call. Solution to overcome this problem would be to use an
 entirely new Grant Type to Generate the Application Access Token. The new
 Grant type would accept validity period as a new parameter and use it when
  generating the Application Access Token.


 2. Using a Separate Table to store Application Access Tokens

 Currently, when rendering the UI, Store gets the Access Token by querying
 the Database directly. After decoupling AS, if we are to Display the
 Application Token, we would have to Keep the token in a separate Table. In
 this scenario, Store would act as another client App created on the AS and
 the Table for storing tokens will be used as a temporary storage. This
 means that only the most recent Access Token will be kept in, and the table
 won’t be used to obtain token meta data (such as validity period , Consumer
 Key) during an API invocation.


 3. Generate the token only using /token, /authorize endpoints

 First time when creating an Application Access Token, Store calls
 APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token.
 This method, simply creates a token and write it down to
 IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when
 moving forward, we would have to obtain the the Application Access Token
 only using standard OAuth endpoints.


 4. Determining the type of a token using a scope

 In API Manager, the type of the token (whether it is Application or
 Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token.
 Token Type is used when validating API Invocations (When defining a
 resource, the type of token required to access it can be specified, and a
 resource can be only accessed with a token of the specified type). Since
 the type of the token is tightly coupled with our implementation of Tokens,
 to make it usable across different Authorization Servers, Token type will
 be mapped to a scope. So Application Tokens will have a scope like
 am:application_token (we can make the scope name configurable). When a
 token is generated through the Store UI, Store will request the token with
 this scope.


 These are the major changes required for the Store to function properly.
 Would appreciate your feedback on these.

 --
 *Amila De Silva*

 WSO2 Inc.
 mobile :(+94) 775119302


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





-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store

[Amila De Silva]

Hi All,

With API Manager 1.9.0, capability will be provided to plug in an External
Authorization server. With this change, Authorization Server will be the
only entity creating OAuth clients, and issuing access tokens.

In order to seamlessly support some of the existing APIM features, certain
changes should be done on the Store:

1. Generating Application Token using an Extended Grant Type

As of now, Store UI allows to specify a validity period when Generating an
Application Access Token. In the previous releases this was possible, since
KeyManager component could directly access the tables where tokens are
kept. So after generating a token through UI, Store could update the newly
generated token giving a preferred validity period. After decoupling
Authorization Server, Store would no longer be able to do this, through a
direct DB call. Solution to overcome this problem would be to use an
entirely new Grant Type to Generate the Application Access Token. The new
Grant type would accept validity period as a new parameter and use it when
 generating the Application Access Token.


2. Using a Separate Table to store Application Access Tokens

Currently, when rendering the UI, Store gets the Access Token by querying
the Database directly. After decoupling AS, if we are to Display the
Application Token, we would have to Keep the token in a separate Table. In
this scenario, Store would act as another client App created on the AS and
the Table for storing tokens will be used as a temporary storage. This
means that only the most recent Access Token will be kept in, and the table
won’t be used to obtain token meta data (such as validity period , Consumer
Key) during an API invocation.


3. Generate the token only using /token, /authorize endpoints

First time when creating an Application Access Token, Store calls
APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token.
This method, simply creates a token and write it down to
IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when
moving forward, we would have to obtain the the Application Access Token
only using standard OAuth endpoints.


4. Determining the type of a token using a scope

In API Manager, the type of the token (whether it is Application or
Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token.
Token Type is used when validating API Invocations (When defining a
resource, the type of token required to access it can be specified, and a
resource can be only accessed with a token of the specified type). Since
the type of the token is tightly coupled with our implementation of Tokens,
to make it usable across different Authorization Servers, Token type will
be mapped to a scope. So Application Tokens will have a scope like
am:application_token (we can make the scope name configurable). When a
token is generated through the Store UI, Store will request the token with
this scope.


These are the major changes required for the Store to function properly.
Would appreciate your feedback on these.

-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Meeting Note : Implement a Pluggable Version Strategy feature in APIManager

[Amila De Silva]

 on this.


 Thanks

 *Dinesh J. Weerakkody*
 Software Engineer
 WSO2 Inc.
 lean | enterprise | middleware
 M : +94 727 361788 | E : dine...@wso2.com | W : www.wso2.com



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




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Login Interceptor Interface of API Manager

[Amila De Silva]

Hi Lakshman,
Can you explain a bit about when this is invoked, and for what tasks this
is going to be used? If we are trying to provide an extension point to run
a custom code after a user logs in, I think then we should try to use
WorkflowExecutor
https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/components/apimgt/org.wso2.carbon.apimgt.impl/1.2.3/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java
 first.

On Tue, Jan 13, 2015 at 1:22 PM, Lakshman Udayakantha lakshm...@wso2.com
wrote:

 Hi All,

 I am working on [1]. In that I have to implement the application and
 subscription sharing capability based on the organisation of the login
 user. I have to create a Login interceptor interface to determine the
 organisation of login user. We have to extract the organisation identifier
 from login response using login interceptor. below is a proposed login
 interceptor interface.

 public interface LoginInterceptor {

 public String getOrganization(String response);

 }

 When using WSO2 identity server we can add organisation as an attribute to
 SAML response and we can extract it in the implementation of the
 interceptor in API Manager side. Appreciate your thought on this.

 [1]https://redmine.wso2.com/issues/2917

 --
 Lakshman Udayakantha
 WSO2 Inc. www.wso2.com
 lean.enterprise.middleware
 Mobile: *0711241005*




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Amila De Silva]

Doing this as a mediation extension would make it more re-usable IMO.

On Tue, Jan 13, 2015 at 3:10 PM, Ruwan Yatawara ruw...@wso2.com wrote:

 On Tue, Jan 13, 2015 at 2:54 PM, Nuwan Dias nuw...@wso2.com wrote:

 Ok, so I think we need to have a property which can be enabled/disabled.
 This property decides whether the OPTIONS request should be forwarded to
 the back-end or not. Whenever the Max-Forwards header is not present in the
 request, this property gets prominence. When present, Max-Forwards get
 prominence.

 And I think this needs to be done at the Synapse level rather than
 handling at an API Manager handler level.


 +1 including this in the Synapse level makes good sense.


 Thanks,
 NuwanD.

 On Tue, Jan 13, 2015 at 2:38 PM, Joseph Fonseka jos...@wso2.com wrote:

 Hi

 @Amila
 For options call we can respond per API basis, based on the HTTP methods
 defined in the API. And those methods can be sent via Allow header. Also
 the same methods can be sent in CORS headers too.

 @Nuwan
 Yes the Max-Forwards is the problem and according to the spec it is to
 be honored by proxy servers. But API Gateway is more of an API facade which
 does masking so shouldn't it be hiding internal implementation details from
 outside ? (Ex the implemented methods in the back-end server). If so then
 we should not send the OPTIONS call to the back-end.

 @Ruwan
 IMO we should return the OPTIONS call from Gateway also in ESB if the
 Max-Forwards is set to 0 it will return before hitting the in sequence.

 Thanks
 Jo





 On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara ruw...@wso2.com wrote:

 On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias nuw...@wso2.com wrote:



 On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka jos...@wso2.com
 wrote:


 Hi

 Currently in API Manager we send the OPTIONS call to the back-end
 server to respond. But if the API does not expose all the HTTP methods in
 back-end, OPTIONS call response will be invalid.

 1. Should we respond to the OPTIONS call from the gateway with the
 Allow header including only the HTTP methods exposed by the API.

 2. If we are doing above should we give an option to the user to
 override in case if he want to send it to back-end.


 Whether the OPTIONS call goes to the back-end or not is dominated by
 the Max-Forwards header. According to the spec [1], it seems like the
 request should be forwarded when the Max-Forwards header is not present.


 First of all +1, but since we are implicitly enabling OPTIONS for the
 API, and we are including a property that can be configured by the users if
 they to enable sending options call to the back end (Which by the way needs
 to be a configuration that can be done on a per API basis, i believe),
 should we not introduce the Max-Forward : 0 header when intercepting the
 options call at the gateway? and sending it back. Or should just the drop
 the message and respond back, with the allow origin headers and what not?


 3. Is there a valid requirement to show the OPTIONS method in API
 Design phase, shouldn't it be enabled by default.

 +1

 +1


 [1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html


 Thanks
 Jo

 Related
 https://wso2.org/jira/browse/APIMANAGER-1704







 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara*




 --
 Nuwan Dias

 Associate Tech Lead - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729





 --

 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara*




 --
 Nuwan Dias

 Associate Tech Lead - 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




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] API Manager Authorization Server Decoupling

[Amila De Silva]

, 2014 at 11:14 PM, Amila De Silva ami...@wso2.com wrote:

 Hi,

 *Extension points for token validation*

 These changes are the planned changes.

 1. All the extensions will be done in Key Manager - Earlier it was
 suggested to allow GW to call directly to a different Authorization Server
 and use the result returned by that to validate the subscription. After
 some discussions it seemed that keeping GW intact and changing the validate
 operation in KM would be much simple. GW will always receive a uniform
 response irrespective of the Authorization Server used behind.


 2 Use validate operation in OAuth2TokenValidationService instead of
 using APIKeyValidationService. - Behaviour of the validate operation of can
 be changed by providing a custom handler. We can put the current validate
 method in the default implementation,without any changes.
 One expected benefit of using OAuth2TokenValidationService is,
 eliminating the need to install Key Manager features on IS, when using IS
 as an Authorization Server. But the suggested change alone would not make
 it possible, since GW calls getAllURITemplates operation, which is only
 available in APIKeyValidationService, to get the Authentication Scheme of a
 resource.




 --
 Roshan Wijesena.
 Senior Software Engineer-WSO2 Inc.
 Mobile: *+94752126789*
 Email: ros...@wso2.com
 *WSO2, Inc. :** wso2.com http://wso2.com/*
 lean.enterprise.middleware.




 --
 Nuwan Dias

 Associate Tech Lead - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729




 --

 *Sanjeewa Malalgoda*
 WSO2 Inc.
 Mobile : +94713068779

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





-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] API Manager Authorization Server Decoupling

[Amila De Silva]

Hi Sanjeewa


On Thu, Sep 4, 2014 at 10:29 AM, Sanjeewa Malalgoda sanje...@wso2.com
wrote:

 Hi Amila,
 This is very valid use case and thanks for bring this up. Please find
 comments inline.


 On Mon, Sep 1, 2014 at 9:30 AM, Amila De Silva ami...@wso2.com wrote:

 Hi,

 Currently a development is going onto decouple Authorization Server from
 API Manager.

 In the existing design, creating Applications, generating  validating
 Tokens are done through non-standard interfaces and these operations are
 tightly coupled with the Key Manager ,which is the default Authorization
 Server in a typical API Manager Deployment.

 The ongoing effort is to identify such tightly coupled areas and provide
 extension points for them, allowing an external Authorization Server to
 issue and validate Access Tokens.

 There are 2 major Tasks involved in this.

 1. Changing the way Applications are registered on the Store – An
 Application created in Store can have two types of Keys PRODUCTION and
 SANDBOX. When a user clicks on the Generate button,
a. An Oauth app is created with the given key type
b. An Application Access token is Generated

 When creating the OAuth app entries get written to IDN_CONSUMER_APPS and
 AM_APPLICATION_KEY_MAPPING tables.
 Access Token is generated by creating an entry in IDN_OAUTH2_ACCESS_TOKEN
 table.


 By providing the capability to plug-in a custom implementation for an
 Oauth app, users will be able to store/create Oauth Apps in their own
 Authorization Server, eliminating the need to keep Access Tokens in AM
 Tables.

 In this case do we still need to maintain apps inside API Manager.
 Applications, subscriptions and tokens are tightly coupled and inter
 related. So how do we plan decouple these? First we might need to identify
 the roles and tasks of authorization server. Following are required IMO
 Create, update and maintains applications.

The Application created in the Store (let's refer to this as the AM
Application) , doesn't get changed by these. Subscriptions are maintained
against an AM Application, therefore, we don't need to change the way
subscriptions are stored.
The OAuth Application being discussed here, is an abstract representation
of an OAuth 2.0 client. It is for an OAuth Application we obtain an
Application Access Token for. When you generate a key under the AM
Application (say a Production key),
a. First an OAuth Application is created (Consumer Key and Consumer Secret
belongs to that particular OAuth App)
b. And then a Token is generated.

Instead of creating the OAuth App in the APIM, users can choose to create
them in an external Authorization Server. We can use the Consumer Key
issued by the  Authorization Server to keep the mapping between the AM
Application and the OAuth Application. When implementing OAuthApplication
interface, developers have to determine where they are going to keep the
App, and how they are going to retrieve it. It should be possible to
retrieve an OAuthApplication by the consumer key.

Maintains subscriptions.
 Generate tokens and manage them.

In the case of an External Authorization server, generating/managing tokens
will not be handled by APIM.

 Handle token validation, verification.

Yes, the capability should be given to plug in a custom handler to do the
Token Validation.


 So from API Manager side we can provide interface to access authorization
 server. Are we planning to create interface and decouple current
 implementation as authorization server? Or are we going to consider
 external common authorization server pluggability ?

We are going to do both. We have to decouple the current implementation and
also we have to make sure that the interfaces we provide contain all the
necessary methods needed to plug in an external Authorization Server.

Thought it would be better to explain certain terms clearly, hence the long
description :)


 Thanks,
 sanjeewa.


 2. Changes on Token Validation
 During an API Invocation, GW calls the KM to get the Key Validated.
 During the validation
a. Token is checked for it's Validity- whether it is Active or not
b. Subscription gets validated - If the API being invoked is
 subscribed by the Application that obtained the token.
c. A JWT is generated using the default claims and the custom claims
 user has provided.

 As of now, all of these operations are performed by
 APIKeyValidationService running in KM. There can be scenarios where user
 needs to delegate , token validation to a different Authorization Server.
 To use in such scenarios, a service needs to be provided in KM, which only
 checks the state of the subscription.

 APIAuthenticationHandler which is responsible for calling KM and getting
 the token validated needs to be modified to call an external
 service/endpoint and fetch details(such as consumer key) about the client
 that obtained the token.


 Details about the design and the tasks will be provided in the mails to
 follow.
 --
 *Amila De Silva*

  WSO2 Inc

Re: [Architecture] API Manager - Self Signup for tenant's API Store

[Amila De Silva]

Hi Chamila,

I think you have to start the TenantFlow and set the ID for the tenant
correctly before fetching the configuration. In the method
jsFunction_resumeWorkflow, this is done by calling
PrivilegedCarbonContext.startTenantFlow();

PrivilegedCarbonContext.getThreadLocalCarbonContext().setTenantDomain(tenantDomain,
true);



On Wed, Sep 3, 2014 at 10:47 PM, Chamila Adhikarinayake chami...@wso2.com
wrote:

 Actually the tasks are created with that executor for other tenants as
 well. but not inside the correct tenant domain in the BPS. They are created
 in carbon.super tenant domain and the related task can be viewed in
 workflow-admin ui only by login as super user.

 following is the reason I think that causes this.

 In the method jsFunction_addUser() in APIStoreHostObject following code is
 there to create the workflow

 WorkflowExecutor userSignUpWFExecutor =
 WorkflowExecutorFactory.getInstance()

 .getWorkflowExecutor(WorkflowConstants.WF_TYPE_AM_USER_SIGNUP);

 This WorkflowExecutor is created using carbon.super user configuration
 information in the registry. In the 'getWorkflowConfigurations()' method in
 WorkflowExecutorFactory class
 PrivilegedCarbonContext.getThreadLocalCarbonContext().getTenantDomain(); is
 used to get the domain name. (aslo tenant id). So even though there is a
 different tenant domain, these values do not change. So superuser conf is
 used and  the request is sent to the carbon.super tenant in BPS. not to the
 tenant's one. So I'm working on passing the correct domain info to this


 On Wed, Sep 3, 2014 at 9:06 PM, Nuwan Dias nuw...@wso2.com wrote:

 On Wed, Sep 3, 2014 at 9:02 PM, Chamila Adhikarinayake chami...@wso2.com
  wrote:

 Hi all,
 I'm creating user self signup feature for tenant store in API Manager.
 Current api manager provides only self signup facility for carbon.super
 store. To add tenant users, tenant admin has to manually add it through the
 carbon console.

 Following parts will be implemented

 *UI changes* (see attached images)

 1. enable the sign-up button for tenant user store
 2. add the domain name extension for the user name field in the user
 registration form. (this is appended to the user name)

 *User roles for tenants *

 Tenant signup configuration will be moved to the registry location
 '/_system/governance/repository/identity/sign-up-config'. This part is
 already implemented by Shariq for a IS component(See discussion in the
 thread Provide support for self signup for tenants' APIStores for more
 info on the configuration). But this resource needed to be created
 manually. So as a part of the implementation, This resource will be added
 with default values when creating a tenant. Default value will be

 SelfSignUp
SignUpDomainPRIMARY/SignUpDomain
SignUpRole
   RoleNamesubscriber/RoleName
   IsExternalRolefalse/IsExternalRole
/SignUpRole
 /SelfSignUp


 *Modification to current work-flow for tenant sign-up. *

 The current implemented method does not work when
 UserSignUpWSWorkflowExecutor is used in the work-flow. this can be only
 used with tenants signups for superuser. Existing code uses configuration
 in the carbon super user's registry entry
 '/_system/governance/apimgt/applicationdata/workflow-extensions.xml' for
 tenants as well ( see jsFunction_addUser() in
 org.wso2.carbon.apimgt.hostobjects.APIStoreHostObject class. ). When
 registering a tenant user for different tenant, configuration in the
 tenant's workflow-extensions.xml needed to be used.

 I have implemented basic functionality[1] as requested by AmilaM (Users
 can signup for tenant stores. But Tenant admin has to manually add the
 registry entry with user roles to the given location. If this entry is not
 there, a default 'identity' user role is assigned to the user.  Only
 UserSignUpSimpleWorkflowExecutor for the workflow can be used with this. If
 UserSignUpWSWorkflowExecutor is used to connect to the BPS, the tenant
 approval tasks are not created properly)


 Do we know the reason for the tasks of the BPS not being created when the
 UserSignUpWSWorkflowExecutor is used? We will need to dig into that IMO.


 [1] https://wso2.org/jira/browse/APIMANAGER-2785

 Comments are highly appreciated
 Thanks,
 Chamila.

 --
 Regards,
 Chamila Adhikarinayake
 Software Engineer
 WSO2, Inc.
 Mobile - +94712346437
 Email  - chami...@wso2.com




 --
 Nuwan Dias

 Associate Tech Lead - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729




 --
 Regards,
 Chamila Adhikarinayake
 Software Engineer
 WSO2, Inc.
 Mobile - +94712346437
 Email  - chami...@wso2.com




-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] API Manager Authorization Server Decoupling

[Amila De Silva]

Hi,

Currently a development is going onto decouple Authorization Server from
API Manager.

In the existing design, creating Applications, generating  validating
Tokens are done through non-standard interfaces and these operations are
tightly coupled with the Key Manager ,which is the default Authorization
Server in a typical API Manager Deployment.

The ongoing effort is to identify such tightly coupled areas and provide
extension points for them, allowing an external Authorization Server to
issue and validate Access Tokens.

There are 2 major Tasks involved in this.

1. Changing the way Applications are registered on the Store – An
Application created in Store can have two types of Keys PRODUCTION and
SANDBOX. When a user clicks on the Generate button,
   a. An Oauth app is created with the given key type
   b. An Application Access token is Generated

When creating the OAuth app entries get written to IDN_CONSUMER_APPS and
AM_APPLICATION_KEY_MAPPING tables.
Access Token is generated by creating an entry in IDN_OAUTH2_ACCESS_TOKEN
table.

By providing the capability to plug-in a custom implementation for an Oauth
app, users will be able to store/create Oauth Apps in their own
Authorization Server, eliminating the need to keep Access Tokens in AM
Tables.

2. Changes on Token Validation
During an API Invocation, GW calls the KM to get the Key Validated. During
the validation
   a. Token is checked for it's Validity- whether it is Active or not
   b. Subscription gets validated - If the API being invoked is subscribed
by the Application that obtained the token.
   c. A JWT is generated using the default claims and the custom claims
user has provided.

As of now, all of these operations are performed by APIKeyValidationService
running in KM. There can be scenarios where user needs to delegate , token
validation to a different Authorization Server. To use in such scenarios, a
service needs to be provided in KM, which only checks the state of the
subscription.

APIAuthenticationHandler which is responsible for calling KM and getting
the token validated needs to be modified to call an external
service/endpoint and fetch details(such as consumer key) about the client
that obtained the token.


Details about the design and the tasks will be provided in the mails to
follow.
-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Fwd: [Dev] Moving Workflow configurations to Registry

[Amila De Silva]

Moving to Architecture

Hi,

Currently the configuration for Workflow Executors are kept in the
api-manager.xml due to which all the tenants living in a APIM Deployment
have to use the same executors defined by the Super Tenant Admin. To allow
Tenants configure their own executors, Workflow Configurations will be
moved to the Registry.

Following places will be changed when accommodating this;

1. With the existing implementation, Workflow Executor Factory reads the
config and maintains  a map for different executors needed by each Workflow
Type. This factory will be changed to hold Workflows defined by each
different tenant.

2. At present, the configuration is read only at the start up.  When moving
those to the registry, users will be able to change them at any moment and
the data structure created out of the configs will have to be updated
reflecting the changes. This will be done using a Registry Handler.

3. To reduce frequent accesses of the registry resource, the data structure
created out by parsing the config will be cached. The new registry handler
which gets called upon updating the config will be responsible for
invalidating the cache.

Comments are welcome.

-- 
*Amila De Silva*

*Software Engineer*
WSO2 Inc.
mobile :(+94) 775119302




-- 
*Amila De Silva*

*Software Engineer*
WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Storing configuration for Workflow Executors in Registry

[Amila De Silva]

Hi Senaka,

If we assume a subscription being a resource, then the states it would go
through are somewhat similar to stages in a LifeCycle. When a subscription
is made a workflow will be triggered (the state will be set to Created) and
based on the configuration it will call an external service. The state of
the subscription will be changed by several different parties - the
subscription creator and several Administrators. Subscription will only
become active after the state is changed to Approved.
The main difference I see between the workflows we currently have and a
registry life cycle is the ability for several parties to do the state
changes.


On Thu, Mar 6, 2014 at 11:49 AM, Senaka Fernando sen...@wso2.com wrote:

 Hi Nuwan, Amila,

 If you for a moment think of a Store/Publisher webapp being a resource
 (just a logical assumption), is this kind of workflow similar to a registry
 lifecycle? We shouldn't be looking at the configuration model or what it
 does today, but the functional similarity.

 I'm asking these questions to understand whether we should unify the
 concept of workflow inside the platform to be based on some similar model.

 Thanks,
 Senaka.


 On Thu, Mar 6, 2014 at 11:36 AM, Nuwan Dias nuw...@wso2.com wrote:

 From what I understand, a registry lifecycle is always associated to a
 registry resource (only). But workflows are plug-points to various UI
 actions that you perform on the Store/Publisher webapps. Ex: A user
 sign-up, API Subscription, etc.

 Thanks,
 NuwanD.


 On Thu, Mar 6, 2014 at 11:28 AM, Senaka Fernando sen...@wso2.com wrote:

 Hi Amila,

 How different are these workflow configurations from a registry
 lifecycle configuration? I'm not suggesting that we reuse, but just to
 understand.

 Thanks,
 Senaka.


 On Thu, Mar 6, 2014 at 11:04 AM, Amila De Silva ami...@wso2.com wrote:

 Hi,

 Currently the configuration for Workflow Executors are kept in the
 api-manager.xml. Due to this design, there'll be a single workflow
 configuration for an entire deployment and all the tenants have to use the
 same executors.

 We are planning to move Workflow Configuration to the registry. A
 default configuration will be sent with the pack, and it'll get added to
 the registry when;
 1. The pack is first started - (Workflow configuration is created
 created in the Super Tenant's registry)
 2. A new Tenant is Created - (Workflow configuration is created created
 in the respective  Tenant's registry).

 With this, each tenant will be referring to the configuration stored in
 their own Registry space.
 To change the configuration, the Tenant Admin has to log into the admin
 console and edit the registry resource.

 --
 *Amila De Silva*

 *Software Engineer*
 WSO2 Inc.
 mobile :(+94) 775119302


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




 --


 *[image: http://wso2.com] http://wso2.com Senaka Fernando*
 Senior Technical Lead; WSO2 Inc.; http://wso2.com



 * Member; Apache Software Foundation; http://apache.org
 http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1
 408 754 7388 %2B1%20408%20754%207388; ext: 51736*;


 *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In:
 http://linkedin.com/in/senakafernando
 http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware

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




 --
 Nuwan Dias

 Senior Software Engineer - 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




 --


 *[image: http://wso2.com] http://wso2.com Senaka Fernando*
 Senior Technical Lead; WSO2 Inc.; http://wso2.com



 * Member; Apache Software Foundation; http://apache.org
 http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1
 408 754 7388 %2B1%20408%20754%207388; ext: 51736*;


 *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In:
 http://linkedin.com/in/senakafernando
 http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware

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




-- 
*Amila De Silva*

*Software Engineer*
WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Extending workflow integration in API Manager

[Amila De Silva]

Hi Senaka,

With the previous release, we can define which workflow executor should get
executed for a given operation. For example if we take Application Creation
operation, we can specify to execute either
ApplicationCreationSimpleWorkflowExecutor or
ApplicationCreationWSWorkflowExecutor when a new application is created.

A workflow executor has two methods;

execute - which can be used to send out a message to an external service
notifying the creation of an application.

complete - which is used to receive the final result of the workflow and
determine if the application can be created or not.

In the configuration we can specify which service should be invoked in the
execute method, and which service should be used for receiving the status
in complete method.

Using these two operations, an external BPS workflow can be initiated by
calling an external service, and the result of the workflow can be received
by the API Manager to complete the application creation process.


The Token Generation flow will operate in a similar fashion;

   - When a subscriber clicks the Generate button, a workflow will be
   initiated by the application registration request. Until this request is
   completed, further requests cannot be placed to register the same
   application.
   - An admin user either approves or declines the request - In the
   existing workflows ,this is done by a human task. Admin users can login to
   the Workflow-Admin, and see all the pending requests.
   - If the registration request is approved, it will complete the
   registration process by generating a consumerKey , consumerSecret pair.
   Accepting the output of the workflow and completing the actual registration
   can be done in two steps. In a distributed setup, there can be times the
   key manager nodes might not be able to create consumerKey, secret pair at
   the exact time the registration process receives the approval.


AmilaD




On Sat, Feb 8, 2014 at 2:06 PM, Senaka Fernando sen...@wso2.com wrote:

 Hi Amila,

 Can you define steps (or the extension points) of the existing workflows
 and how for example they can be interfaced with an external business
 process? And, also the possible steps that you plan to introduce for these
 new workflows?

 Thanks,
 Senaka.


 On Thu, Feb 6, 2014 at 11:40 AM, Amila De Silva ami...@wso2.com wrote:

  Hi,

 In the previous API Manager release we incorporated workflows for the
 following operations;

 1. User Signup.

 2. Application Creation.

 3. Creating subscriptions.

 As a part of the API Manager 2.0.0 release, we are planning to integrate
 workflows for other useful business operations. These are the areas we have
 identified currently;

  1. Token Generation - As of now, after creating an application,
 application owner can Generate a Production or Sandbox access token (or
 both) for an application. What actually happens at this point is the
 application getting registered as an OAuth application of either type. With
 this feature, a workflow will be executed when registering the application,
 so it'll be after an admin user confirms, the application will be able to
 obtain Production (or Sandbox) keys. Using this feature administrators can
 allow users\developers to create Sandbox keys to continue
 development\testing , but defer generating Production keys until the
 testing is done.

 2. Adding/Updating Comments - Currently users can post comments about the
 APIs and these will be displayed in the store without any moderation. With
 this feature, comments can be moderated before they are displayed.

 Appreciate your suggestions on these.

 Further we'd like to identify any additional useful operations we can
 integrate workflows for.

 --
 *Amila De Silva*

 *Software Engineer*
 WSO2 Inc.
 mobile :(+94) 775119302


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




 --


 *[image: http://wso2.com] http://wso2.com Senaka Fernando*
 Senior Technical Lead; WSO2 Inc.; http://wso2.com



 * Member; Apache Software Foundation; http://apache.org
 http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1
 408 754 7388 %2B1%20408%20754%207388; ext: 51736*;


 *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In:
 http://linkedin.com/in/senakafernando
 http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware

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




-- 
*Amila De Silva*

*Software Engineer*
WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Extending workflow integration in API Manager

[Amila De Silva]

Hi,

In the previous API Manager release we incorporated workflows for the
following operations;

1. User Signup.

2. Application Creation.

3. Creating subscriptions.

As a part of the API Manager 2.0.0 release, we are planning to integrate
workflows for other useful business operations. These are the areas we have
identified currently;

 1. Token Generation - As of now, after creating an application,
application owner can Generate a Production or Sandbox access token (or
both) for an application. What actually happens at this point is the
application getting registered as an OAuth application of either type. With
this feature, a workflow will be executed when registering the application,
so it'll be after an admin user confirms, the application will be able to
obtain Production (or Sandbox) keys. Using this feature administrators can
allow users\developers to create Sandbox keys to continue
development\testing , but defer generating Production keys until the
testing is done.

2. Adding/Updating Comments - Currently users can post comments about the
APIs and these will be displayed in the store without any moderation. With
this feature, comments can be moderated before they are displayed.

Appreciate your suggestions on these.

Further we'd like to identify any additional useful operations we can
integrate workflows for.

-- 
*Amila De Silva*

*Software Engineer*
WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture