Re: [Architecture] API History View in Publisher

[Ishara Cooray]

Hi Dushani,

Recording historical events will help for troubleshooting as well.
In that case, storing information such as
CRUD and deploy/undeploy operations on APIs along with users, requests,
responses, timestamp would be helpful.

Hope we are planning to implement this separately for API Products as well.

For how long do we plan to keep this data in the database?


Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512

WSO2, Inc. | http://wso2.com/
https://wso2.com/signature
Lean . Enterprise . Middleware


On Wed, Nov 25, 2020 at 9:03 PM Dushani Wellappili 
wrote:

> Hi Malintha,
> On Wed, Nov 25, 2020 at 11:58 AM Malintha Amarasinghe 
> wrote:
>
>> Hi,
>>
>> On Tue, Nov 24, 2020 at 9:28 AM Dushani Wellappili 
>> 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 deciding the viable feature design.
>>> API History View feature is mainly useful for API developers to go back and
>>> see what has been changed on the particular API since it was created. This
>>> will be a *read-only view *inside the Publisher Portal. Following are
>>> the main user stories for the feature.
>>>
>>>- User(I) wants to find out what has happened/what are the
>>>operations that have executed on this API. This will show a timeline view
>>>to show a series of events that happened since the creation of this API.
>>>- User(I) wants to sort the history by time and/or filter history
>>>events by their types to find the history element that the user is 
>>> looking
>>>for.
>>>
>>> As we are going to introduce the "revision support for APIs" feature
>>> along with the next release, we have *two design options *for the
>>> history view.
>>>
>>> *1. Show different history hierarchies for different revisions*
>>>
>>>
>>>
>>>
>>> In this case, when a user selects a revision (Eg: Revisions_1), all the
>>> events that happened till that revision_1 will be shown. This even includes
>>> events where prior revisions were created and restored.
>>>
>>> [image: image.png]
>>>
>>> This shows all the history up to the selected revision_3 including the
>>> reverted changes (since we have restored to a previous revision_1 in the
>>> middle). Hence, for a user who is trying to get a list of changes gone only
>>> for revision_3 of an API, they need to consciously discard such reverted
>>> changes done (Eg: PUT /apis) in the middle.
>>>
>>> *2. Show all the historical events in one hierarchy since API creation.
>>> No different views for different revisions.*
>>>
>>> [image: image.png]
>>> This includes all the events that occurred for the current working copy
>>> including both revision created, restored operations.
>>>
>>> The Publisher REST API for History View will only include one resource, *GET
>>> /apis/{apiId}/history* or *GET
>>> /apis/{apiId}/history?revision={revision_key}*  returning an API
>>> History response with all the events. This may also include query
>>> parameters to filter based on timestamp or event type.
>>>
>>> There are* two options* for backend implementation for this feature to
>>> capture and persist each and every API event.
>>>
>>> *1. REST API Layer Interceptor.*
>>> This will make sure all the events are captured as they all will be done
>>> through REST APIs. However, this will tightly couple the implementation
>>> with CXF and the event details which can be captured during this stage will
>>> be more generic. (This might fail to capture depending API update events
>>> when a default version of an API is changed)
>>>
>>> *2. In Implementation Layer inside a common component where events are
>>> fired*
>>> There will be no direct coupling with the REST APIs and we could be able
>>> to capture more granular level events. This could be done in the same
>>> component logic where now events are fired.
>>>
>>
>> For the backend implementation I think we can also go for a combined
>> approach of the above two.
>>
>> Implementing the 1st one is relatively easy and we can capture about 95%
>> of the cases from that. The rest of the 5% includes cases where updating a
>> certain API causes updating another one or more APIs internally. Eg: like
>> Dushani mentioned the default version case, a

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

[Ishara Cooray]

Tested the following flow for the tenant and super tenant users.

- Key Cloak Integration

No blockers are identified. +1 to proceed with the release.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512

WSO2, Inc. | http://wso2.com/
https://wso2.com/signature
Lean . Enterprise . Middleware


On Sun, Aug 9, 2020 at 1:23 AM Rukshan Premathunga  wrote:

> Tested Followings:
>
>- Verified APIM Distributed deployment with HA
>- Tested Analytics worker/dashboard HA deployment
>- Tested APIs access and throttling with apiKey
>- Tested Analytics with all the API types
>- Tested Analytics dashboard manage
>
>  [+] Stable - go ahead and release
>
> On Sat, 8 Aug 2020 at 22:59, Tharindu Dharmarathna 
> wrote:
>
>> Tested the following flow for the tenant and super tenant users.
>>
>> - Okta Integration
>>
>> No issues found. +1 to proceed with the release.
>>
>>
>> On Sat, Aug 8, 2020 at 6:36 PM Mushthaq Rumy  wrote:
>>
>>> Tested the following flows for super tenant and tenant users.
>>> - Basic flow of API creation, subscription and invocation
>>> - Soap API with pass through
>>> - Soap to Rest feature
>>>
>>> No issues found. +1 to proceed with the release.
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>> On Sat, Aug 8, 2020 at 5:53 PM Amila De Silva  wrote:
>>>
>>>> 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>
>>>> ___
>>>> Dev mailing list
>>>> d...@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>
>>>
>>> --
>>> Mushthaq Rumy
>>> *Associate Technical Lead*
>>> Mobile : +94 (0) 779 492140
>>> Email : musht...@wso2.com
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middleware.
>>>
>>> <http://wso2.com/signature>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>>
>> *Tharindu Dharmarathna*Technical Lead
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091*
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] Subscription Validation

[Ishara Cooray]

: string
  description: Name of the API
version:
  type: string
  description: Version of the API.
context:
  type: boolean
  description: Context of the API.
policy:
  type: string
  description: API level throttling policy.

#-
# The Application resource
#-
Application:
  properties:
id:
  type: integer
name:
  type: string
subId:
  type: integer
policy:
  type: string
  description: Application level throtting policy.
tokenType:
  type: string
  description: type of the token.
  example: JWT

#-
# The Subscription resource
#-
Subscription:
  properties:
policyId:
  type: integer
apiId:
  type: integer
appId:
  type: integer
subscriptionState:
  type: string

#-
# The Subscriber resource
#-
Subscriber:
  properties:
userId:
  type: integer
subscriberId:
  type: integer

#-
# The Application Key Mapping resource
#-
ApplicationKeyMapping:
  properties:
  applicationId:
type: integer
  consumerKey:
type: string
  keyType:
type: string

#-
# The Throttle Policy resource
#-
Policy:
  properties:
id:
  type: integer
tenantId:
  type: integer
name:
  type: string
quotaType:
  type: string

#-
# The Subscription Level Policy resource
#-
SubscriptionPolicy:
  properties:
allOf:
  $ref: '#/definitions/Policy'
rateLimitCount:
  type: integer
rateLimitTimeUnit:
  type: string
stopOnQuotaReach:
  type: boolean

#-
# The Application Level Policy resource
#-
ApplicationPolicy:
  properties:
allOf:
  $ref: '#/definitions/Policy'

#-
# The API Level Policy resource
#-
ApiPolicy:
  properties:
allOf:
  $ref: '#/definitions/Policy'
conditionGroups:
  type: array
  items:
$ref: '#/definitions/ApiPolicyConditionGroup'

#-
# The API Policy Condition  Group resource
#-
ApiPolicyConditionGroup:
  properties:
policyId:
  type: integer
quotaType:
  type: string
conditionGroupId:
  type: integer
condition:
  type: array
  items:
$ref: '#/definitions/Condition'

#-
# The Throttle Policy Condition resource
#-
Condition:
  properties:
conditionType:
  type: string
name:
  type: string
value:
  type: string
isInverted:
  type: boolean


Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi Tharindu,
We have changed the rest API tagging convention in publisher and devportal
REST APIs since 3.0.0 to use a common tag without separating as Collection
and Individual.
Shall we use the same convention here?
So that all of these will fall under the Key Manager tag.

Regarding the new table definition, if there is no specific reason in
APIM_KEYMGT_MAPPING and APIM_KEY_MANAGER names I would prefer to use and AM
instead of APIM
WDYT?


Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Thu, Apr 16, 2020 at 11:14 PM Tharindu Dharmarathna 
wrote:

> Hi All,
> Please find the database diagram on Implementation.
>
> [image: db diagram.png]
>
> let us know any feedback on this.
>
> Thanks & Regards
>
> On Thu, Apr 16, 2020 at 10:29 PM Tharindu Dharmarathna 
> wrote:
>
>> Hi Farasath,
>>
>> The authentication on those endpoints depends on the implementation
>> implemented for the specific oauth provider, there will be configuration
>> key value elements will be asked from user to retrieve those details.
>>
>> On Thu, Apr 16, 2020 at 6:34 PM Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 14, 2020 at 10:13 PM Tharindu Dharmarathna <
>>> tharin...@wso2.com> 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.
>>>>
>>>> Just a suggestion, most OAuth/OIDC providers expose a .wellknown
>>> configuration endpoint that gives some of these endpoints. For example,
>>> https://accounts.google.com/.well-known/openid-configuration
>>> Maybe we can support populating the URLs from using that endpoint as
>>> well in addition to configuring manually.
>>>
>>> 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.
>>>>
>>>> 6. Validating the Token.
>>>>
>>>>- Generated Token from Oauth Providers contains a specific change
>>>>related to the Token.
>>>>- 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.
>>>>
>>>
>>> Also, some of the endpoints exposed by OAuth providers will be protected
>>> with different auth mechanisms. How do we plan to handle this?
>>>
>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> *Tharindu Dharmarathna*Technical Lead
>>>> WSO2 Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>> mobile: *+94779109091*
>>>> ___
>>>> Architecture mailing l

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

[Ishara Cooray]

Hi Tharindu,

With this feature, will it also support changing the OAuth provider for an
existing app without changing subscriptions, etc?
If one needs to change their OAuth provider in the future this will help.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/



On Wed, Apr 15, 2020 at 9:32 AM Tharindu Dharmarathna 
wrote:

> Hi Gayan,
> For Self containing access tokens it already has the OOTB capability to
> validate the token from different token issuers. the Key Management layer
> will only use to validate the Reference tokens.
>
> To prefix, the token Generated from Identity providers, they have their
> own ways of differentiating the token, in Simple case, we will use the
> Regex validation and for other cases. they could write their own validation.
>
> Thanks
>
> On Tue, Apr 14, 2020 at 11:17 PM gayan gunawardana <
> gmgunaward...@gmail.com> wrote:
>
>> Hi Tharindu,
>>
>> In #6 Validating the Token, regex validation may work for
>> reference access tokens to find corresponding Oauth provider but can we
>> utilize regex validation for self-contained access tokens. Is it possible
>> mediate token generation and append specific prefix to identify Oauth
>> provider or else add mapping to a database table ?
>>
>> Thanks,
>> Gayan
>>
>> On Tue, Apr 14, 2020 at 10:13 PM Tharindu Dharmarathna <
>> tharin...@wso2.com> 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.
>>>
>>> 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.
>>>
>>> 6. Validating the Token.
>>>
>>>- Generated Token from Oauth Providers contains a specific change
>>>related to the Token.
>>>- 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.
>>>
>>>
>>> Thanks
>>>
>>> *Tharindu Dharmarathna*Technical Lead
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>> mobile: *+94779109091*
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Gayan
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
>
> *Tharindu Dharmarathna*Technical Lead
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091*
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi All,

Tested the following,

* Third-party key manager with OKTA
* Key Provisioning
* Self signup
* Workflows

No blockers found.
[+] Stable: go ahead and release.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Mon, Mar 23, 2020 at 12:21 PM Dushan Silva  wrote:

> Hi all,
>
> Tested following,
>
> * API Product
> * API Monetisation
> * Bot detection feature
> * JWT Authentication
>
> No blockers found.
> [+] Stable: go ahead and release.
>
> Thanks
>
> On Mon, Mar 23, 2020 at 10:55 AM Sachini De Silva 
> wrote:
>
>>
>> Hi all,
>>
>> Tested following,
>>
>> * API Categories
>> * Forgot Password
>> * Account Locking
>> * Password Policies
>> * Social Login with Facebook
>> * Application Attributes
>> * IS KM Basic flows
>>
>> No blockers found.
>>
>> [+] Stable: go ahead and release.
>>
>> Thanks,
>> Sachini
>>
>> On Mon, Mar 23, 2020 at 10:35 AM Kavishka Fernando 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have tested the following in super tenant and tenant:
>>>
>>>- Publisher Access control
>>>- Open API 2 and 3
>>>- API Key
>>>- API Comments
>>>- Email Username
>>>- API Store Visibility
>>>
>>> No blocking issues were found.
>>>
>>> [+] Stable: go ahead and release.
>>>
>>> On Mon, Mar 23, 2020 at 9:51 AM Vithursa Mahendrarajah <
>>> vithu...@wso2.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have tested following in super tenant and tenant:
>>>>
>>>>- REST API creation, subscription and invocation
>>>>- Basic auth endpoint security
>>>>- Digest auth endpoint security
>>>>- Secure APIs with Mutual SSL
>>>>- API Documentation
>>>>- SOAP APIs creation  and invocation
>>>>
>>>> No issues found.
>>>>
>>>> [+] Stable - go ahead and release.
>>>>
>>>> Thanks,
>>>> Vithursa
>>>>
>>>> On Mon, Mar 23, 2020 at 8:10 AM Hiranya Abeyrathne 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Tested the following with MySQL and Postgresql for the tenant and
>>>>> super tenant users.
>>>>>
>>>>> 1. REST and Graphql API creation, publishing, subscription and
>>>>> invoking using JWT and OAuth2 opaque tokens.
>>>>> 2. Operational level authentication, security,rate-limiting for
>>>>> Graphql APIs.
>>>>> 3. Application, Subscription, API and Resource Level Throttling.
>>>>> 4. APIM Analytics for Graphql APIs.
>>>>>
>>>>> No issues found.
>>>>> [+] Stable - go ahead and release
>>>>>
>>>>> Thanks!
>>>>> Hiranya Abeyrathne
>>>>> Software Engineer,
>>>>>
>>>>> *WSO2, Inc. *
>>>>>
>>>>> lean. enterprise. middleware
>>>>> Mob: +94 70210 8657
>>>>> LinkedIn: https://www.linkedin.com/in/hiranya-kavishani/
>>>>>
>>>>> <http://wso2.com/signature>
>>>>>
>>>>>
>>>>> On Mon, Mar 23, 2020 at 12:47 AM Viraj Gamage  wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Tested the following.
>>>>>>
>>>>>>- Import API to Microgateway Project
>>>>>>- Analytics with Microgateway
>>>>>>- Microgateway Analytics Report Generation.
>>>>>>
>>>>>> No issues found.
>>>>>>
>>>>>> [+] Stable - go ahead and release
>>>>>>
>>>>>> Regards,
>>>>>> Viraj
>>>>>>
>>>>>> On Sun, Mar 22, 2020 at 10:23 PM Rukshan Premathunga <
>>>>>> ruks...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Tested followings.
>>>>>>>
>>>>>>>- Tested followings in an APIM fully distributed system
>>>>>>>   - Verify profile optimization script
>>>>>>>   - Verify profile configuration
>>>&

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

[Ishara Cooray]

We will not allow deleting global scopes if they are attached to any
resource. Btw, Global scopes cannot be used across tenants, global scopes
can be defined locally to a tenant. When a global scope is updated (role
binding updates), we will provide a warning about the need to republish the
APIs. Because role binding updates will not immediately reflect in the
swagger unless we republish. Basic auth will not work properly in such
cases.

We will have to check for each resource of each api to identify the usages
of a scope. This could be done if the scopes are local to the tenant.
However, there should be a mechanism to filter the APIs associated with a
scope, that will help to identify which APIs to republish.
Maybe we can facilitate the Scope UI to list down the associated APIs as
well.

So isn't it make sense to call the scopes as *tenant local scopes *instead
of global scopes? Because global scopes imply that it is applicable across
tenants.



Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Wed, Feb 5, 2020 at 9:40 AM Dushani Wellappili  wrote:

> Hi Ishara,
>
> We will not allow deleting global scopes if they are attached to any
> resource. Btw, Global scopes cannot be used across tenants, global scopes
> can be defined locally to a tenant. When a global scope is updated (role
> binding updates), we will provide a warning about the need to republish the
> APIs. Because role binding updates will not immediately reflect in the
> swagger unless we republish. Basic auth will not work properly in such
> cases.
>
>
>
> *Dushani Wellappili*
> Senior Software Engineer - WSO2
>
> Email : dusha...@wso2.com
> Mobile : +94779367571
> Web : https://wso2.com/
>
>
>
>
> On Wed, Feb 5, 2020 at 5:31 AM Ishara Cooray  wrote:
>
>> Hi Dushani,
>>
>> If a global scope is modified or deleted it will affect all the APIs that
>> it is being used.
>> How do we handle this?
>> There should be a way to identify the APIs that the scope is
>> associated with.
>> And when deleting we need to make sure that none of the APIs using the
>> scope. When modifying we need to at least warn about the usages of the
>> scope.
>> Also, it will introduce complexities when it comes to tenants.
>>
>> IMO we should not allow modifying/deleting global scopes because we can
>> easily create a new scope to match the requirements.
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Associate Technical Lead
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>>
>> On Mon, Jan 27, 2020 at 12:04 PM Dushani Wellappili 
>> wrote:
>>
>>> Hi Rushmin,
>>>
>>>
>>> On Fri, Jan 24, 2020 at 5:37 PM Rushmin Fernando 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 20, 2020 at 12:29 PM Amila De Silva 
>>>> wrote:
>>>>
>>>>> A couple of other points needing the opinion of a wider audience are;
>>>>>
>>>>> 1. Whether only to support Global scopes in future releases and
>>>>> convert all per API scopes to Global scopes.
>>>>>
>>>>> One of the points raised during an internal discussion was that, per
>>>>> API scopes will get obsolete with the introduction of Global scopes, since
>>>>> a global scope can be used in the place of a per API scope. If an API
>>>>> Provider needs to use a completely different scope (than the ones already
>>>>> available in the system), they can still define it as a Global scope and
>>>>> assign it to the API/resource. The new scope will be a shared one and can
>>>>> be used for other APIs by different API developers.
>>>>> Unless an API Developer needs to restrict the usage of several scopes
>>>>> to a few selected APIs, Global scopes can replace per API scopes.
>>>>>
>>>>>
>>>> I believe that the UX of an API publisher gets affected due to the
>>>> following reasons if we allow only global scopes and not facilitate them
>>>> properly.
>>>>
>>>> - Two scopes might have the same name but might have two different
>>>> semantics in the context of two APIs.
>>>>
>>>
>>> Even with the current behavior (with local scopes), we do not provide
>>> the capability to have the same name for scopes of two different APIs.
>>> Irrespective of whether its a local or global scope, we will not allow
>>> having d

Re: [Architecture] PDF Report Generation for APIM Analytics

[Ishara Cooray]

In addition to the above, I think it will be useful if we could provide the
report in CSV format as well.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Thu, Jan 9, 2020 at 10:18 AM Kavishka Fernando  wrote:

> Regarding the report generation, Can't we render HTML pages as reports and
>> give users a print button to print or download it as PDF? In this way, I
>> think we will have more flexibility in styling and arranging the report
>> data. Basically providing a printable version of  the widget (Graph/Table/
>> pie chart etc,)
>
>
> +1 for this. Users can get more information about analytics and customize
> the report accordingly.
>
> On Thu, Jan 9, 2020 at 7:26 AM Fazlan Nazeem  wrote:
>
>> Hi Harsha,
>>
>> On Mon, Jan 6, 2020 at 9:52 PM Harsha Kumara  wrote:
>>
>>> Can we select range when generating the report? Also we need to evaluate
>>> what are the common requirements and provide the capability to generate the
>>> reports based on it.
>>>
>> The initial version may only have the capability to generate reports for
>> a particular month of an year. We will implement reports for a range of
>> time in the upcoming versions.
>>
>>>
>>> On Mon, Jan 6, 2020 at 5:47 PM Fazlan Nazeem  wrote:
>>>
>>>> Hi all,
>>>>
>>>> We have been constantly getting requests from customers to have a
>>>> proper PDF reporting mechanism where users can export analytics data in PDF
>>>> format. Therefore we have implemented a prototype of this feature for the
>>>> upcoming 3.1 release.
>>>>
>>>> The current prototype is implemented by exposing an MSF4J rest service
>>>> which will generate a hit count report for a particular month, year
>>>> combination. The month, year combination has to be passed as query params
>>>> to the API. Attached herewith is a PDF report generated by this service. We
>>>> are thinking of adding two more types of reports if time permits.
>>>> Altogether this makes 3 types of reports which can be downloaded.
>>>>
>>>> 1) Request Summary
>>>> 2) Throttle Summary
>>>> 3) Fault summary
>>>>
>>>> The plan is to secure the service with tenant admin credentials. This
>>>> means not all users who visit the analytics dashboard will be able to
>>>> download the PDF report unless he/she is an admin. We are thinking of
>>>> exposing a new dashboard with a single widget that takes the inputs (year,
>>>> month) and downloads this report. The dashboard will be secured with admin
>>>> role, resulting in only admin users being able to view this dashboard. The
>>>> rationale behind this decision is not to expose analytics data of publisher
>>>> access-controlled APIs to normal API publishers.
>>>>
>>>> Please provide your suggestions on any improvements or changes which
>>>> can add value to this feature.
>>>>
>>>> --
>>>> Thanks & Regards,
>>>>
>>>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
>>>> Mobile : +94772338839 | fazl...@wso2.com
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>> *Harsha Kumara*
>>>
>>> Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Email: hars...@wso2.coim
>>> Blog: harshcreationz.blogspot.com
>>>
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>> --
>> Thanks & Regards,
>>
>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
>> Mobile : +94772338839 | fazl...@wso2.com
>>
>>
>>
>
> --
> *Kavishka Fernando*
> *Software Engineer | WSO2*
> Email: kavis...@wso2.com
> Mobile:  +94773838069
> Web: http://wso2.com
> Blog: https://medium.com/@kavishkafernando
>
> <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

[Ishara Cooray]

Hi Dushani,

If a global scope is modified or deleted it will affect all the APIs that
it is being used.
How do we handle this?
There should be a way to identify the APIs that the scope is
associated with.
And when deleting we need to make sure that none of the APIs using the
scope. When modifying we need to at least warn about the usages of the
scope.
Also, it will introduce complexities when it comes to tenants.

IMO we should not allow modifying/deleting global scopes because we can
easily create a new scope to match the requirements.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Mon, Jan 27, 2020 at 12:04 PM Dushani Wellappili 
wrote:

> Hi Rushmin,
>
>
> On Fri, Jan 24, 2020 at 5:37 PM Rushmin Fernando  wrote:
>
>>
>>
>> On Mon, Jan 20, 2020 at 12:29 PM Amila De Silva  wrote:
>>
>>> A couple of other points needing the opinion of a wider audience are;
>>>
>>> 1. Whether only to support Global scopes in future releases and convert
>>> all per API scopes to Global scopes.
>>>
>>> One of the points raised during an internal discussion was that, per API
>>> scopes will get obsolete with the introduction of Global scopes, since a
>>> global scope can be used in the place of a per API scope. If an API
>>> Provider needs to use a completely different scope (than the ones already
>>> available in the system), they can still define it as a Global scope and
>>> assign it to the API/resource. The new scope will be a shared one and can
>>> be used for other APIs by different API developers.
>>> Unless an API Developer needs to restrict the usage of several scopes to
>>> a few selected APIs, Global scopes can replace per API scopes.
>>>
>>>
>> I believe that the UX of an API publisher gets affected due to the
>> following reasons if we allow only global scopes and not facilitate them
>> properly.
>>
>> - Two scopes might have the same name but might have two different
>> semantics in the context of two APIs.
>>
>
> Even with the current behavior (with local scopes), we do not provide the
> capability to have the same name for scopes of two different APIs.
> Irrespective of whether its a local or global scope, we will not allow
> having duplicate scope keys/names.
>
>
>> - There might be scopes which are semantically same but have different
>> names.
>>
> This is a case where we cannot control. IMO, it is a design choice of the
> privileged user/admin to create different scopes with same role bindings
> and use them across multiple APIs.
>
>>
>> So this might create confusion when choosing the scopes for an API unless
>> this is well-governed.
>>
>>
>>
>>> 2. While creating an API using the Swagger, only doing the scope
>>> assignments without creating any new scope.
>>>
>>> Suggestion is to use scopes defined in the swagger only to do scope to
>>> resource assignment. If the scopes are already available in the System,
>>> those will be assigned to the Resources as specified by the Swagger. If
>>> not, the API will be created without creating any scopes. This would help
>>> removing scope to role mapping from swagger and would also eliminate the
>>> need of identifying Global and Per-API scopes differently. But a different
>>> configuration is needed to keep that information while exporting/importing
>>> APIs. The idea is to have a clean Swagger while moving all wso2 specific
>>> configurations to a different file.
>>>
>>>
>>> On Mon, Jan 20, 2020 at 11:50 AM Dushani Wellappili 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> According to the recent discussions we've had, we have modified the
>>>> initial DB design as follows.
>>>>
>>>>- Remove the FK constraint on SCOPE_ID, as it would be easy when
>>>>decoupling API-M from IS components in the future.
>>>>- Add a UUID for Global Scopes to support REST APIs
>>>>
>>>> AM_GLOBAL_SCOPE
>>>>  SCOPE_ID INTEGER NOT NULL,
>>>>  TENANT_ID INTEGER DEFAULT -1,
>>>>  UUID VARCHAR (256)
>>>>
>>>> In addition, the following points are highlighted which we need to
>>>> discuss further.
>>>>
>>>>- The management of scopes can be done in the Publisher Portal and
>>>>it would make more sense if move it to the same UI view of APIs as 
>>>> scopes
>>

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

[Ishara Cooray]

Hi,

In addition to the above,
if we want to enable customer url per tenant we need to add callback URLs
of each tenant in the service provider config.
Which seems to be not scalable.

This can be mitigated to some extent by creating SPs per tenant.
Any thoughts?

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


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

>
>
> On Tue, Jan 7, 2020 at 12:27 PM Malintha Amarasinghe 
> wrote:
>
>>
>>
>> On Tue, Jan 7, 2020 at 12:23 PM Harsha Kumara  wrote:
>>
>>>
>>>
>>> On Tue, Jan 7, 2020 at 12:20 PM Malintha Amarasinghe 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Currently, we do not support $subject and we always use the local IDP
>>>> as the login/logout URLs (/authorize and /oidc/logout). In normal cases,
>>>> this works without issues. But when it comes to configuring federated login
>>>> with facebook, google etc, it is required to use IS (IS as KM) as the
>>>> intermediate IDP which has the required authenticators to support
>>>> facebook/google logins. In those cases, we need to point the local IDP to
>>>> the IS/KM and the IS/KM points to Facebook as a federated login. But this
>>>> flow has unnecessary one additional hop caused by the local IDP.
>>>>
>>>> As a solution, we plan to support externalizing the IDP URL (used for
>>>> /authorize and /oidc/logout).
>>>>
>>>> [image: image.png]
>>>>
>>>> The plan is to introduce new configs as below:
>>>>
>>>> *api-manager.xml*
>>>>
>>>> {% if apim.idp is defined %}
>>>> 
>>>> 
>>>>
>>>> {{apim.idp.authorize_endpoint}}
>>>>
>>>> {{apim.idp.oidc_logout_endpoint}}
>>>>
>>>> 
>>>> {% endif %}
>>>>
>>>> *deployment.toml*
>>>>
>>>> #[api.idp]
>>>> #authorize_endpoint = "https://localhost:9444/oauth2/authorize;
>>>> #oidc_logout_endpoint = "https://localhost:9444/oidc/logout;
>>>>
>>> Token endpoint will be pointed to  gateway?
>>>
>>
>> No, it will still use the local endpoints eg;
>> https://localhost:9443/oauth2/token. All the backend calls (generate
>> token, DCR, refresh token) will use the local hardcoded endpoints in 9443
>> port.
>> Hope that would not cause an issue?
>>
> Yes that should be fine.  Since we do share databases in this scenario, it
> should be fine to go with the local endpoints.
>
>>
>> Thanks!
>>
>>>
>>>> By default, the server will use the local IDP for login/logout. Only,
>>>> if the above URLs are configured, they will be used instead of the default
>>>> ones.
>>>>
>>>> Thoughts are highly appreciated.
>>>>
>>>> Thanks!
>>>> Malintha
>>>>
>>>> --
>>>> Malintha Amarasinghe
>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>> http://wso2.com/
>>>>
>>>> Mobile : +94 712383306
>>>>
>>>
>>>
>>> --
>>>
>>> *Harsha Kumara*
>>>
>>> Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Email: hars...@wso2.coim
>>> Blog: harshcreationz.blogspot.com
>>>
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: hars...@wso2.coim
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi All,

Tested the following.
- API Creation, Publishing, Subscription in super tenant and tenant.
- Reverse proxy configuration for publisher and devportal
- CORS
- Custom authorization header
- Message Mediation Policies

No Blockers found. Hence, +1.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Fri, Oct 25, 2019 at 4:59 PM Ruwini Wijesiri  wrote:

> Hi all,
>
> Tested analytics with access controls and tenancy.
>
> No blockers found. Hence,  +1 to go ahead with the release.
>
> Regards,
> Ruwini
>
> On Fri, Oct 25, 2019 at 4:40 PM Tanya Madurapperuma 
> wrote:
>
>> Hi,
>>
>> Tested the following.
>>
>> - Api creation, publishing and invoking
>> - Api properties
>> - Api and document Search
>> - Analytics dashboards with access control and tenancy
>>
>> No blockers found. Hence,
>>  [+] Stable - go ahead and release
>>
>> Thanks,
>> Tanya
>>
>>
>>
>> On Fri, Oct 25, 2019 at 4:20 PM Silmy Hasan  wrote:
>>
>>> Tested Monetization for both super tenant and tenant
>>> no blockers found , +1 for the release.
>>>
>>> On Fri, Oct 25, 2019 at 4:16 PM Chamila Adhikarinayake <
>>> chami...@wso2.com> wrote:
>>>
>>>> Tested
>>>> -custom keymanager implementation
>>>> -provision out-of-band OAuth keys
>>>> -pass custom attributes from rest API to custom keymanager
>>>> implementation (for external OAuth app creation scenario)
>>>>
>>>> and no blockers found
>>>> +1 for the release
>>>>
>>>> On Fri, Oct 25, 2019 at 4:08 PM Lakshitha Gunasekara <
>>>> lakshi...@wso2.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Tested the following.
>>>>>
>>>>> - Analytics on windows
>>>>> - On Windows as a Service
>>>>>
>>>>> No blockers found. +1 for the release.
>>>>>
>>>>> Thanks,
>>>>> Lakshitha
>>>>>
>>>>> On Fri, Oct 25, 2019 at 4:02 PM Arshardh Ifthikar 
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>> Tested the following scenarios,
>>>>>>
>>>>>>- Correlation logs (Verified the logs printed for an API
>>>>>>invocation)
>>>>>>- WebSocket API creation, invocation, throttling (count and
>>>>>>bandwidth) and analytics
>>>>>>- Basic flows with PostgreSQL 12.0
>>>>>>
>>>>>> No blockers found. Stable.
>>>>>> +1 Go ahead and release.
>>>>>>
>>>>>> Thanks,
>>>>>> Arshardh
>>>>>>
>>>>>> On Fri, Oct 25, 2019 at 2:53 PM Nalaka Senarathna 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>> Tested the followings.
>>>>>>> - Token cleanup
>>>>>>> - Caching
>>>>>>> - API /API product invocation and visibility
>>>>>>> - SDK feature
>>>>>>> - Pass end-user attributes to backend using JWT
>>>>>>> - Alert subscription
>>>>>>> - Basic flows in oracle and db2
>>>>>>>
>>>>>>> Stable and go ahead and release.
>>>>>>> Thanks & Regards.
>>>>>>> Nalaka
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 25, 2019 at 2:44 PM Hasunie Adikari 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have tested the following
>>>>>>>>
>>>>>>>> - Micro-gw API import and label import.
>>>>>>>> - Micro-gw analytics.
>>>>>>>> - API request/response validator.
>>>>>>>> - Self signup.
>>>>>>>> - Scope test.
>>>>>>>> - API invocation and analytics.
>>>>>>>> - Tested API manager scenarios in both super tenant and tenant.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hasunie
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct

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

[Ishara Cooray]

Hi All,

Tested the following.
- API Creation, Publishing, Subscription in super tenant and tenant.
- Reverse proxy configuration for publisher and devportal
- CORS
- Custom authorization header
- Message Mediation Policies

No blockers found. Hence +1.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Thu, Oct 24, 2019 at 4:19 PM Mushthaq Rumy  wrote:

> Hi All,
>
> Tested the following scenarios.
> - API Creation, Publishing and Subscription
> - Tested Publisher Access Control
> - Tested Store visibility
> - Identity management features such as self sign up, password reset,
> password policy, account locking.
>
> No blockers found. Hence +1.
>
> Thanks & Regards,
> Mushthaq
>
> On Thu, Oct 24, 2019 at 4:15 PM Prasanna Dangalla 
> wrote:
>
>> Hi All,
>>
>> Tested API Creation, Publishing, Subscription JWT & OAuth Token
>> generation and throttling.
>>
>> Hence +1 from me.
>>
>> Thanks
>> *Prasanna Dangalla* | Associate Technical Lead | WSO2 Inc.
>> (m) +94 718 112 751 | (e) prasa...@wso2.com
>> [image: Signature.jpg]
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 24, 2019 at 8:51 AM Mushthaq Rumy  wrote:
>>
>>> Hi All,
>>>
>>> We are pleased to announce the second release candidate of WSO2 API
>>> Manager 3.0.0.
>>>
>>> This release fixes the following issues.
>>>
>>>- Fixes : carbon-apimgt
>>>
>>> <https://github.com/wso2/carbon-apimgt/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-23+>
>>>- Fixes : product-apim
>>>
>>> <https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-23>
>>>- Fixes : analytics-apim
>>>
>>> <https://github.com/wso2/analytics-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-23>
>>>
>>> Source and distribution,
>>> Runtime :
>>> https://github.com/wso2/product-apim/releases/tag/v3.0.0-rc2
>>> Analytics :
>>> https://github.com/wso2/analytics-apim/releases/tag/v3.0.0-rc2
>>> APIM Tooling :
>>> https://github.com/wso2/product-apim-tooling/releases/tag/v3.0.0-rc
>>>
>>> Please download, test the product and vote.
>>>
>>> [+] Stable - go ahead and release
>>> [-] Broken - do not release (explain why)
>>>
>>> Thanks,
>>> WSO2 API Manager Team
>>>
>>>
>>> --
>>> Mushthaq Rumy
>>> *Senior Software Engineer*
>>> Mobile : +94 (0) 779 492140
>>> Email : musht...@wso2.com
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middleware.
>>>
>>> <http://wso2.com/signature>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Mushthaq Rumy
> *Senior Software Engineer*
> Mobile : +94 (0) 779 492140
> Email : musht...@wso2.com
> WSO2, Inc.; http://wso2.com/
> lean . enterprise . middleware.
>
> <http://wso2.com/signature>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM 3.0.0 Mediation Policy REST API

[Ishara Cooray]

Hi Dushan,
Thanks for the response.

Whats the purpose of saving the method it was received (sourceType) ?
Correct me if i'm wrong but I feel like we do not need it as I do not see
that value being useful.

inline editor in the future to edit the mediation policies withing the
publisher portal.

Even for this we do not need to save the sourceType right ?

This was to track the type that the policy is uploaded, and based on that
we could decide whether we show it in the inline editor or download.
According to my previous mail we decided to remove it as we can always show
the mediation policy in the editor because it is an xml file.


Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Fri, Aug 30, 2019 at 4:48 PM Ishara Cooray  wrote:

> Hi Malintha,
> Thanks for the response.
> Please find my comments inline.
>
> But I doubt we still need, sourceType. We use sourceType: FILE/INLINE for
> documents because we allow people to upload PDF etc which are binary and
> not editable in a text editor. But for mediation policies, it is always
> text so we can even allow people to update uploaded files as well via the
> inline editor.
> The idea to have sourceType is to keep track of the method that the policy
> is added and based on that we can decide whether to show the file in the
> editor or download as a file.
> As per the offline chat with Malintha, we can always show the policy
> content in the inline editor regardless of it is a file upload or inline
> content.
> Hence there is no requirement to keep track of the source type.
> Therefore +1 to remove the sourceType from the Mediation resource.
>
> I guess we do not need the extension here? We can use the name only.
> I think it make sense to have the extension as it always xml. wdyt?
>
> Shall we use: "API Mediation Policies" (plural format as other existing
> tags).
> Shall we use: "Global Mediation Policies" (plural format as other existing
> tags).
> I used the singular format because it refers to an individual policy.
>
> /apis/{apiId}/mediation-policies/{mediationPolicyId}/content
>
> /mediation-policies/{mediationPolicyId}/content
>
> And for /mediation-policies: i have used the *Global Mediation Policies*
>
> Also
> *,*
>
> '/apis/{apiId}/mediation-policies': API Mediation Policies
> /apis/{apiId}/mediation-policies/{mediationPolicyId}: API Mediation Policy
>
> wdyt?
>
>
> Thanks & Regards,
> Ishara Cooray
> Associate Technical Lead
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
>
> On Fri, Aug 30, 2019 at 10:11 AM Dushan Silva  wrote:
>
>> Hi ishara,
>> Whats the purpose of saving the method it was received (sourceType) ?
>> Correct me if i'm wrong but I feel like we do not need it as I do not see
>> that value being useful.
>>
>> inline editor in the future to edit the mediation policies withing the 
>> publisher portal.
>>
>> Even for this we do not need to save the sourceType right ?
>>
>> On Fri, Aug 30, 2019 at 9:17 AM Malintha Amarasinghe 
>> wrote:
>>
>>> Few inline comments:
>>>
>>> On Fri, Aug 30, 2019 at 6:04 AM Ishara Cooray  wrote:
>>>
>>>> Hi,
>>>> In APIM 3.0.0 Publisher rest api , we have introduced separate two APIs
>>>> to retrieve mediation policy content as files. Each for API specific custom
>>>> mediation policy content and for global mediation policy content.
>>>>
>>>> Previously, mediation policy content was in the same Mediation resource
>>>> as below.
>>>>
>>>> #-
>>>> # The Mediation resource
>>>> #-
>>>> Mediation:
>>>>   title: Mediation
>>>>   required:
>>>> - name
>>>> - type
>>>> - config
>>>>   properties:
>>>> id:
>>>>   type: string
>>>>   example: 01234567-0123-0123-0123-012345678901
>>>> name:
>>>>   type: string
>>>>   example: json_fault.xml
>>>>
>>>> type:
>>>>   type: string
>>>>   enum:
>>>> - in
>>>> - out
>>>> - fault
>>>>   example: in
>>>> config:
>>>>   type: string
>>>>   example: 'http://ws.apache.org/ns/synapse; 
>>>> name="log_in_message">

Re: [Architecture] APIM 3.0.0 Mediation Policy REST API

[Ishara Cooray]

Hi Malintha,
Thanks for the response.
Please find my comments inline.

But I doubt we still need, sourceType. We use sourceType: FILE/INLINE for
documents because we allow people to upload PDF etc which are binary and
not editable in a text editor. But for mediation policies, it is always
text so we can even allow people to update uploaded files as well via the
inline editor.
The idea to have sourceType is to keep track of the method that the policy
is added and based on that we can decide whether to show the file in the
editor or download as a file.
As per the offline chat with Malintha, we can always show the policy
content in the inline editor regardless of it is a file upload or inline
content.
Hence there is no requirement to keep track of the source type.
Therefore +1 to remove the sourceType from the Mediation resource.

I guess we do not need the extension here? We can use the name only.
I think it make sense to have the extension as it always xml. wdyt?

Shall we use: "API Mediation Policies" (plural format as other existing
tags).
Shall we use: "Global Mediation Policies" (plural format as other existing
tags).
I used the singular format because it refers to an individual policy.

/apis/{apiId}/mediation-policies/{mediationPolicyId}/content

/mediation-policies/{mediationPolicyId}/content

And for /mediation-policies: i have used the *Global Mediation Policies*

Also
*,*

'/apis/{apiId}/mediation-policies': API Mediation Policies
/apis/{apiId}/mediation-policies/{mediationPolicyId}: API Mediation Policy

wdyt?


Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Fri, Aug 30, 2019 at 10:11 AM Dushan Silva  wrote:

> Hi ishara,
> Whats the purpose of saving the method it was received (sourceType) ?
> Correct me if i'm wrong but I feel like we do not need it as I do not see
> that value being useful.
>
> inline editor in the future to edit the mediation policies withing the 
> publisher portal.
>
> Even for this we do not need to save the sourceType right ?
>
> On Fri, Aug 30, 2019 at 9:17 AM Malintha Amarasinghe 
> wrote:
>
>> Few inline comments:
>>
>> On Fri, Aug 30, 2019 at 6:04 AM Ishara Cooray  wrote:
>>
>>> Hi,
>>> In APIM 3.0.0 Publisher rest api , we have introduced separate two APIs
>>> to retrieve mediation policy content as files. Each for API specific custom
>>> mediation policy content and for global mediation policy content.
>>>
>>> Previously, mediation policy content was in the same Mediation resource
>>> as below.
>>>
>>> #-
>>> # The Mediation resource
>>> #-
>>> Mediation:
>>>   title: Mediation
>>>   required:
>>> - name
>>> - type
>>> - config
>>>   properties:
>>> id:
>>>   type: string
>>>   example: 01234567-0123-0123-0123-012345678901
>>> name:
>>>   type: string
>>>   example: json_fault.xml
>>>
>>> type:
>>>   type: string
>>>   enum:
>>> - in
>>> - out
>>> - fault
>>>   example: in
>>> config:
>>>   type: string
>>>   example: 'http://ws.apache.org/ns/synapse; 
>>> name="log_in_message">
>>> 
>>> >> value="IN_MESSAGE_21133232"/>
>>> 
>>> '
>>>
>>> *In APIM 3.0.0* this is changed to,
>>> #-
>>> # The Mediation resource
>>> #-
>>> Mediation:
>>>   title: Mediation
>>>   required:
>>>   - name
>>>   - type
>>>   properties:
>>> id:
>>>   type: string
>>>   example: 01234567-0123-0123-0123-012345678901
>>> name:
>>>   type: string
>>>   example: json_fault.xml
>>>
>>> I guess we do not need the extension here? We can use the name only.
>>
>>> type:
>>>   type: string
>>>   enum:
>>>   - in
>>>   - out
>>>   - fault
>>>   example: in
>>> sourceType:
>>>   type: string
>>>   enum:
>>>   - FILE
>>>   - INLINE
>>>
>>> ** config property has been removed and a new property sou

[Architecture] APIM 3.0.0 Mediation Policy REST API

[Ishara Cooray]

Hi,
In APIM 3.0.0 Publisher rest api , we have introduced separate two APIs to
retrieve mediation policy content as files. Each for API specific custom
mediation policy content and for global mediation policy content.

Previously, mediation policy content was in the same Mediation resource as
below.

#-
# The Mediation resource
#-
Mediation:
  title: Mediation
  required:
- name
- type
- config
  properties:
id:
  type: string
  example: 01234567-0123-0123-0123-012345678901
name:
  type: string
  example: json_fault.xml
type:
  type: string
  enum:
- in
- out
- fault
  example: in
config:
  type: string
  example: 'http://ws.apache.org/ns/synapse;
name="log_in_message">



'

*In APIM 3.0.0* this is changed to,
#-
# The Mediation resource
#-
Mediation:
  title: Mediation
  required:
  - name
  - type
  properties:
id:
  type: string
  example: 01234567-0123-0123-0123-012345678901
name:
  type: string
  example: json_fault.xml
type:
  type: string
  enum:
  - in
  - out
  - fault
  example: in
sourceType:
  type: string
  enum:
  - FILE
  - INLINE

** config property has been removed and a new property sourceType is introduced.

sourceType will decide whether the mediation policy content is
received as a file or inline content.
Because we are planing to give an inline editor in the future to edit
the mediation policies withing the publisher portal.

So to get a content of a mediation policy we have introduced below two
rest apis.

###
# The "Individual API specific mediation sequence content" resource
###
/apis/{apiId}/mediation-policies/{mediationPolicyId}/content:

  #---
  # Retrieve a particular API specific mediation sequence content
  #---
  get:
security:
- OAuth2Security:
  - apim:api_view
x-examples:
  $ref: docs/examples/apis/apis_id_mediationpolicies_id_content_get.yaml
summary: Downloadt an API specific mediation policy
description: |
  This operation can be used to download a particular API specific
mediation policy.
parameters:
- $ref: '#/parameters/apiId'
- $ref: '#/parameters/mediationPolicyId'
- $ref: '#/parameters/If-None-Match'
tags:
- API Mediation Policy
responses:
  200:
description: |
  OK.
  Mediation policy returned.
headers:
  Content-Type:
description: |
  The content type of the body.
type: string
  ETag:
description: |
  Entity Tag of the response resource.
  Used by caches, or in conditional requests (Will be
supported in future).
type: string
  Last-Modified:
description: |
  Date and time the resource has been modifed the last time.
  Used by caches, or in conditional requests (Will be
supported in future).
type: string
  304:
description: |
  Not Modified.
  Empty body because the client has already the latest version
of the requested resource (Will be supported in future).
  404:
description: |
  Not Found.
  Requested file does not exist.
schema:
  $ref: '#/definitions/Error'


###
# The "Individual Global mediation policy content" resource
###
/mediation-policies/{mediationPolicyId}/content:

  #---
  # Retrieve a particular Global mediation sequence content
  #---
  get:
security:
- OAuth2Security:
  - apim:api_view
summary: Downloadt specific global mediation policy
description: |
  This operation can be used to download a particular global
mediation policy.
parameters:
- $ref: '#/parameters/mediationPolicyId'
- $ref: '#/parameters/If-None-Match'
tags:
- Global Mediation Policy

Thanks & Regards,

Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi,

4) Back-end JWTs will be included in as part of the access token itself
(self-contained). This eliminates the need of creating back-end JWTs while
the API request is being processed. Which in turn makes APIs calls much
faster.

Only concern, this might lead the header to become very large.
In that case we will have to increase the header size.
Alternatively, HPACK[1] in http/2 (Header Compression for HTTP2) might be
useful.


[1] https://httpwg.org/specs/rfc7541.html

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Thu, Aug 22, 2019 at 11:04 AM Nuwan Dias  wrote:

>
>
> On Wed, 21 Aug 2019 at 10:57 pm, Manjula Rathnayake 
> wrote:
>
>> Hi Nuwan,
>>
>> Can the same API gateway handle both self-contained and opaque tokens?
>>
>
> Yes it can. The gateway needs to be connected to the key manager if it is
> expected to validate opaque tokens.
>
>>
>> How does the API consumption work? Does the application need to invoke
>> both the KM and gateway endpoints to refresh/revoke and invoke the APIs?
>>
>
> If the gateway is connected to the key manager the app can use the /token
> and /revoke endpoints on the gateway itself. Otherwise the key manager
> needs to be expose them some other way for apps to use.
>
>>
>> Thank you.
>>
>> On Wed, Aug 21, 2019 at 1:21 PM Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Tue, Aug 20, 2019 at 2:37 PM Nuwan Dias  wrote:
>>>
>>>> Hi,
>>>>
>>>> With the introduction of the Microgateway self-contained access tokens
>>>> were supported in the API Manager since version 2.5. Self-contained access
>>>> tokens however were only supported in the Microgateway so far. The regular
>>>> gateway was unable to process and validate a self-contained access token.
>>>> With API Manager 3.0 we are bringing this support to the regular gateway as
>>>> well. With this we hope to make self-contained tokens the default token
>>>> type of applications. Opaque tokens will still be supported as before.
>>>> There are several benefits of using self-contained access tokens. These 
>>>> are,
>>>>
>>>> 1) The gateway no longer connects to the Key Manager when processing
>>>> API requests. This makes the deployment simpler and reduces configuration
>>>> points a bit.
>>>> 2) We no longer have to scale the Key Manager when we need the Gateway
>>>> to be scaled. This bring a significant reduction to the cost of using the
>>>> product in larger deployments.
>>>> 3) The gateway becomes regionally resilient. A token issued from one
>>>> region can be validated by a gateway in another region even if the data is
>>>> not synced.
>>>> 4) Back-end JWTs will be included in as part of the access token itself
>>>> (self-contained). This eliminates the need of creating back-end JWTs while
>>>> the API request is being processed. Which in turn makes APIs calls much
>>>> faster.
>>>>
>>>> One pending items that's left to handle is the revocation of
>>>> self-contained access tokens. Since the gateway does not connect to the Key
>>>> Manager for validating self-contained tokens, the gateway will not know
>>>> when a particular token has been revoked. Using shorter expiry times for
>>>> access token addresses this solution to a certain extent. We hope to
>>>> implement the same solution we implemented for the Microgateway to address
>>>> this. The Key Manager will be notifying the gateway cluster through a
>>>> broker when a token has been revoked. And the gateway will no longer be
>>>> treating the particular token as valid upon receiving the notification.
>>>>
>>>> Appreciate your thoughts and suggestions on this.
>>>>
>>>
>>> So we are making it as default to increase the usage of it ?
>>>
>>> Is this would be same for developer token in store (application tokens)?
>>> What are the default user details which are adding to self-contains
>>> access token ?
>>>
>>> Thanks,
>>> Asela.
>>>
>>>
>>>>
>>>> Thanks,
>>>> NuwanD.
>>>> --
>>>> *Nuwan Dias* | Director | WSO2 Inc.
>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>>>> [image: Signature.jpg]
>>>> ___
>>>> Architecture mail

Re: [Architecture] [APIM 3.0.0] Publisher REST APIs for mediation policies

[Ishara Cooray]

For viewing, shall we use a single scope: apim:mediation_policy_view
But, it make sense to have the apim:api_view scope to view mediation
policies of an api IMO
If not, a user with apim:api_view scope can see the api but unable to see
the mediation policies due to missing apim:mediation_policy_view scope. Do
we need a separation here?

Also for the tag: shall we simplify as "Mediation Policies"
+1

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Thu, Aug 15, 2019 at 2:32 PM Malintha Amarasinghe 
wrote:

> Hi Ishara,
>
> +1 for the overall approach.
>
> For viewing, shall we use a single scope: apim:mediation_policy_view
>
> Also for the tag: shall we simplify as "Mediation Policies"
>
> Thanks!
>
>
> On Tue, Aug 13, 2019 at 1:18 PM Ishara Cooray  wrote:
>
>> Hi,
>> I have started working on the $Subject and below is the rest api
>> definitions.
>>
>>
>>- To avoid string manipulations, Mediation policy post is done as a
>>file upload. Hence we can provide the sequence file(xml content) as an
>>input in the form of multipart/form-data
>>ex:
>>
>>curl -X POST 
>> https://localhost:9443/api/am/publisher/v1.0/apis/2a3d5469-5394-4576-974a-5f8bf7e400bd/mediation-policies
>>-H "Authorization: Bearer 5cbc7d4f-d4f1-33c9-87e4-68a22ae7e602"
>>-F file=@sampleSeq2.xml
>>-H "Content-Type: multipart/form-data"
>>-F "type=in"
>>
>>- To retrieve a mediation sequence, a new REST api has been
>>introduced which will download sequence as a file. Where as in APIM 2.x
>>REST API it was returning as a string.
>>Please refer
>>/apis/{apiId}/mediation-policies/{mediationPolicyId}/content:
>>
>>
>> ##
>> # The "specific mediation policy" resource APIs
>> ##
>> '/apis/{apiId}/mediation-policies':
>>
>>   
>> #-
>>   # Retrieving the list of all API specific mediation sequences under a 
>> given search condition
>>   
>> #-
>>   get:
>> security:
>>   - OAuth2Security:
>> - apim:mediation_policy_view
>> x-examples:
>> $ref: docs/examples/apis/apis_id_mediationpolicies_get.yaml
>> summary: |
>>   Get all mediation policies of an API
>> operationid:  apisApiIdMediationPoliciesGet
>> description: |
>>   This operation provides you a list of available mediation policies of 
>> an API.
>> parameters:
>>   - $ref: '#/parameters/apiId'
>>   - $ref : '#/parameters/limit'
>>   - $ref : '#/parameters/offset'
>>   - name : query
>> in: query
>> description: "-Not supported yet-"
>> type: string
>>   - $ref : "#/parameters/If-None-Match"
>> tags:
>>   - Mediation Policies of an API
>> responses:
>>   200:
>> description: |
>>   OK.
>>   List of qualifying APIs is returned.
>> schema:
>>   $ref: '#/definitions/MediationList'
>> headers:
>>   Content-Type:
>> description: The content type of the body.
>> type: string
>>   ETag:
>> description: |
>>   Entity Tag of the response resource. Used by caches, or in 
>> conditional requests (Will be supported in future).
>> type: string
>>   304:
>> description: |
>>   Not Modified.
>>   Empty body because the client has already the latest version of 
>> the requested resource (Will be supported in future).
>>   406:
>> description: |
>>   Not Acceptable.
>>   The requested media type is not supported
>> schema:
>>   $ref: '#/definitions/Error'
>>
>>   
>> #
>>   # Upload an API specific mediation policy
>>   
>> #
>>   post:
>> consumes:
>> - multipart/form-data
>> security:
>>   - OAuth2Security:
>> 

Re: [Architecture] [APIM] [3.0] Publishing to External Stores via Publisher REST APIs

[Ishara Cooray]

Hi,

We can move the same functionality to the "*POST
/import/api?preserveProvider={false}  -F file={@api.zip}*" API with another
optional query parameter "*isOverwrite*" to update an existing API. Instead
of giving the APIID to update, can't we get the existing API using the
name, version, and tenantDomain of the logged-in user?  We already have an
APIUtil method to retrieve an API using the above three arguments [1].
Would this break the story of updating APIs in CI/CD flow?
Mentioned util method returns the provider name , but not the apiId.

IMO correct approach to update an api artifact is to have the* PUT *method
rather than having an option in the POST method.
Where we can have
*PUT /import/api?preserveProvider={false}  -F file={@api.zip}*

we can obtain the apiId as below .

1. get the provider name from the above suggested util method.
 APIUtil.getAPIProviderFromAPINameVersionTenant
2.  Create an APIIdentifier
APIIdentifier apiIdentifier = new APIIdentifier(providerName, apiName,
apiVersion);
3. Obtain apiId.
int apiId = ApiMgtDAO.getInstance().getAPIID(apiIdentifier, null);


Thanks & Regards,
Ishara Udeshika Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Wed, Aug 14, 2019 at 11:19 AM Dushani Wellappili 
wrote:

> Hi all,
>
> After we decided to go ahead with the import-export approach, we decided
> to move the existing api-import-export APIs to Admin REST APIs (similar to
> current application-import-export APIs). So the Admin REST API will have
> the following two new resources.
>
> *GET
> /export/api?name={APIName}={version}={providerName}*
>
> *curl -H "Authorization:Basic YWRtaW46YWRtaW4=" -X GET
> "https://localhost:9443/api/am/admin/v0.14/export/api?name=PizzaShackAPI=1.0.0=admin
> "
>  -k > exportAPI.zip  -i*
>
> *POST /import/api?preserveProvider={false}  -F file={@api.zip}*
>
> *curl -H "Authorization:Basic YWRtaW5AYWJjLmNvbTphZG1pbg==" -F
> file=@PizzaShackAPI-1.0.0.zip  -X POST
> "https://localhost:9443/api/am/admin/v0.14/import/api?preserveProvider=false
> "
>  -k -i*
>
> Recently we have added another new resource "*PUT 
> /{apiID}**?preserveProvider={false}
> -F file={@api.zip}**"* to the current api-import-export webapp to update
> an existing API by given API ID (AFAIK we have added it to support the
> CI/CD flow).  We need to move the same to new Admin api-import-export REST
> APIs as well. However, it does not seems right to define the resource as "*PUT
> update/{apiID}**?preserveProvider={false}  -F file={@api.zip}"*.
>
> We can move the same functionality to the "*POST
> /import/api?preserveProvider={false}  -F file={@api.zip}*" API with
> another optional query parameter "*isOverwrite*" to update an existing
> API. Instead of giving the APIID to update, can't we get the existing API
> using the name, version, and tenantDomain of the logged-in user?  We
> already have an APIUtil method to retrieve an API using the above three
> arguments [1]. Would this break the story of updating APIs in CI/CD flow?
>
> Appreciate your thoughts in moving forward.
>
> [1]
> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/utils/APIUtil.java#L6798
>
> Thanks
>
> *Dushani Wellappili*
> Software Engineer - WSO2
>
> Email : dusha...@wso2.com
> Mobile : +94779367571
> Web : https://wso2.com/
>
>
>
>
> On Wed, Aug 7, 2019 at 6:32 PM Malintha Amarasinghe 
> wrote:
>
>>
>>
>> On Tue, Aug 6, 2019 at 9:35 PM Dushani Wellappili 
>> wrote:
>>
>>> Hi all,
>>>
>>> When publishing to external stores, at runtime we need to use API
>>> create, life-cycle change, create a version, add API thumbnail, delete
>>> Publisher REST APIs. In order to create the API payload, we need to do the
>>> mapping from API object to APIDTO. Reusing the existing APIDTO or
>>> APIMappingUtil classes are not possible as we do not import rest.api
>>> dependencies to impl level. Creating the payload manually from scratch will
>>> not be a very cleaner approach, also we will be duplicating the same logic.
>>>
>>> Hence following are the options which might help us to achieve this.
>>>
>>>- Generate a REST client using publisher REST API swagger (using
>>>openapi-generator plugin) and pack it as a jar in the product (packing 
>>> the
>>>component inside service-stubs). But for that, we need to pack an
>>>additional set of dependencies to lib as well. For example, the generated
>>>client is using okhttp client. We also need to add the APIMappingUtil 
>>> logic
>>>(to map API to DTO) as util class inside the same client.
>>>
>>>
>>>- Generate only the DTO classes using publisher REST API swagger and
>>>pack it as a jar in service-stubs. However, even in this case, API to 

Re: [Architecture] [APIM] [3.0] Store REST API for comments

[Ishara Cooray]

Should we allow users to comment on APIs which belong to different tenants?
If not we can remove  '#/parameters/requestedTenant' from POST operation.
IMO this is not required as if we need to comment on an api we need to
login to the particular tenant.
Hence +1 to remove  '#/parameters/requestedTenant' from POST operation.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Thu, Aug 15, 2019 at 5:45 AM Ishara Cooray  wrote:

> Hi,
>
>   username:
>>> type: string
>>> description: |
>>>   If username is not given user invoking the API will be taken as 
>>> the username.
>>>
>>> Regarding the description: I guess we should omit it when posting a
> comment and always use the logged-in user?
>  +1
>
>>   content:
>>> type: string
>>>   createdTime:
>>> type: string
>>> example: 2017-02-20T13:57:16.229
>>>   createdBy:
>>> type: string
>>>
>>> I guess we don't need two properties: createdBy and username?
> Are we allowing admin or the provider to edit the comment?
> If so it make sense to have both username and createdBy.
>
> @Kavishka Fernando 
> Let's add operationId to the definition as a convention.
>
> Thanks & Regards,
> Ishara Cooray
> Associate Technical Lead
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
>
> On Tue, Aug 13, 2019 at 7:19 PM Malintha Amarasinghe 
> wrote:
>
>>
>>
>> On Tue, Aug 13, 2019 at 6:06 PM Thilini Shanika 
>> wrote:
>>
>>> Shouldn't we add error handling for unauthorized/forbidden API(Role
>>> restricted) comment retrievals/deletions
>>>
>> +1
>>
>>
>> Also please find a couple of inline comments:
>>
>>>
>>> On Tue, Aug 13, 2019 at 5:10 PM Kavishka Fernando 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> We are planning on creating the comments feature for the Store in APIM
>>>> 3.0 similar to the comments feature and outlook available in APIM-2.6.0.
>>>>
>>>> I am currently in the process of creating the REST API for the comments
>>>> feature.
>>>> Shown below is the swagger related to the resource,
>>>>
>>>> ##
>>>> # The "Comments Collection" resource API
>>>> ##
>>>>   '/apis/{apiId}/comments':
>>>> #-
>>>> # Retrieve a list of all comments of a certain API
>>>> #-
>>>> get:
>>>>   summary: Retrieve API comments
>>>>   security:
>>>> - OAuth2Security: []
>>>>   description: |
>>>> Get a list of Comments that are already added to APIs
>>>>   parameters:
>>>> - $ref: '#/parameters/apiId'
>>>> - $ref: '#/parameters/limit'
>>>> - $ref: '#/parameters/offset'
>>>>
>>>> We will need to add #/parameters/requestedTenant to retrieve comments
>> of APIs which are in other tenant domains than the user's tenant.
>>
>>>   tags:
>>>> - Comments
>>>>   responses:
>>>> 200:
>>>>   description: |
>>>> OK.
>>>> Comments list is returned.
>>>>   schema:
>>>> $ref: '#/definitions/CommentList'
>>>> 406:
>>>>   description: |
>>>> Not Acceptable. The requested media type is not supported
>>>>   schema:
>>>> $ref: '#/definitions/Error'
>>>>
>>>> #-
>>>> # Add a new Comment
>>>> #-
>>>> post:
>>>>   summary: Add an API comment
>>>>   security:
>>>> - OAuth2Security:
>>>>   - apim:subscribe
>>>>   x-scope: apim:subscribe
>>>>   parameters:
>>>> - $ref: '#/parameters/apiId'
>>>> - $ref: '#/parameters/requestedTenant'
>>>>
>>>> Should we allow u

Re: [Architecture] [APIM] [3.0] Store REST API for comments

[Ishara Cooray]

Hi,

  username:
>> type: string
>> description: |
>>   If username is not given user invoking the API will be taken as 
>> the username.
>>
>> Regarding the description: I guess we should omit it when posting a
comment and always use the logged-in user?
 +1

>   content:
>> type: string
>>   createdTime:
>> type: string
>> example: 2017-02-20T13:57:16.229
>>   createdBy:
>> type: string
>>
>> I guess we don't need two properties: createdBy and username?
Are we allowing admin or the provider to edit the comment?
If so it make sense to have both username and createdBy.

@Kavishka Fernando 
Let's add operationId to the definition as a convention.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Tue, Aug 13, 2019 at 7:19 PM Malintha Amarasinghe 
wrote:

>
>
> On Tue, Aug 13, 2019 at 6:06 PM Thilini Shanika  wrote:
>
>> Shouldn't we add error handling for unauthorized/forbidden API(Role
>> restricted) comment retrievals/deletions
>>
> +1
>
>
> Also please find a couple of inline comments:
>
>>
>> On Tue, Aug 13, 2019 at 5:10 PM Kavishka Fernando 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are planning on creating the comments feature for the Store in APIM
>>> 3.0 similar to the comments feature and outlook available in APIM-2.6.0.
>>>
>>> I am currently in the process of creating the REST API for the comments
>>> feature.
>>> Shown below is the swagger related to the resource,
>>>
>>> ##
>>> # The "Comments Collection" resource API
>>> ##
>>>   '/apis/{apiId}/comments':
>>> #-
>>> # Retrieve a list of all comments of a certain API
>>> #-
>>> get:
>>>   summary: Retrieve API comments
>>>   security:
>>> - OAuth2Security: []
>>>   description: |
>>> Get a list of Comments that are already added to APIs
>>>   parameters:
>>> - $ref: '#/parameters/apiId'
>>> - $ref: '#/parameters/limit'
>>> - $ref: '#/parameters/offset'
>>>
>>> We will need to add #/parameters/requestedTenant to retrieve comments
> of APIs which are in other tenant domains than the user's tenant.
>
>>   tags:
>>> - Comments
>>>   responses:
>>> 200:
>>>   description: |
>>> OK.
>>> Comments list is returned.
>>>   schema:
>>> $ref: '#/definitions/CommentList'
>>> 406:
>>>   description: |
>>> Not Acceptable. The requested media type is not supported
>>>   schema:
>>> $ref: '#/definitions/Error'
>>>
>>> #-
>>> # Add a new Comment
>>> #-
>>> post:
>>>   summary: Add an API comment
>>>   security:
>>> - OAuth2Security:
>>>   - apim:subscribe
>>>   x-scope: apim:subscribe
>>>   parameters:
>>> - $ref: '#/parameters/apiId'
>>> - $ref: '#/parameters/requestedTenant'
>>>
>>> Should we allow users to comment on APIs which belong to different
> tenants? If not we can remove  '#/parameters/requestedTenant' from POST
> operation.
>
>
>> - in: body
>>>   name: body
>>>   description: |
>>> Comment object that should to be added
>>>   required: true
>>>   schema:
>>> $ref: '#/definitions/Comment'
>>>   tags:
>>> - Comments
>>>   responses:
>>> 201:
>>>   description: |
>>> Created.
>>> Successful response with the newly created object as entity in 
>>> the body.
>>> Location header contains URL of newly created entity.
>>>   schema:
>>> $ref: '#/definitions/Comment'
>>>   headers:
>>>

[Architecture] [APIM 3.0.0] Publisher REST APIs for mediation policies

[Ishara Cooray]

alse
  - in: formData
name: type
description: Type of the mediation sequence(in/out/fault)
required: true
type: string
  - $ref: '#/parameters/apiId'
  - $ref: '#/parameters/mediationPolicyId'
  - $ref: '#/parameters/If-Match'
tags:
  - Mediation Policy of an API
responses:
  200:
description: |
  OK.
  Successful response with updated API object
schema:
  $ref: '#/definitions/Mediation'
headers:
  Location:
description: |
  The URL of the newly created resource.
type: string
  Content-Type:
description: |
  The content type of the body.
type: string
  ETag:
description: |
  Entity Tag of the response resource. Used by caches, or
in conditional requests (Will be supported in future).
type: string
  Last-Modified:
description: |
  Date and time the resource has been modifed the last time.
  Used by caches, or in conditional requests (Will be
supported in future).
type: string
  400:
description: |
  Bad Request.
  Invalid request or validation error
schema:
  $ref: '#/definitions/Error'
  403:
description: |
  Forbidden.
  The request must be conditional but no condition has been specified.
schema:
  $ref: '#/definitions/Error'
  404:
description: |
  Not Found.
  The resource to be updated does not exist.
schema:
  $ref: '#/definitions/Error'
  412:
description: |
  Precondition Failed.
  The request has not been performed because one of the
preconditions is not met.
schema:
  $ref: '#/definitions/Error'
###
# The "Individual API specific mediation sequence content" resource
###
/apis/{apiId}/mediation-policies/{mediationPolicyId}/content:

  #---
  # Retrieve a particular API specific mediation sequence content
  #---
  get:
security:
- OAuth2Security:
  - apim:api_view
x-examples:
  $ref: docs/examples/apis/apis_id_mediationpolicies_id_content_get.yaml
summary: Downloadt an API specific mediation policy
operationid:  apisApiIdMediationPoliciesMediationPolicyIdContentGet
description: |
  This operation can be used to download a particular API specific
mediation policy.
parameters:
- $ref: '#/parameters/apiId'
- $ref: '#/parameters/mediationPolicyId'
- $ref: '#/parameters/If-None-Match'
tags:
- Mediation Policy content of an API
responses:
  200:
description: |
  OK.
  Mediation policy returned.
headers:
  Content-Type:
description: |
  The content type of the body.
type: string
  ETag:
description: |
  Entity Tag of the response resource.
  Used by caches, or in conditional requests (Will be
supported in future).
type: string
  Last-Modified:
description: |
  Date and time the resource has been modifed the last time.
  Used by caches, or in conditional requests (Will be
supported in future).
type: string
  304:
description: |
  Not Modified.
  Empty body because the client has already the latest version
of the requested resource (Will be supported in future).
  404:
description: |
  Not Found.
  Requested file does not exist.
    schema:
  $ref: '#/definitions/Error'


Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi,

On Mon, Feb 25, 2019 at 3:41 PM Ishara Cooray  wrote:

>
> *Hi,*
>
> *micro-gw set-project *
> I think setting the project name we can do within the *micro-gw setup*
> command itself rather having another command.
> *micro-gw setup  -a  -oa  -e
> *
>

Yes, we can do that in this case. But if you want to switch between
different projects, we can't use the setup command again and again. The
setup command will work with the command -f. I don't think we can ask the
user to use -f for switching between projects.
Hence, we would need another command to set the project.

Make sense..
Having s separate command would be good in that case. However if *micro-gw
setup command also able to do that, then set-project command will have to
use only if needed.*
*I think switching between projects may not be a frequent task.*


> Can we have API_name different from the title in the swagger file?
> I think if a different name is provided in the command, precedence will be
> given to that API_name.
>

API Name or any other configs can be specified in the meta-data file. And
that file get the precedence over the swagger.
 Bit confused. Are there 3 different places that we can provide the
API_name?
If we give the option to provide API_name(or some parameter) regardless of
it is optional or mandatory, we will have to clearly define which one is
eventually be used in the underline logic.
Could you please clarify?


> Current Micro gateway is immutable so that if we want to update an api, we
> will need to re-create the container/instance.
> When we support multiple apis how are we going to handle this?
> In that case i think we may need to have *micro-gw add-api *support for
> bulk of apis.
>

In the microgateway approach there won't be many APIs and micro-gw add-api
support should be able to handle.

What is the expected max no of APIs per project?
I think we can simply have a command that accepts APIs data as a file to
cater this?

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Mon, Feb 25, 2019 at 4:03 PM Pubudu Gunatilaka  wrote:

> Hi,
>
> On Mon, Feb 25, 2019 at 3:41 PM Ishara Cooray  wrote:
>
>>
>> *Hi,*
>>
>> *micro-gw set-project *
>> I think setting the project name we can do within the *micro-gw setup*
>> command itself rather having another command.
>> *micro-gw setup  -a  -oa 
>> -e *
>>
>
> Yes, we can do that in this case. But if you want to switch between
> different projects, we can't use the setup command again and again. The
> setup command will work with the command -f. I don't think we can ask the
> user to use -f for switching between projects.
>
> Hence, we would need another command to set the project.
>
>>
>> Can we have API_name different from the title in the swagger file?
>> I think if a different name is provided in the command, precedence will
>> be given to that API_name.
>>
>
> API Name or any other configs can be specified in the meta-data file. And
> that file get the precedence over the swagger.
>
>
>>
>> Current Micro gateway is immutable so that if we want to update an api,
>> we will need to re-create the container/instance.
>> When we support multiple apis how are we going to handle this?
>> In that case i think we may need to have *micro-gw add-api *support for
>> bulk of apis.
>>
>
> In the microgateway approach there won't be many APIs and micro-gw add-api
> support should be able to handle.
>
> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Associate Technical Lead
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

*Hi,*

*micro-gw set-project *
I think setting the project name we can do within the *micro-gw setup*
command itself rather having another command.
*micro-gw setup  -a  -oa  -e
*

Can we have API_name different from the title in the swagger file?
I think if a different name is provided in the command, precedence will be
given to that API_name.

Current Micro gateway is immutable so that if we want to update an api, we
will need to re-create the container/instance.
When we support multiple apis how are we going to handle this?
In that case i think we may need to have *micro-gw add-api *support for
bulk of apis.

wdyt?

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Mon, Feb 25, 2019 at 10:15 AM Nuwan Dias  wrote:

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

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

[Ishara Cooray]

Hi Chamindu,
Couple of questions came to my mind is

1. What will be the case if both headers are provided? Are we doing both
validations?
2. Do we have a expiry time for this cookie.
3.In the case of invalid cookie how can one obtain a new valid cookie?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


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

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

Re: [Architecture] If I have 2 Apis, one can be connected to the IS and the other no ?

[Ishara Cooray]

Hi Nicolas,

If I understand correctly, you have two apis and  need to authenticate one
but not the other(need to access second api without an access token)?
If so you can use Auth Type as none for the second api.

Please refer [1].

[1] https://wso2.com/blogs/cloud/disabling-oauth-in-api-cloud/

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Thu, Oct 18, 2018 at 2:13 PM Nicolas Maujean <
nicolas.maujean.fra...@gmail.com> wrote:

> Hi,
>
>If I have 2 Apis, one can be connected to the IS and the other no ?
>
>if yes, how I can do it ?
>
> best regards,
>
> Nicolas Maujean
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

The CREATED_BY and UPDATED_BY columns are ones we add to all tables for
audit purposes. We don't associate them with any business logic nor do we
reason out any logic for having or not having those columns.
Thanks Nuwan, for the clarification.
But I think it's redundant if UPDATED_BY column has the same info as
CREATED_BY. However this will be useful if we allow to update a comment to
a person other than the owner.

Also interested in knowing who will get the right to edit/delete comments.
Is the comment owner only? Or provider has the right to edit/delete a
particular comment in case of irrelevant or misleading comments?
Sorry if this has been discussed already in the review which I missed.

Thanks & Regards,
Ishara Cooray

On Tue, Oct 2, 2018 at 10:22 AM Nuwan Dias  wrote:

> The CREATED_BY and UPDATED_BY columns are ones we add to all tables for
> audit purposes. We don't associate them with any business logic nor do we
> reason out any logic for having or not having those columns.
>
> On Tue, Oct 2, 2018 at 10:02 AM Wasura Wattearachchi 
> wrote:
>
>> Hi Ishara,
>>
>> Thank you for pointing this out.
>>
>> On Tue, Oct 2, 2018 at 5:42 AM Ishara Cooray  wrote:
>>
>>> Hi Wasura,
>>>
>>> I think PARENT_COMMENT_ID should have a default value because first
>>> comment does not have a associated parent comment.
>>>
>>> When we are inserting a parent comment it will not have a
>> PARENT_COMMENT_ID. So this may throw an error due to violation of
>> Referential Integrity Constraint. So I thought not to have any constraint
>> for PARENT_COMMENT_ID and we discussed this yesterday during the code
>> review.
>>
>>
>>> Since there are two fields CREATED_BY and UPDATED_BY I guess comments
>>> can be updated(edit/delete) by someone other than the owner.
>>>
>>
>> +1 for this. I must handle this in the logic when updating a comment. I
>> will look into this matter.
>>
>>> Appreciate if you clarify the expected behavior.
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>>
>>
>> Thank you!
>>
>>>
>>> On Mon, Oct 1, 2018 at 10:54 PM Wasura Wattearachchi 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> According to what we have discussed today during the code review, I
>>>> added a new attribute named ENTRY_POINT to distinguish the role of the
>>>> person, based on the entry point - whether the particular person initiates
>>>> the comment from the API Store or the API Publisher. Following is the ERD
>>>> for that (You can find the newly added attribute in green colour).
>>>>
>>>>
>>>>
>>>>
>>>> Following is the corresponding *table* and the data types.
>>>>
>>>>
>>>> AM_API_COMMENTS
>>>>
>>>> UUID
>>>>
>>>> VARCHAR(255)
>>>>
>>>> PRIMARY KEY
>>>>
>>>> COMMENT_TEXT
>>>>
>>>> TEXT
>>>>
>>>> USER_IDENTIFIER
>>>>
>>>> VARCHAR(255)
>>>>
>>>> CATEGORY
>>>>
>>>> VARCHAR(20)
>>>>
>>>> DEFAULT ‘General’
>>>>
>>>> PARENT_COMMENT_ID
>>>>
>>>> VARCHAR(255)
>>>>
>>>> ENTRY_POINT
>>>>
>>>> VARCHAR(20)
>>>>
>>>> API_ID
>>>>
>>>> VARCHAR(255)
>>>>
>>>> FOREIGN KEY REFERENCES AM_API (UUID) ON DELETE CASCADE ON UPDATE CASCADE
>>>>
>>>> CREATED_BY
>>>>
>>>> VARCHAR(100)
>>>>
>>>> CREATED_TIME
>>>>
>>>> TIMESTAMP
>>>>
>>>> DEFAULT CURRENT_TIMESTAMP
>>>>
>>>> UPDATED_BY
>>>>
>>>> VARCHAR(100)
>>>>
>>>> UPDATED_TIME
>>>>
>>>> TIMESTAMP
>>>>
>>>> DEFAULT CURRENT_TIMESTAMP
>>>>
>>>>
>>>> I would much appreciate if you can provide feedback and suggestions.
>>>>
>>>>
>>>> Thank you!
>>>>
>>>>
>>>> On Wed, Sep 19, 2018 at 10:24 AM Ishara Cooray 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for the clarification Wasura.
>>>>>
>>>>> In C5 we have used *USER_IDENTIFIER* in below APIM tables.
>>>>> AM_USER_NAME_MAPPING

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

[Ishara Cooray]

Hi Wasura,

I think PARENT_COMMENT_ID should have a default value because first comment
does not have a associated parent comment.

Since there are two fields CREATED_BY and UPDATED_BY I guess comments can
be updated(edit/delete) by someone other than the owner.
Appreciate if you clarify the expected behavior.


Thanks & Regards,
Ishara Cooray

On Mon, Oct 1, 2018 at 10:54 PM Wasura Wattearachchi 
wrote:

> Hi all,
>
> According to what we have discussed today during the code review, I added
> a new attribute named ENTRY_POINT to distinguish the role of the person,
> based on the entry point - whether the particular person initiates the
> comment from the API Store or the API Publisher. Following is the ERD for
> that (You can find the newly added attribute in green colour).
>
>
>
>
> Following is the corresponding *table* and the data types.
>
>
> AM_API_COMMENTS
>
> UUID
>
> VARCHAR(255)
>
> PRIMARY KEY
>
> COMMENT_TEXT
>
> TEXT
>
> USER_IDENTIFIER
>
> VARCHAR(255)
>
> CATEGORY
>
> VARCHAR(20)
>
> DEFAULT ‘General’
>
> PARENT_COMMENT_ID
>
> VARCHAR(255)
>
> ENTRY_POINT
>
> VARCHAR(20)
>
> API_ID
>
> VARCHAR(255)
>
> FOREIGN KEY REFERENCES AM_API (UUID) ON DELETE CASCADE ON UPDATE CASCADE
>
> CREATED_BY
>
> VARCHAR(100)
>
> CREATED_TIME
>
> TIMESTAMP
>
> DEFAULT CURRENT_TIMESTAMP
>
> UPDATED_BY
>
> VARCHAR(100)
>
> UPDATED_TIME
>
> TIMESTAMP
>
> DEFAULT CURRENT_TIMESTAMP
>
>
> I would much appreciate if you can provide feedback and suggestions.
>
>
> Thank you!
>
>
> On Wed, Sep 19, 2018 at 10:24 AM Ishara Cooray  wrote:
>
>> Hi,
>>
>> Thanks for the clarification Wasura.
>>
>> In C5 we have used *USER_IDENTIFIER* in below APIM tables.
>> AM_USER_NAME_MAPPING
>> AM_API_RATINGS
>> AM_API_COMMENTS
>>
>> But in C5 UM tables we still have used *USER_ID*.
>>
>> AUTH_UM_PASSWORD_INFO
>> AUTH_UM_USER_GROUP
>> AUTH_UM_USER_ATTRIBUTES
>>
>> Is there any particular reason for that?
>>
>> I am +1 to use USER_ID in apim tables as well.
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Tue, Sep 18, 2018 at 9:17 PM, Wasura Wattearachchi 
>> wrote:
>>
>>> Hi Ishara,
>>>
>>> I agree with you. It is better to have USER_ID rather than
>>> USER_IDENTIFIER. But there is a problem. I checked all the tables in
>>> the database again and found that there are some tables which have
>>> USER_IDENTIFIER column (which is used to symbolize the username of the
>>> current user like in AM_API_COMMENTS table).
>>> So if I change the USER_IDENTIFIER field to USER_ID in my table
>>> (AM_API_COMMENTS) then the consistency of the database will be lost,
>>> because other tables have it as USER_IDENTIFIER while AM_API_COMMENTS has
>>> it as USER_ID.
>>>
>>> So I think it is better to keep it this way as USER_IDENTIFIER without
>>> doing any changes. What are the ideas of others?
>>>
>>> Thanks!
>>>
>>> On Tue, Sep 18, 2018 at 5:47 AM Ishara Cooray  wrote:
>>>
>>>> Hi Wasura,
>>>> We can simplify USER_IDENTIFIER field as USER_ID
>>>>
>>>> And also I think we need to categorize comments as "Bug", "Feature
>>>> Request" or "General". By default it should be "General.
>>>>
>>>> What is the way that we identify the category of a particular comment?
>>>>
>>>
>>>
>>> --
>>> Wasura Wattearachchi
>>> Software Engineer Intern | WSO2
>>>
>>> Email: was...@wso2.com 
>>> Mobile: +94775396038
>>>
>>
>>
>
> --
> Wasura Wattearachchi
> Software Engineer Intern | WSO2
>
> Email: was...@wso2.com 
> Mobile: +94775396038
> <http://wso2.com/signature>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi,

Thanks for the clarification Wasura.

In C5 we have used *USER_IDENTIFIER* in below APIM tables.
AM_USER_NAME_MAPPING
AM_API_RATINGS
AM_API_COMMENTS

But in C5 UM tables we still have used *USER_ID*.

AUTH_UM_PASSWORD_INFO
AUTH_UM_USER_GROUP
AUTH_UM_USER_ATTRIBUTES

Is there any particular reason for that?

I am +1 to use USER_ID in apim tables as well.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Sep 18, 2018 at 9:17 PM, Wasura Wattearachchi 
wrote:

> Hi Ishara,
>
> I agree with you. It is better to have USER_ID rather than
> USER_IDENTIFIER. But there is a problem. I checked all the tables in the
> database again and found that there are some tables which have
> USER_IDENTIFIER column (which is used to symbolize the username of the
> current user like in AM_API_COMMENTS table).
> So if I change the USER_IDENTIFIER field to USER_ID in my table
> (AM_API_COMMENTS) then the consistency of the database will be lost,
> because other tables have it as USER_IDENTIFIER while AM_API_COMMENTS has
> it as USER_ID.
>
> So I think it is better to keep it this way as USER_IDENTIFIER without
> doing any changes. What are the ideas of others?
>
> Thanks!
>
> On Tue, Sep 18, 2018 at 5:47 AM Ishara Cooray  wrote:
>
>> Hi Wasura,
>> We can simplify USER_IDENTIFIER field as USER_ID
>>
>> And also I think we need to categorize comments as "Bug", "Feature
>> Request" or "General". By default it should be "General.
>>
>> What is the way that we identify the category of a particular comment?
>>
>
>
> --
> Wasura Wattearachchi
> Software Engineer Intern | WSO2
>
> Email: was...@wso2.com 
> Mobile: +94775396038
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi,

Also tested 'Enabling Role-Based Access Control Using XACML' and no issues
found.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Sep 17, 2018 at 2:47 PM, Mushthaq Rumy  wrote:

> Hi All,
>
> I have tested the following scenarios.
>
> - Basic API creation flow with the creator role.
> - Publishing an API with publisher role.
> - User sign-up.
> - Password recovery with super tenant and other tenants.
>
> No blockers found. Hence [+] Stable - go ahead and release.
>
> Thanks & Regards,
> Mushthaq
>
> On Mon, Sep 17, 2018 at 1:43 PM Bhathiya Jayasekara 
> wrote:
>
>> Hi,
>>
>> I tested the following areas and no blockers were found.
>>
>> - Semi manual client registration
>> - Grant types
>> - Scopes
>> - GDPR
>>
>> Hence, +1 for the release.
>>
>> Thanks,
>> Bhathiya
>>
>>
>>
>>
>> On Mon, Sep 17, 2018 at 12:42 PM Praminda Jayawardana 
>> wrote:
>>
>>> Hi,
>>>
>>> Tested below scenarios,
>>>
>>> 1. Basic API creation and publishing with roles.
>>> 2. Micro gateway with labels
>>> 3. Micro gateway stat publishing
>>> 4. Micro gateway throttling with both oauth and jwt tokens
>>> 5. Dynamic SSL certificates
>>>
>>>
>>> [+] Stable - go ahead and release
>>>
>>> Thanks,
>>> Praminda
>>>
>>> On Mon, Sep 17, 2018 at 11:50 AM Pubudu Gunatilaka 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Tested the following scenarios.
>>>>
>>>> - JWT generation in API Manager
>>>> - API Micorgateway generation using a Swagger Imported API
>>>> - API Microgateway API invocation with a JWT and without a subscription
>>>> (JWT validation only)
>>>> - API Microgateway run on VM/Docker
>>>>
>>>> [+] Stable - go ahead and release.
>>>>
>>>> Thank you!
>>>>
>>>> On Mon, Sep 17, 2018 at 11:26 AM Ishara Cooray 
>>>> wrote:
>>>>
>>>>> Tested the following.
>>>>>
>>>>> Store REST API
>>>>> External Stores
>>>>> Store tag listing and tagwiseMode
>>>>>
>>>>> [+] Stable - go ahead and release
>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>>>
>>>>>> ___
>>>>> Dev mailing list
>>>>> d...@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>
>>>>
>>>> --
>>>> *Pubudu Gunatilaka*
>>>> Committer and PMC Member - Apache Stratos
>>>> Senior Software Engineer
>>>> WSO2, Inc.: http://wso2.com
>>>> mobile : +94774078049 <%2B94772207163>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>>
>>> *Praminda Jayawardana*
>>> Senior Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> Mobile : +94 (0) 716 590918
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> *Bhathiya Jayasekara*
>> *Technical Lead,*
>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>
>> *Phone: +94715478185*
>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>> <http://www.linkedin.com/in/bhathiyaj>*
>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
>> *Blog: http://movingaheadblog.blogspot.com
>> <http://movingaheadblog.blogspot.com/>*
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Mushthaq Rumy
> *Senior Software Engineer*
> Mobile : +94 (0) 779 492140
> Email : musht...@wso2.com
> WSO2, Inc.; http://wso2.com/
> lean . enterprise . middleware.
>
> <http://wso2.com/signature>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Tested the following.

Store REST API
External Stores
Store tag listing and tagwiseMode

[+] Stable - go ahead and release


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

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

Re: [Architecture] [AM] Securing APIs using Mutal SSL

[Ishara Cooray]

On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray  wrote:

> Hi Megala,
>
> In current authentication handler we set some API Parameters to
> MessageContext such as
> CONTEXT, API_VERSION, API, VERSION, RESOURCE, HTTP_METHOD, HOST_NAME,
> API_PUBLISHER, etc.
> We will need to do the same with the mutual ssl as well.
>
> To subscribe to an api currently we should have an oath application to be 
> used. So in this case even if we do not have any token involved I think still 
> we need let users to subscribe to the api.
>
> May be then we can store required subscription related information for a 
> given api.
>
> Even if we store the subscription details with the API, when a particular
API is invoked how we know that this particular API invocation is related
with this particular subscription, given that we do not have token involved
with the request? AFAIU even if store it with the API, we will not be able
to use them for subscription throttling. Please do correct me if I have
misunderstood something regarding this

Your understanding is correct indeed.
However, for authorization we may be converting the client SSL certificate
into an auth context.
Please refer [1].

1. Client invoke an API by establishing a two way SSL session
> 2. Gateway validates the client SSL certificate and translates it into an
> auth context using the information from the subject distinguished name (DN).
> 3. Gateway performs authorization by matching the auth context against
> the target resource
>
wdyt?

[1] https://blueprints.launchpad.net/keystone/+spec/client-ssl-certificate-
authorization


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Sep 12, 2018 at 4:16 PM, Rajith Roshan  wrote:

>
>
> On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar 
> wrote:
>
>> Hi Rajith,
>>
>> Thanks for the response.
>> On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan  wrote:
>>
>>> Hi Megala,
>>> On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am currently working on $subject for APIM 2.x. Currently all the APIs
>>>> are protected with oauth2 token, with this feature, the API
>>>> creators/publishers will be given the flexibility to select different
>>>> options to secure their APIs (i.e. Options can be oauth2, mutal ssl or
>>>> both). Userstory for this feature can be found at [1]
>>>>
>>>> *Option 1  - oauth2*
>>>> This will follow the same old flow when invoking the API.
>>>>
>>>> *Option 2 - Mutual SSL*
>>>> If this option is selected, the authentication will be handled in the
>>>> transport level and in the handler level, we do not need to do the
>>>> authentication explicitily.
>>>>
>>>> *Option 3 - oauth2 and mutal SSL*
>>>> The authentication will be handled in transport level as well as in
>>>> handler level.
>>>>
>>>> In the above options, option 2 has some unclear areas that need to be
>>>> sorted out.
>>>>
>>>> *How to handle the scope validation*
>>>> Authentication will be handled with the client certificates, however
>>>> for scope handling we need role/scope information(i.e. authorization
>>>> information). As per specification[2], it seems attribute certificate is
>>>> used for this purpose, which incudes the authorization information. However
>>>> it seems it seems there seems to be no proper support for such certificate
>>>> as of [3]. In that case, we may need to get the scope information from the
>>>> public certificate, may be we could use certificate extension for that
>>>> purpose, however seems we do not have a standard extension for the relevant
>>>> purpose.
>>>>
>>> AFAIK there is no standard certificate extension to save scope values,
>>> If we use wso2 proprietary certificate extension attribute , then users
>>> with valid CA signed  x509 certificate won't be able to access the APIs. Or
>>> if use proprietary attribute for scopes users will have to generate
>>> certificates with those extension attributes.
>>>
>> Agree on those points. I was thinking of giving the flexibility to API
>> creator to decide on what is the certificate extension attribute, we need
>> to get the scope from, may be we can have a optional attibute in API level.
>> If the API creator does not want the APIs to checked against scopes, they
>> can simply leave the field 

Re: [Architecture] [AM] Securing APIs using Mutal SSL

[Ishara Cooray]

Hi Megala,

In current authentication handler we set some API Parameters to
MessageContext such as
CONTEXT, API_VERSION, API, VERSION, RESOURCE, HTTP_METHOD, HOST_NAME,
API_PUBLISHER, etc.
We will need to do the same with the mutual ssl as well.

To subscribe to an api currently we should have an oath application to
be used. So in this case even if we do not have any token involved I
think still we need let users to subscribe to the api.

May be then we can store required subscription related information for
a given api.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Sep 12, 2018 at 9:05 AM, Megala Uthayakumar  wrote:

> Hi Rajith,
>
> Thanks for the response.
> On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan  wrote:
>
>> Hi Megala,
>> On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar 
>> wrote:
>>
>>> Hi All,
>>>
>>> I am currently working on $subject for APIM 2.x. Currently all the APIs
>>> are protected with oauth2 token, with this feature, the API
>>> creators/publishers will be given the flexibility to select different
>>> options to secure their APIs (i.e. Options can be oauth2, mutal ssl or
>>> both). Userstory for this feature can be found at [1]
>>>
>>> *Option 1  - oauth2*
>>> This will follow the same old flow when invoking the API.
>>>
>>> *Option 2 - Mutual SSL*
>>> If this option is selected, the authentication will be handled in the
>>> transport level and in the handler level, we do not need to do the
>>> authentication explicitily.
>>>
>>> *Option 3 - oauth2 and mutal SSL*
>>> The authentication will be handled in transport level as well as in
>>> handler level.
>>>
>>> In the above options, option 2 has some unclear areas that need to be
>>> sorted out.
>>>
>>> *How to handle the scope validation*
>>> Authentication will be handled with the client certificates, however for
>>> scope handling we need role/scope information(i.e. authorization
>>> information). As per specification[2], it seems attribute certificate is
>>> used for this purpose, which incudes the authorization information. However
>>> it seems it seems there seems to be no proper support for such certificate
>>> as of [3]. In that case, we may need to get the scope information from the
>>> public certificate, may be we could use certificate extension for that
>>> purpose, however seems we do not have a standard extension for the relevant
>>> purpose.
>>>
>> AFAIK there is no standard certificate extension to save scope values, If
>> we use wso2 proprietary certificate extension attribute , then users with
>> valid CA signed  x509 certificate won't be able to access the APIs. Or if
>> use proprietary attribute for scopes users will have to generate
>> certificates with those extension attributes.
>>
> Agree on those points. I was thinking of giving the flexibility to API
> creator to decide on what is the certificate extension attribute, we need
> to get the scope from, may be we can have a optional attibute in API level.
> If the API creator does not want the APIs to checked against scopes, they
> can simply leave the field empty. WDYT?
>
>
>>
>>> *How to support client certificates upload*
>>> When we support mutual SSL, we may need to provide the way to upload the
>>> client certificates. For this we can make use of the same way we have used
>>> for dynamic ssl certification handling for backend. Similar to sender,
>>> dynamic ssl certification is supported for listeners as well. Hence we
>>> could use the similar implementation to support this usecase.
>>>
>>> *Application subscription and related functionalities and a**nalytics
>>> related functionalities*
>>> We retrieve the subscription information from the authenticated token.
>>> Since we do not have any token's involved, subscription and related
>>> functionalities will not work.
>>> Analytics related functionalities need to be verified as well in the
>>> same flow.
>>>
>> In mutual ssl flow we will have  to skip the subscription validation,
>> since there is no valid subscription. Subscription related analytics and
>> throttling should also be skipped.
>>
>>>
>>> *Modification Store API Console*
>>> With this feature, we may need to consider the modifications that need
>>> to be done to swagger API console in store to support calling APIs with
>>> 

Re: [Architecture] no access to service

[Ishara Cooray]

Hi Nicolas,

What is the service that you need to restrict access?
Hope you are using API Manager and Identity Server (IS as a Key Manager)

Could you please elaborate your usecase?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Sep 12, 2018 at 2:31 AM, Nicolas Maujean <
nicolas.maujean.fra...@gmail.com> wrote:

> hi,
>
>   I would like to know if it is possible to don't give access to service
> from outside, if yes how we can do it ?
>
> best regards,
>
> Nicolas Maujean
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

+1 to make password-rest as the base path if we are not going to have any
other apis other than password reset.

since clicking on the url in the e-mail is something that is confirming the
password reset action I would suggest to change the endpoint as *confirm  *than
notify

/initiate
> /confirm   -  endpoint gets called when user clicks on the link, validates
> the confirmation key
> /
>

Hope we can use the same password-reset api for change password request as
well.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Aug 21, 2018 at 5:43 PM, Sanjeewa Malalgoda 
wrote:

>
>
> On Tue, Aug 21, 2018 at 5:31 PM Vithursa Mahendrarajah 
> wrote:
>
>> Hi all,
>>
>> As per suggestions, I will work on reset password feature. Proposed flow
>> of implementation for this feature is as follows:
>>
>> [image: first_reset.png]  [image: second_reset.png]
>>
>> We need following APIs to handle reset password request:
>> /password-reset-initiate  - generates a confirmation key
>> /password-reset-notify   -  endpoint gets called when user clicks on the
>> link, validates the confirmation key
>> /password-reset - end point to reset password, ultimately
>> calls SCIM API for updating user
>>
> If we consider rest best practices then this URL pattern might need to
> change. password-rest can be a base path and /initiate, /notify etc can be
> operations perform on service.
> Also please see URL patterns of other service providers.
>
> Thanks,
> sanjeewa.
>
>>
>> Password-reset-initiate and password-reset endpoints are associated with
>> client_credentials grant types. We can add separate scopes to these
>> resources to enhance security.
>> Here, do we need to have dedicated end-point that can be used to reset
>> password for users in API store or can we have a common end-point that is
>> used to reset password like we had in IS.
>>
>> Please provide your thoughts and feed back.
>>
>> Thanks,
>> Vithursa
>>
>> On Tue, Aug 21, 2018 at 11:49 AM Thilini Shanika 
>> wrote:
>>
>>> Hi All,
>>>
>>> Are we planning to implement the account locking feature for 3.0.0
>>> release? Since we had this in 2.5/2.2 and this is a feature that we always
>>> suggest to enable in order to eliminate some of the security threats (ie:
>>> Password guessing attacks). If we are going to implement 'forgot password'
>>> feature, its better to consider implementing this as well. WDYT?
>>>
>>> On Tue, Aug 21, 2018 at 4:44 AM, Nuwan Dias  wrote:
>>>
>>>> I don't think we should decide the priority of the feature based on how
>>>> easy it is to implement. The priority should be decided based on its
>>>> importance. To me, someone forgetting a password is far more likely than
>>>> someone wanting to change it. So I would consider 'Forgot Password' as a
>>>> must have feature and 'Change Password' as a good to have one.
>>>>
>>>> The other reason this thread made me think about the 'Forgot Password'
>>>> feature is that if we implement that feature, we can address the change
>>>> password capability through the same feature. We don't have to implement
>>>> two features to address the two use cases. So, two birds with one stone.
>>>> Less code, less bugs and less work.
>>>>
>>>> On Tue, Aug 21, 2018 at 1:34 AM Ishara Cooray  wrote:
>>>>
>>>>> +1 to implement change password feature first as it is simpler than
>>>>> forgot password feature which involves user verification.
>>>>> Also for the forgot password feature we can either send an email with
>>>>> a temporary password or redirect to the change password.
>>>>> Even if we send a temporary password we will need to ask to change the
>>>>> password.
>>>>>
>>>>> Hi Vithursa,
>>>>>
>>>>> I would suggest having another required property call *retypeNewPassword
>>>>> *for new password verification.
>>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> On Mon, Aug 20, 2018 at 5:08 PM, roshan wijesena <
>>>>> roshan86...@gmail.com> wrote:
&

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

[Ishara Cooray]

+1 to implement change password feature first as it is simpler than forgot
password feature which involves user verification.
Also for the forgot password feature we can either send an email with a
temporary password or redirect to the change password.
Even if we send a temporary password we will need to ask to change the
password.

Hi Vithursa,

I would suggest having another required property call *retypeNewPassword *for
new password verification.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Aug 20, 2018 at 5:08 PM, roshan wijesena 
wrote:

> Do we have any send an email to user feature in apim 3 road map ?
>
> On Mon, Aug 20, 2018 at 7:56 PM Sanjeewa Malalgoda 
> wrote:
>
>> Forgot password feature should comes with some sort of user
>> verification(enter security question or send email verification, sms
>> verification etc).
>> That feature need to implement with some extensions as all are not using
>> same verification process.
>> So i think we can first complete this and come back to that feature.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>> On Mon, Aug 20, 2018 at 11:42 AM Mushthaq Rumy  wrote:
>>
>>> +1. I too think that forgot password option is more important and it is
>>> not yet implemented. I would prefer if we start on that first.
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>> On Mon, Aug 20, 2018 at 11:40 AM Nuwan Dias  wrote:
>>>
>>>> Do we have a forgot password option on the Store? I would think that is
>>>> more important for an API Store than a change password functionality.
>>>>
>>>> On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah <
>>>> vithu...@wso2.com> wrote:
>>>>
>>>>> Hi all,
>>>>> I am working on $subject in APIM 3.0.0. Planned flow of implementation
>>>>> is as follows:
>>>>>
>>>>> [image: new_password_mail.png]
>>>>> We have SCIM API [1] for updating user-info. A separate REST API can
>>>>> be implemented to provide the feature to change password by wrapping
>>>>> mentioned SCIM API. The sample resource could be as,
>>>>>
>>>>> PasswordChangeRequest:
>>>>> title: Request for changing password
>>>>> required:
>>>>>   - username
>>>>>   - currentPassword
>>>>>   - newPassword
>>>>> properties:
>>>>>   username:
>>>>> type: string
>>>>>   currentPassword:
>>>>> type: string
>>>>>   newPassword:
>>>>> type: string
>>>>>
>>>>> Please provide your thoughts and feedback on this.
>>>>>
>>>>> Thanks,
>>>>> Vithursa
>>>>> --
>>>>> Vithursa Mahendrarajah
>>>>> Software Engineer
>>>>> WSO2 Inc. - http ://wso2.com
>>>>> Mobile  : +947*66695643*
>>>>>
>>>>>
>>>>> * <http://wso2.com/signature> <http://wso2.com/signature>
>>>>> <http://wso2.com/signature>*
>>>>>
>>>>
>>>>
>>>> --
>>>> Nuwan Dias
>>>>
>>>> Director - WSO2, Inc. http://wso2.com
>>>> email : nuw...@wso2.com
>>>> Phone : +94 777 775 729
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> Mushthaq Rumy
>>> *Senior Software Engineer*
>>> Mobile : +94 (0) 779 492140
>>> Email : musht...@wso2.com
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middleware.
>>>
>>> <http://wso2.com/signature>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94 712933253
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.
>> blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

[Ishara Cooray]

For me, PRODUCT_VERSION column in every table seems to be redundant.
Could you please explain the reason for introducing this column in each
table? Is this for auditing?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Aug 20, 2018 at 4:03 PM, Uvindra Dias Jayasinha 
wrote:

> Small calcification regarding this statement,
>
> For the 3.0.0 release we just need to implement steps *1* and *2* above.
>> Step *3* can be done for all subsequent releases.
>>
>
> I specifically meant the changes to the DB schema when it comes to steps 1
> and 2 . Obviously no migration logic will be needed for 3.0.0 itself
>
> On 20 August 2018 at 15:58, Uvindra Dias Jayasinha 
> wrote:
>
>> In the past the APIM product has relied on an external component such as
>> a migration client for upgrading from a given product version to a higher
>> version.The end user was required to configure the latest product that they
>> are upgrading to against their current data(databases, synapse files,
>> registry) and run the migration client manually to upgrade the product.
>> This can be a cumbersome and error prone process to accomplish for end
>> users, making product version upgrades time consuming.
>>
>> To overcome the above problem on the fly upgrades were proposed where the
>> product code detects if relevant data being accessed needs to be migrated
>> to the latest version and migrates the data when the code is executed when
>> the respective feature is used. Upgrading product data is much easier from
>> 3.0.0 onwards because all data related to the product is stored in a
>> central database.This means that the end user does not need to get involved
>> in upgrading, it happens without them even being aware as they use the
>> latest version of the product by pointing it against their current
>> database.This makes for a more pleasant user experience when upgrading,
>> putting the burden of the upgrade to be added by the developer into the
>> functional code itself.
>>
>> The following outlines a design that can be supported from 3.0.0 onwards
>> to outline a uniform way of handling product upgrades. This is inspired by
>> the methodology used by FlywayDB to enable DB migrations[1]  but also
>> taking into account the requirement of being able to run on the fly at
>> runtime(Note: DB schema changes between releases will need to be handled
>> via DB vendor specific scripts prepared by the team to be run by the
>> customer against their DB).
>>
>>
>> *1.* A new table will be added to the schema called
>> PRODUCT_VERSION_AUDIT to track the product version upgrades that take place
>> on a given dataset
>>
>> PRODUCT_VERSION_AUDIT
>> VERSION VARCHAR(5)
>> CREATED_TIME TIMESTAMP(6)
>>
>> If a user begins using APIM version 3.0.0 and then upgrades to version
>> 3.1.0 the table will contain the following values,
>>
>> VERSION CREATED_TIME
>> 3.0.0 2018-11-11 13:23:44
>> 3.1.0 2019-10-14 9:26:22
>>
>> This gives a historical view of the product versions a customer has been
>> using. A new row will be inserted into the table when a given product
>> version is started for the first time.
>>
>>
>>
>> *2*. Each table in the database will have a new column called
>> PRODUCT_VERSION(VARCHAR(5)) added. When a row is inserted for the first
>> time it will populate this column with the current product version being
>> used.
>> For example the AM_API table could have the following entries for a
>> customer using APIM 3.0.0,
>>
>> UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
>> 123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 /abc 3.0.0
>> 00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz 3.0.0
>>
>>
>> Lets assume when upgrading to 3.1.0 the leading '/' character in the
>> context needs to be removed. On the fly migration code will run when a
>> given row is accessed by the DAO layer to remove the '/'. Once the
>> migration of the row is completed the PRODUCT_VERSION column will be
>> updated with the value 3.1.0 to signify that the migration for this row has
>> been completed. The PRODUCT_VERSION column can be validated to check if
>> migration code needs to be executed. So assuming the API abc is accessed
>> first the table will look as follows after migration,
>>
>>
>> UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
>> 123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 abc 3.1.0
>> 00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz

Re: [Architecture] Moving to a user configurable model to set threshold values for APIM analytics instead of percentile values

[Ishara Cooray]

Hi Silmy,

   1.  Let the admins or subcribers set those values in APIM side and
   publish it to SP as a stream. A siddhi app can be written to listen to the
   stream an store it in database
   2.  Let the admins or subscriber set a value at SP dashboard itself
   using a dashboard widget


If we go with option 2 we will need to share the user store with the SP
isn't it?
Is there any other usease/s where we need to share the userstore? If not I
am +1 to option 1 because that will bring all the configurations into a one
single place which is the admin app.

wdyt?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Aug 8, 2018 at 7:07 PM, Silmy Hasan  wrote:

> Hi all,
>
> According to the current implementation of APIM Analytics , we use
> percentile values to find out certain threshold values (eg:- Abnormal
> request count) . Since generating alerts using percentile values creates
> lots of complexity to the users of the alert, it was decided to move
> towards a user configurable system where admins and subscribers can set
> those threshold values directly.
>
> *Note*
>
>- There will not be any default values for those thresholds.
>- The alerts will not be generated to the particualr API or
>application untill the admins or subscribers set a value for those
>thresholds.
>
> Two possible ways could be identified to let the admins and subscribers to
> configure these values,
>
>1.  Let the admins or subcribers set those values in APIM side and
>publish it to SP as a stream. A siddhi app can be written to listen to the
>stream an store it in database
>2.  Let the admins or subscriber set a value at SP dashboard itself
>using a dashboard widget
>
> We are thinking of moving on with the second method since the first one
> creates complexity on the APIM side.
>
> *Proposed solution*
> Creating two custom widgets in SP dashboard to enable the
> admins/subscribers perform CRUD operation on those alert configuration
> tables. There will be two tables namely ApiCreatorAlertConfiguration and
> ApiSubscriberAlertConfiguration.
>
> Please provide your suggestions.
>
> Thanks,
> Silmy
>
>
> --
> Shilmy Hasan
> Associate Software Engineer | WSO2
>
> E-mail :si...@wso2.com
> Phone :0779188653
> web : http://www.wso2.com
>
> [image: https://wso2.com/signature] <https://wso2.com/signature>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Audit logs for token generation.

[Ishara Cooray]

+1 to have a new File Logging appender for the new audit logs as it makes
easier to analyze the logs as well.
But we may need to set additivity property to false in order to avoid
appending these logs to main logger.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Aug 7, 2018 at 9:45 AM, Ruwan Abeykoon  wrote:

> Hi Rushmin,
> +1 for a new logger.
> It should be INFO level. as it is for informational purpose and not debug
> purpose. We can still enable/disable with Log4J config.
>
> Cheers,
> Ruwan
>
> On Tue, Aug 7, 2018 at 9:38 AM Rushmin Fernando  wrote:
>
>> Hi Dulanja,
>>
>> Please see the inline response.
>>
>> On Mon, Aug 6, 2018 at 10:40 PM Dulanja Liyanage 
>> wrote:
>>
>>> IINM the requirement here is to log the token generation event, not resource
>>> access with the generated token. Therefore access log won't be the
>>> correct place. This should be ideally logged in a separate log file, but we
>>> would have to use the audit log file because that's the existing option we
>>> have.
>>>
>>> However, not all customers will require this. This will in fact grow the
>>> audit log rapidly. So this should be configurable.
>>>
>>
>> To solve this we can use a different logger for these new logs and the
>> logs should be in debug level. So the new logs won't be visible in an
>> existing deployment. If a customer needs to see these logs, they just need
>> to configure log4j to enable DEBUG for the new logger and direct the logs
>> to a different file.
>>
>>
>>
>>>
>>> On Mon, Aug 6, 2018 at 3:30 PM, Ruwan Abeykoon  wrote:
>>>
>>>> HI Rushmin,
>>>> It is valid requirement to log the information.
>>>> Access log is the the right place for this kind of logs, as it logs
>>>> who/what accessed the Application with token.
>>>>
>>>> Audit log in contrast logs who did what modification at what resource.
>>>>
>>>> Cheers.
>>>> Ruwan
>>>>
>>>> On Mon, Aug 6, 2018 at 1:36 PM Rushmin Fernando 
>>>> wrote:
>>>>
>>>>> It is a valid requirement for a production deployment to publish/log
>>>>> context data during the operations like OAuth token generation.
>>>>>
>>>>> As of now, we don't log these audio data. One close existing candidate
>>>>> is HTTP access logs. But it doesn't contain any context information like
>>>>> client ID.
>>>>>
>>>>> What we can do is, use an audit logger in relevant classes and start
>>>>> logging the data.
>>>>>
>>>>> Do we have any concerns with this?
>>>>>
>>>>> --
>>>>> *Best Regards*
>>>>>
>>>>> *Rushmin Fernando*
>>>>> *Technical Lead*
>>>>>
>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>>>>
>>>>> mobile : +94775615183
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> *Ruwan Abeykoon*
>>>> *Associate Director/Architect**,*
>>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>>>> *lean.enterprise.middleware.*
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Dulanja Liyanage
>>> Lead, Platform Security Team
>>> WSO2 Inc.
>>>
>>
>>
>> --
>> *Best Regards*
>>
>> *Rushmin Fernando*
>> *Technical Lead*
>>
>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>
>> mobile : +94775615183
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
>
> *Ruwan Abeykoon*
> *Associate Director/Architect**,*
> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
> *lean.enterprise.middleware.*
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM 3.0.0] [Store] Self-sign up and Change password features

[Ishara Cooray]

Yes , As the offline discussion had with Uvindra, We could avoid exploiting
the access token issued for the self-signup scenario by adding captcha +
token revoke mechanism, So they can't reuse the same access token once it
is used for self-signup, and to get new access token anonymous user has to
pass the captcha challenge. But still, other product REST APIs are
vulnerable to DOS attacks since once the user gets an access token by login
through the UI, it can be used to make a DOS attack. So, in general, we
would need to introduce throttling policy for product wide REST APIs.

+1 throttling policy for product wide REST APIs.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Aug 1, 2018 at 11:19 AM, Uvindra Dias Jayasinha 
wrote:

> +1, we need to have default throttling policies for all our REST APIs
>
> On 1 August 2018 at 11:17, Kasun Thennakoon  wrote:
>
>> Hi Ishara,
>>
>> Yes , As the offline discussion had with Uvindra, We could avoid
>> exploiting the access token issued for the self-signup scenario by adding
>> captcha + token revoke mechanism, So they can't reuse the same access token
>> once it is used for self-signup, and to get new access token anonymous user
>> has to pass the captcha challenge. But still, other product REST APIs are
>> vulnerable to DOS attacks since once the user gets an access token by login
>> through the UI, it can be used to make a DOS attack. So, in general, we
>> would need to introduce throttling policy for product wide REST APIs.
>>
>> Thanks
>> ~KasunTe
>>
>> On Wed, Aug 1, 2018 at 11:06 AM Ishara Cooray  wrote:
>>
>>> So in this case there are two tokens. One for the sign up that is
>>> obtained using client credentials that only has the scope for accessing the
>>> sign up resource. The other is the one obtained from the password grant
>>> type that is used else where. I don't see a need to immediately revoke the
>>> token used for the sign up invocation(it can only be used for signing up),
>>> is there any specific concern you have regarding this?
>>>
>>> I was thinking that If this signup token is stolen, one can onboard
>>> users to the system and will lead to a potential attack. Isn't it?
>>> Of cause, if we can have captcha validation we can mitigate this.
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Wed, Aug 1, 2018 at 10:48 AM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On 1 August 2018 at 09:36, Ishara Cooray  wrote:
>>>>
>>>>> To obtain an access token using the client credentials grant we need
>>>>> to store client id and client secrete.
>>>>> How are we going to store it so that it cannot be stolen?
>>>>>
>>>>
>>>>
>>>> We need the client id and secret for the password grant type as well
>>>> which are using for all other calls. We have addressed this security
>>>> concern already by storing the client id and secret on the server side as
>>>> discussed in the mail thread[1]
>>>>
>>>> [1] API Manager UI - Storing access token in Cookie
>>>>
>>>>
>>>>> Also, I think it is better if we revoke the token as the user is
>>>>> signed up. So each sign up will need to obtain a new access token.
>>>>>
>>>>
>>>> So in this case there are two tokens. One for the sign up that is
>>>> obtained using client credentials that only has the scope for accessing the
>>>> sign up resource. The other is the one obtained from the password grant
>>>> type that is used else where. I don't see a need to immediately revoke the
>>>> token used for the sign up invocation(it can only be used for signing up),
>>>> is there any specific concern you have regarding this?
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> On Tue, Jul 31, 2018 at 3:21 PM, Vithursa Mahendrarajah <
>>>

Re: [Architecture] [APIM 3.0.0] [Store] Self-sign up and Change password features

[Ishara Cooray]

So in this case there are two tokens. One for the sign up that is obtained
using client credentials that only has the scope for accessing the sign up
resource. The other is the one obtained from the password grant type that
is used else where. I don't see a need to immediately revoke the token used
for the sign up invocation(it can only be used for signing up), is there
any specific concern you have regarding this?

I was thinking that If this signup token is stolen, one can onboard users
to the system and will lead to a potential attack. Isn't it?
Of cause, if we can have captcha validation we can mitigate this.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Aug 1, 2018 at 10:48 AM, Uvindra Dias Jayasinha 
wrote:

>
>
> On 1 August 2018 at 09:36, Ishara Cooray  wrote:
>
>> To obtain an access token using the client credentials grant we need to
>> store client id and client secrete.
>> How are we going to store it so that it cannot be stolen?
>>
>
>
> We need the client id and secret for the password grant type as well which
> are using for all other calls. We have addressed this security concern
> already by storing the client id and secret on the server side as discussed
> in the mail thread[1]
>
> [1] API Manager UI - Storing access token in Cookie
>
>
>> Also, I think it is better if we revoke the token as the user is signed
>> up. So each sign up will need to obtain a new access token.
>>
>
> So in this case there are two tokens. One for the sign up that is obtained
> using client credentials that only has the scope for accessing the sign up
> resource. The other is the one obtained from the password grant type that
> is used else where. I don't see a need to immediately revoke the token used
> for the sign up invocation(it can only be used for signing up), is there
> any specific concern you have regarding this?
>
>>
>>
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Tue, Jul 31, 2018 at 3:21 PM, Vithursa Mahendrarajah <
>> vithu...@wso2.com> wrote:
>>
>>> + [architecture]
>>>
>>> On Tue, Jul 31, 2018 at 12:55 PM Kasun Thennakoon 
>>> wrote:
>>>
>>>> Hi Rukshan,
>>>>
>>>> This is the current flow
>>>>
>>>> [image: image.png]
>>>>
>>>> So how we restricted this token, talk only to signup api? with scopes??
>>>>>
>>>> Yes we get an access token for self signup scope only
>>>>
>>>>
>>>> Thanks
>>>> ~KasunTe
>>>>
>>>>
>>>> On Tue, Jul 31, 2018 at 11:21 AM Rukshan Premathunga 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 31, 2018 at 11:12 AM, Uvindra Dias Jayasinha <
>>>>> uvin...@wso2.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 31 July 2018 at 10:57, Rukshan Premathunga 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 31, 2018 at 10:57 AM, Rukshan Premathunga <
>>>>>>> ruks...@wso2.com> wrote:
>>>>>>>
>>>>>>>> in sigin up case, if you take a token to talk to signup api, is it
>>>>>>>> also store in the browser?
>>>>>>>>
>>>>>>> * in signup case, if you take a token to talk to signup api, is it
>>>>>>> also store in the browser?
>>>>>>>
>>>>>>
>>>>>> In this case, Yes. Since there is no user involved yet(user has not
>>>>>> got registered yet), it is the store that is making this call on behalf 
>>>>>> of
>>>>>> the user so that they can get registered.
>>>>>>
>>>>> So how we restricted this token, talk only to signup api? with scopes??
>>>>>
>>>>>>
>>>>>>>> On Tue, Jul 31, 2018 at 10:26 AM, Fazlan Nazeem 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yes, since the client secret will not be known to the end users
>>>>>>>>> there is no threat in adding client_credentials grant to the store 
>>>>>>>

Re: [Architecture] [APIM 3.0.0] [Store] Self-sign up and Change password features

[Ishara Cooray]

To obtain an access token using the client credentials grant we need to
store client id and client secrete.
How are we going to store it so that it cannot be stolen?

Also, I think it is better if we revoke the token as the user is signed up.
So each sign up will need to obtain a new access token.




Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Jul 31, 2018 at 3:21 PM, Vithursa Mahendrarajah 
wrote:

> + [architecture]
>
> On Tue, Jul 31, 2018 at 12:55 PM Kasun Thennakoon 
> wrote:
>
>> Hi Rukshan,
>>
>> This is the current flow
>>
>> [image: image.png]
>>
>> So how we restricted this token, talk only to signup api? with scopes??
>>>
>> Yes we get an access token for self signup scope only
>>
>>
>> Thanks
>> ~KasunTe
>>
>>
>> On Tue, Jul 31, 2018 at 11:21 AM Rukshan Premathunga 
>> wrote:
>>
>>>
>>>
>>> On Tue, Jul 31, 2018 at 11:12 AM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On 31 July 2018 at 10:57, Rukshan Premathunga  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 31, 2018 at 10:57 AM, Rukshan Premathunga <
>>>>> ruks...@wso2.com> wrote:
>>>>>
>>>>>> in sigin up case, if you take a token to talk to signup api, is it
>>>>>> also store in the browser?
>>>>>>
>>>>> * in signup case, if you take a token to talk to signup api, is it
>>>>> also store in the browser?
>>>>>
>>>>
>>>> In this case, Yes. Since there is no user involved yet(user has not got
>>>> registered yet), it is the store that is making this call on behalf of the
>>>> user so that they can get registered.
>>>>
>>> So how we restricted this token, talk only to signup api? with scopes??
>>>
>>>>
>>>>>> On Tue, Jul 31, 2018 at 10:26 AM, Fazlan Nazeem 
>>>>>> wrote:
>>>>>>
>>>>>>> Yes, since the client secret will not be known to the end users
>>>>>>> there is no threat in adding client_credentials grant to the store app.
>>>>>>>
>>>>>>> On Tue, Jul 31, 2018 at 10:18 AM Uvindra Dias Jayasinha <
>>>>>>> uvin...@wso2.com> wrote:
>>>>>>>
>>>>>>>> +1 for option 1, adding the client credentials capability to the
>>>>>>>> store app makes sense to support this use case.
>>>>>>>>
>>>>>>>> On 31 July 2018 at 10:06, Kasun Thennakoon 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Vithursa,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In my opinion
>>>>>>>>>
>>>>>>>>> *Option-1: *Adding *client_credentials* grant type to existing
>>>>>>>>>> application
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> option-1 would be more appropriate here, other than maintaining a
>>>>>>>>> separate OAuth app for the self sign-up feature.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> ~KasunTe
>>>>>>>>>
>>>>>>>>> On Mon, Jul 30, 2018 at 9:17 PM Vithursa Mahendrarajah <
>>>>>>>>> vithu...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I encountered an issue while implementing feature to self-sign up
>>>>>>>>>> user via UI.  Access token generation using
>>>>>>>>>> *client_credentials *grant type is needed to call REST API
>>>>>>>>>> resource of self-sign up. As per current implementation, we have one 
>>>>>>>>>> DCR
>>>>>>>>>> Application for publisher and one for st*o*re which does not
>>>>>>>>>> support *client_credentials* grant type, hence token generation
>>>>>>>>>> fails. It can be resolved in two ways:
>>>>>>>>>>
>>>>>>

Re: [Architecture] Old access token cleanup when token generating, renewing and revoking.

[Ishara Cooray]

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

So by default are we going to enable the token cleanup feature and storing
old access tokens in audit table?

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



Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, Jul 20, 2018 at 10:04 AM, Harshan Liyanage  wrote:

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

[Architecture] MSF4J supported REST API for file upload feature in APIM Analytics

[Ishara Cooray]

Hi,

I started working on a REST API using wso2 MSF4J for uploading analytics
data as a zip archive to the analytics server which was discussed in [1].
This was developed as a JAX_RS web app but now we are revamping it to use
MSF4J.

Please find the swagger definition for the api.

> ##
> # The "Upload zip" resource API
> ##
> paths:
>   /usage/upload-file/:
>
> #-
> # Upload analytics data as a zip archive
> #-
> post:
>   consumes:
> - multipart/form-data
>   security:
> - OAuth2Security:
>   summary: |
> Uploading File
>   description: |
> Receives analytics data as a zip archive and upload it to persist in 
> data base.
>   parameters:
> - in: formData
>   name: analytics
>   description: zip archieve of the analytics data
>   type: file
>   required: true
>   headers:
> FileName:
>   description: |
> File name
>   type:
> string
>   responses:
> 201:
>   description: |
> Created.
> File uploaded successfully.
>   headers:
> Location:
>   description: |
> The URL of the newly created resource.
>   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.
>   schema:
> $ref: '#/definitions/Error'
>
>
>
Appreciate if any suggestions?

[1] "[Architecture] [APIM][Micro-Gateway][Analytics] Analytics for
Micro-gateway"


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Dynamic backend endpoint definition for APIs in API micro gateway

[Ishara Cooray]

Thanks, Chamila.
Shall we add that example also in the doc [1]?

[1]
https://docs.wso2.com/display/AM250/Configuring+the+API+Microgateway#ConfiguringtheAPIMicrogateway-GeneratingadistributionforagroupofAPIs

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Jul 17, 2018 at 9:19 AM, Chamila Adhikarinayake 
wrote:

> Hi Ishara,
> We can define endpoints for each apis using the above properties. For
> example, If there are two APIs (APIX and APIY), we could override the
> endpoints as following
>
> -e APIX.v1.prod.endpoint.0="http://wso2.com; <http://wso2.com/> -e
> APIY.v1.prod.endpoint.0="http://wso2.com; <http://wso2.com/>
>
> On Tue, Jul 17, 2018 at 5:56 AM, Ishara Cooray  wrote:
>
>> Hi Chamila,
>>
>> How is this dynamic endpoint feature supported for a micron gateway that
>> is set up for multiple apis through an environment label?
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Thu, Jun 28, 2018 at 12:40 PM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> A small suggestion for the implementation: I think this will be
>>> relatively easier if we define a function to get a particular config from
>>> env variable name (input 1) or from the default value (input 2) (if env
>>> variable is not defined). Then we can use this function name straight in
>>> the codegen templates. I think the function can be defined in the ballerina
>>> lib sources in the gateway core so that can be reused easily.
>>>
>>> Thanks!
>>>
>>> On Thu, Jun 28, 2018 at 12:18 PM, Chamila Adhikarinayake <
>>> chami...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm implementing a dynamic backend endpoint feature which will provide
>>>> users the capability to define dedicated backends for the same API.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This feature is a bit similar to what we have in API Manager where we
>>>> define endpoints with variables and resolve it during the runtime (say we
>>>> set backend endpoint as http://{uri.var.host}:{uri.var.port}/apis/weather
>>>> and resolve them using system variables, etc).
>>>>
>>>> Similarly, We plan to provide a method to override the backend endpoint
>>>>  uri from the API. But this method doesn't depend on whether the URL
>>>> is defined with template structure (with {uri.var.host}, etc).
>>>>
>>>> For example, If there is an API with TestAPI and version 1.0, we could
>>>> define *TestAPI-1.0.prod.**ep* , *TestAPI-1.0.sand.ep* as environment
>>>> variables, value in the TOML format or as command-line parameters and
>>>> override the existing related endpoint during the startup time. If the
>>>> properties are not provided, then we use endpoint defined in the API as the
>>>> default endpoint.
>>>>
>>>> This way, a user can start the micro-gateway with the default backend
>>>> endpoint or he can override it during the startup time. This will give the
>>>> capability to call dedicated endpoints for each environment
>>>>
>>>> Chamila.
>>>>
>>>> --
>>>> Regards,
>>>> Chamila Adhikarinayake
>>>> WSO2, Inc.
>>>> Mobile - +94712346437
>>>> Email  - chami...@wso2.com
>>>> Blog  -  http://helpfromadhi.blogspot.com/
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Regards,
> Chamila Adhikarinayake
> WSO2, Inc.
> Mobile - +94712346437
> Email  - chami...@wso2.com
> Blog  -  http://helpfromadhi.blogspot.com/
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Using /export might confuse with the api export API we have for API Manager
3.0. We should probably use the GET /apis Resource for this as well.
+1

Since we need to omit pagination (because in this case we need all results)
we may need to do something like this

GET /apis?limit=unlimited

Omitting pagination may lead to out of memory issue if it returns a large
JSON.
What could be the maximum no of APIs that a lable can have?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, May 17, 2018 at 11:55 AM, Nuwan Dias <nuw...@wso2.com> wrote:

>
>
> On Thu, May 17, 2018 at 11:49 AM, Malintha Amarasinghe <malint...@wso2.com
> > wrote:
>
>>
>>
>> On Thu, May 17, 2018 at 10:57 AM Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> Using /export might confuse with the api export API we have for API
>>> Manager 3.0. We should probably use the GET /apis Resource for this as
>>> well.
>>>
>>> Since we need to search by label, we'll probably need to filter as below
>>>
>>> GET /apis?query=label:foo
>>>
>>> Since we need to omit pagination (because in this case we need all
>>> results) we may need to do something like this
>>>
>>> GET /apis?limit=unlimited
>>>
>> The limit is currently defined as a number. How about limit=-1? Or we
>> have to change the limit data type to string.
>>
>
> +1
>
>>
>>
>>> The GET /apis responds with a partial payload for listing purposes.
>>> Since that doesn't work in this case we probably need to support a query
>>> param named 'expand'. Ex:
>>>
>>> GET /apis?expand=true
>>>
>>> We may need to honor the Accept header to decide on compression. Ex:
>>>
>>> Accept: application/gzip
>>>
>>> On Wed, May 16, 2018 at 6:38 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>>
>>>> Hi Sachini,
>>>>
>>>> Since the response could have more than 1 APIs you will have to
>>>> consider about pagination as well.
>>>>
>>>> For that, you may use existing *APIList *resource in the
>>>> publisher-api.yaml
>>>>
>>>> Thanks & Regards,
>>>> Ishara Cooray
>>>> Senior Software Engineer
>>>> Mobile : +9477 262 9512
>>>> WSO2, Inc. | http://wso2.com/
>>>> Lean . Enterprise . Middleware
>>>>
>>>> On Tue, May 15, 2018 at 10:08 AM, Sachini De Silva <sachi...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Harsha,
>>>>>
>>>>> Yes, the response contains the swagger definition of APIs and all
>>>>> fields in APIDTO. As for the current implementation labeled apis are
>>>>> returned as a json list. (see response.json) To accommodate this I have
>>>>> introduced a new DetailedAPIListDTO as below.
>>>>>
>>>>> DetailedAPIList:
>>>>> title: Detailed API List
>>>>> properties:
>>>>>   list:
>>>>> type: array
>>>>> items:
>>>>>   $ref: '#/definitions/API'
>>>>>
>>>>> At the moment I am working on compressing the response.
>>>>>
>>>>> Thanks,
>>>>> Sachini
>>>>>
>>>>>
>>>>> On Mon, May 14, 2018 at 5:39 PM, Harsha Kumara <hars...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Sachini,
>>>>>>
>>>>>> Is swagger definition embed with the response returning from this API?
>>>>>>
>>>>>> Thanks,
>>>>>> Harsha
>>>>>>
>>>>>> On Wed, May 9, 2018 at 2:49 PM Sachini De Silva <sachi...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> @Harsha Decided to return all information in APIDTO for each API as
>>>>>>> the response. (not only swagger definition, name, version, context and
>>>>>>> provider)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sachini
>>>>>>>
>>>>>>> On Wed, May 9, 2018 at 1:59 PM, Harsha Kumara <hars...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> @Sachini Can yo

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

[Ishara Cooray]

Hi Sachini,

Since the response could have more than 1 APIs you will have to consider
about pagination as well.

For that, you may use existing *APIList *resource in the publisher-api.yaml

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, May 15, 2018 at 10:08 AM, Sachini De Silva <sachi...@wso2.com>
wrote:

> Hi Harsha,
>
> Yes, the response contains the swagger definition of APIs and all fields
> in APIDTO. As for the current implementation labeled apis are returned as a
> json list. (see response.json) To accommodate this I have introduced a new
> DetailedAPIListDTO as below.
>
> DetailedAPIList:
> title: Detailed API List
> properties:
>   list:
> type: array
> items:
>   $ref: '#/definitions/API'
>
> At the moment I am working on compressing the response.
>
> Thanks,
> Sachini
>
>
> On Mon, May 14, 2018 at 5:39 PM, Harsha Kumara <hars...@wso2.com> wrote:
>
>> Hi Sachini,
>>
>> Is swagger definition embed with the response returning from this API?
>>
>> Thanks,
>> Harsha
>>
>> On Wed, May 9, 2018 at 2:49 PM Sachini De Silva <sachi...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> @Harsha Decided to return all information in APIDTO for each API as the
>>> response. (not only swagger definition, name, version, context and provider)
>>>
>>> Thanks,
>>> Sachini
>>>
>>> On Wed, May 9, 2018 at 1:59 PM, Harsha Kumara <hars...@wso2.com> wrote:
>>>
>>>> @Sachini Can you also add a sample response as well?
>>>>
>>>> On Wed, May 9, 2018 at 8:02 AM, Malintha Amarasinghe <
>>>> malint...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> On Tue, May 8, 2018 at 6:10 PM, Sachini De Silva <sachi...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Proposed resource structure is as below.
>>>>>>
>>>>>>
>>>>>> /exports/apis:
>>>>>>
>>>>>
>>>>> +1. I think this looks more like generic export resource which is not
>>>>> really specific for the ballerina gw feature. I think it is okay as we can
>>>>> use this for any other future requirements which needs API export
>>>>> facilities.
>>>>>
>>>>>
>>>>>
>>>>>>get:
>>>>>>  x-scope: apim:api_export
>>>>>>
>>>>> +1
>>>>>
>>>>>>
>>>>>>  produces:
>>>>>>- application/x-gzip
>>>>>>
>>>>> Not sure this is the most suitable content type we need
>>>>> among application/zip, application/gzip and application/x-gzip?
>>>>>
>>>>> To choose a better one, I think we need to think about what structure
>>>>> we are going to give a response with API information.
>>>>>
>>>>> Will it be a compressed file with a set of folders that containing
>>>>> each API's information?
>>>>>
>>>>>
>>>>>>  summary: Return apis categorized into a label.
>>>>>>  description: |
>>>>>>This operation can be used to fetch APIs categorized into a
>>>>>> certain label.
>>>>>>  parameters:
>>>>>>- name: labelId
>>>>>>  in: query
>>>>>>  required: true
>>>>>>  type: string
>>>>>>
>>>>>
>>>>> Since this is a "required" query parameter, we can think of *GET
>>>>> /exports/apis/{labelId} *as well. But if we use this, we will loose
>>>>> the opportunity to define *GET /exports/apis/{apiId} *in future to
>>>>> export a single API. So +1 for the query parameter.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>>
>>>>>>  responses:
>>>>>>200:
>>>>>>  description: |
>>>>>>OK.
>>>>>>  schema:
>>>>>>type: file
>>>>>>  headers:
>>>>>>Content-Type:
>>>

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

[Ishara Cooray]

Hi Vithursa,

IMO you also need to have *another user story to delete applications with
custom attributes *where you need to make sure application is successfully
deleted from the application list along with its custom attributes.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Apr 19, 2018 at 1:54 AM, Nuwan Dias <nuw...@wso2.com> wrote:

> Based on what Youcef has mentioned, we would need to include these
> additional properties on the JWT perhaps so that they can be accessed by
> the Gateway upon validating an access token.
>
> On Wed, Apr 18, 2018 at 11:38 PM, Youcef HILEM <youcef.hi...@laposte.fr>
> wrote:
>
>> Hi,
>>  for this feature.
>> I do not have access to the document [1] but we wish to develop mediations
>> reinforcing access control to APIs according to these metadata (example
>> (key: client-contract, value: contractx), ie : association between
>> client-id
>> & client-contract-id).
>> Thanks
>> Youcef HILEM
>>
>>
>>
>> --
>> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Architectur
>> e-f62919.html
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 API Manager 2.1.0-update4 Released!

[Ishara Cooray]

The WSO2 API Manager team is pleased to announce the release of version
2.1.0-update4 of API Manager.

WSO2 API Manager is a platform for creating, managing, consuming and
monitoring APIs. It employs proven SOA best practices to solve a wide range
of API management challenges such as API provisioning, API governance, API
security and API monitoring. It combines some of the most powerful and
mature components of the WSO2's state-of-the-art Carbon platform to deliver
a smooth and end-to-end API management experience while catering to both
API publisher and API consumer requirements.

WSO2 API Manager is comprised of several modules.

   -

   API Provider: Define new APIs and manage them
   -

   API Store: Browse published APIs and subscribe to them
   -

   API Gateway: The underlying API runtime based on WSO2 ESB
   -

   API Key Manager: Performs Key Generation and Key Validation
   functionalities
   -

   API Traffic Manager: Performs Rate Limiting of API Requests

For more information on WSO2 API Manager please visit
http://wso2.com/products/api-manager. Also take a look at the online
product documentation
<https://docs.wso2.com/display/AM220/WSO2+API+Manager+Documentation>.

Distributions

WSO2 APIM 2.1.0-update4.zip
<https://github.com/wso2/product-apim/releases/download/v2.1.0-update4/wso2am-2.1.0-update4.zip>

WSO2 APIM Analytics 2.1.0-update3.zip
<https://github.com/wso2/product-apim/releases/download/v2.1.0-update4/wso2am-analytics-2.1.0-update3.zip>
How to Run

   1.

   Extract the downloaded zip
   2.

   Go to the bin directory in the extracted folder
   3.

   Run the wso2server.sh or wso2server.bat as appropriate
   4.

   Launch a web browser and navigate to https://localhost:9443/publisher to
   access the API publisher webapp
   5.

   Navigate to https://localhost:9443/store to access the API store
   6.

   Navigate to https://localhost:9443/admin to access Admin Portal
   7.

   Use "admin", "admin" as the username and password to login as an admin

Bug Fixes And Improvements in 2.1.0-update4

Please refer following locations for WSO2 API Manager 2.1.0-update4 Bug
fixes and Improvements


   1.

   JIRA <https://wso2.org/jira/issues/?filter=14497>
   2.

   GitHub (carbon-apimgt)
   <https://github.com/wso2/carbon-apimgt/milestone/6?closed=1>
   3.

   GitHub (product-apim)
   <https://github.com/wso2/product-apim/milestone/10?closed=1>

Known Issues

All the open issues pertaining to WSO2 API Manager are reported at the
following location:

   1.

   JIRA <https://wso2.org/jira/issues/?filter=14454>
   2.

   GitHub (carbon-apimgt)
   
<https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+-label%3A%223.0.0%22+>
   3.

   GitHub (product-apim)
   
<https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aopen+-label%3A3.0.0+>

How You Can ContributeMailing Lists

Join our mailing list and correspond with the developers directly.

   -

   Developer List : d...@wso2.org | Subscribe | Mail Archive
   <http://wso2.org/mailarchive/dev/>
   -

   User List : u...@wso2.org | Subscribe | Mail Archive
   <http://wso2.org/mailarchive/user/>
   -

   User Forum : Stack Overflow
   <https://stackoverflow.com/questions/tagged/wso2-am>

Reporting Issues

We encourage you to report issues, documentation faults and feature
requests regarding WSO2 API Manager through the WSO2 API Manager Git issues
<https://github.com/wso2/product-apim/issues>

-- The WSO2 API Manager Team --

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 API Manager 2.1.0-update2 Released!

[Ishara Cooray]

The WSO2 API Manager team is pleased to announce the release of version
2.1.0-update2 of API Manager.

WSO2 API Manager is a platform for creating, managing, consuming and
monitoring APIs. It employs proven SOA best practices to solve a wide range
of API management challenges such as API provisioning, API governance, API
security and API monitoring. It combines some of the most powerful and
mature components of the WSO2's state-of-the-art Carbon platform to deliver
a smooth and end-to-end API management experience while catering to both
API publisher and API consumer requirements.

WSO2 API Manager is comprised of several modules.

   -

   API Provider: Define new APIs and manage them
   -

   API Store: Browse published APIs and subscribe to them
   -

   API Gateway: The underlying API runtime based on WSO2 ESB
   -

   API Key Manager: Performs Key Generation and Key Validation
   functionalities
   -

   API Traffic Manager: Performs Rate Limiting of API Requests

For more information on WSO2 API Manager please visit
http://wso2.com/products/api-manager. Also take a look at the online
product documentation
<https://docs.wso2.com/display/AM220/WSO2+API+Manager+Documentation>.

Distributions

WSO2 APIM 2.1.0-update2.zip
<https://github.com/wso2/product-apim/releases/download/v2.1.0-update2/wso2am-2.1.0-update2.zip>

WSO2 APIM Analytics 2.1.0-update2.zip
<https://github.com/wso2/analytics-apim/releases/download/v2.1.0-update2/wso2am-analytics-2.1.0-update2.zip>
How to Run

   1.

   Extract the downloaded zip
   2.

   Go to the bin directory in the extracted folder
   3.

   Run the wso2server.sh or wso2server.bat as appropriate
   4.

   Launch a web browser and navigate to https://localhost:9443/publisher to
   access the API publisher webapp
   5.

   Navigate to https://localhost:9443/store to access the API store
   6.

   Navigate to https://localhost:9443/admin to access Admin Portal
   7.

   Use "admin", "admin" as the username and password to login as an admin

Bug Fixes And Improvements in 2.1.0-update2

Please refer [1] and [2] for WSO2 API Manager 2.1.0-update2 Bug fixes and
Improvements

[1]  JIRA <https://wso2.org/jira/browse/APIMANAGER-6018?filter=14478>

[2]  GitHub <https://github.com/wso2/carbon-apimgt/milestone/4?closed=1>

Known Issues

All the open issues pertaining to WSO2 API Manager are reported at the
following location:

 [1]   JIRA <https://wso2.org/jira/issues/?filter=14454>

 [2]   GitHub
<https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+-label%3A%223.0.0%22+>
How You Can ContributeMailing Lists

Join our mailing list and correspond with the developers directly.

   -

   Developer List : d...@wso2.org | Subscribe | Mail Archive
   <http://wso2.org/mailarchive/dev/>
   -

   User List : u...@wso2.org | Subscribe | Mail Archive
   <http://wso2.org/mailarchive/user/>
   -

   User Forum : Stack Overflow
   <https://stackoverflow.com/questions/tagged/wso2-am>

Reporting Issues

We encourage you to report issues, documentation faults and feature
requests regarding WSO2 API Manager through the public API Manager JIRA
<https://wso2.org/jira/browse/APIMANAGER>. You can use the Carbon JIRA
<http://www.wso2.org/jira/browse/CARBON> to report any issues related to
the Carbon base framework or associated Carbon components.

-- The WSO2 API Manager Team --



Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512 <+94%2077%20262%209512>
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: WSO2 API Manager 2.1.0-update1 Released!

[Ishara Cooray]

Apologies for incorrect links. Resending the mail with corrected links.

The WSO2 API Manager team is pleased to announce the release of version
2.1.0-update1 of API Manager.

WSO2 API Manager is a platform for creating, managing, consuming and
monitoring APIs. It employs proven SOA best practices to solve a wide range
of API management challenges such as API provisioning, API governance, API
security and API monitoring. It combines some of the most powerful and
mature components of the WSO2's state-of-the-art Carbon platform to deliver
a smooth and end-to-end API management experience while catering to both
API publisher and API consumer requirements.

WSO2 API Manager is comprised of several modules.

   -

   API Provider: Define new APIs and manage them
   -

   API Store: Browse published APIs and subscribe to them
   -

   API Gateway: The underlying API runtime based on WSO2 ESB
   -

   API Key Manager: Performs Key Generation and Key Validation
   functionalities
   -

   API Traffic Manager: Performs Rate Limiting of API Requests

For more information on WSO2 API Manager please visit
http://wso2.com/products/api-manager. Also take a look at the online
product documentation
<https://docs.wso2.com/display/AM220/WSO2+API+Manager+Documentation>.

Distributions

WSO2 APIM 2.1.0-update1.zip
<https://github.com/wso2/product-apim/releases/download/v2.1.0-update1/wso2am-2.1.0-update1.zip>

WSO2 APIM Analytics 2.1.0-update1.zip
<https://github.com/wso2/product-apim/releases/download/v2.1.0-update1/wso2am-analytics-2.1.0-update1.zip>
How to Run

   1.

   Extract the downloaded zip
   2.

   Go to the bin directory in the extracted folder
   3.

   Run the wso2server.sh or wso2server.bat as appropriate
   4.

   Launch a web browser and navigate to https://localhost:9443/publisher to
   access the API publisher webapp
   5.

   Navigate to https://localhost:9443/store to access the API store
   6.

   Navigate to https://localhost:9443/admin to access Admin Portal
   7.

   Use "admin", "admin" as the username and password to login as an admin

Bug Fixes And Improvements in 2.1.0-update1

Please refer [1] and [2] for WSO2 API Manager 2.1.0-update1 Bug fixes and
Improvements

[1] JIRA <https://wso2.org/jira/browse/APIMANAGER-6019?filter=14453>

<https://wso2.org/jira/browse/APIMANAGER-6019?filter=14453>[2] GitHub
<https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+-label%3A%223.0.0%22+>
Known Issues

All the open issues pertaining to WSO2 API Manager are reported at the
following location [1] and [2]:

[1] JIRA <https://wso2.org/jira/issues/?filter=14454>
[2] GitHub
<https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+-label%3A%223.0.0%22+>
How You Can ContributeMailing Lists

Join our mailing list and correspond with the developers directly.

   -

   Developer List : d...@wso2.org | Subscribe | Mail Archive
   <http://wso2.org/mailarchive/dev/>
   -

   User List : u...@wso2.org | Subscribe | Mail Archive
   <http://wso2.org/mailarchive/user/>
   -

   User Forum : Stack Overflow
   <https://stackoverflow.com/questions/tagged/wso2-am>

Reporting Issues

We encourage you to report issues, documentation faults and feature
requests regarding WSO2 API Manager through the public API Manager JIRA
<https://wso2.org/jira/browse/APIMANAGER>. You can use the Carbon JIRA
<http://www.wso2.org/jira/browse/CARBON> to report any issues related to
the Carbon base framework or associated Carbon components.

-- The WSO2 API Manager Team --


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Sun, Dec 3, 2017 at 10:17 AM, Bhathiya Jayasekara <bhath...@wso2.com>
wrote:

> The WSO2 API Manager team is pleased to announce the release of version
> 2.1.0-update1 of API Manager.
>
> WSO2 API Manager is a platform for creating, managing, consuming and
> monitoring APIs. It employs proven SOA best practices to solve a wide range
> of API management challenges such as API provisioning, API governance, API
> security and API monitoring. It combines some of the most powerful and
> mature components of the WSO2's state-of-the-art Carbon platform to deliver
> a smooth and end-to-end API management experience while catering to both
> API publisher and API consumer requirements.
>
> WSO2 API Manager is comprised of several modules.
>
>-
>
>API Provider: Define new APIs and manage them
>-
>
>API Store: Browse published APIs and subscribe to them
>-
>
>API Gateway: The underlying API runtime based on WSO2 ESB
>-
>
>API Key Manager: Performs Key Generation and Key Validation
>functionalities
>-
>
>API Traffic Manager: Performs Rate Limiting of API Reque

Re: [Architecture] [C5][APIM] Exposing WSDL based APIs in API Manager 3.0.0

[Ishara Cooray]

Hi Malintha,
 + for the idea as it makes more sense to the api rather than giving only
one POST operation.

Currently we can create soap apis only by giving the URl of the wsdl.
Are we going to support create soap apis by uploading wsdl as well?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Jul 17, 2017 at 11:22 PM, Malintha Amarasinghe <malint...@wso2.com>
wrote:

> Hi Maninda,
>
> If there are any POST operations defined as HTTP binding, we will make
> them normal HTTP POST operations. Sorry, may be my example is a bit
> confusing.
>
> If we take below set of operations, we will have to include HTTP POST
> operations as well.
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> We will be extracting:
>
>- GET /GetQuickQuote
>- GET /GetQuoteDataSet
>- POST /GetQuickQuote
>- POST /GetQuoteDataSet
>
>
>
> I meant to say we would use "POST /" resource only for SOAP binding
> operations. For example:
>
>
> 
> http://schemas.xmlsoap.org/soap/http"/>
> 
> http://ws.cdyne.com/GetQuote; style="document"
> />
> 
> 
> 
> 
> 
> 
> 
> 
> http://ws.cdyne.com/GetQuickQuote; style="
> document"/>
> 
> 
> 
> 
> 
> 
> 
> 
> http://ws.cdyne.com/GetQuoteDataSet; style="
> document"/>
> 
> 
> 
> 
> 
> 
> 
> 
>
>
> Thanks!
> Malintha
>
>
> On Mon, Jul 17, 2017 at 4:38 PM, Maninda Edirisooriya <mani...@wso2.com>
> wrote:
>
>> Hi Malintha,
>>
>> Why we are not making POST operations too as HTTP POST operations? As
>> POST is also a HTTP verb why make it different as SOAP? Are there any more
>> differences between SOAP binding that are not supported in HTTP REST like
>> operations? If that is the case is it correct to move other operations
>> (like GET etc.) to HTTP operations?
>> Thanks.
>>
>>
>> *Maninda Edirisooriya*
>> Senior Software Engineer
>>
>> *WSO2, Inc.*lean.enterprise.middleware.
>>
>> *Blog* : http://maninda.blogspot.com/
>> *E-mail* : mani...@wso2.com
>> *Skype* : @manindae
>> *Twitter* : @maninda
>>
>> On Thu, Jul 13, 2017 at 7:21 PM, Malintha Amarasinghe <malint...@wso2.com
>> > wrote:
>>
>>> Hi,
>>>
>>> In C4 based API Manager, when we create an API using a WSDL, the API is
>>> created with only one resource which is POST /*. We used this for invoking
>>> the service with SOAP payloads.
>>>
>>> But in a typical WSDL, there are several operations defined which are of
>>> different bindings such as SOAP and HTTP. When we look at HTTP binding
>>> based operations, those are a slightly similar to REST operations which
>>> use HTTP verbs such as GET, DELETE, PUT etc.
>>>
>>> For APIM 3.0.0 we are considering parsing those operations as well and
>>> automatically create resources in the API.
>>>
>>> A user can select one of below two options when creating a WSDL-based
>>> API. This is because it is not good to mix up both SOAP and other REST-like
>>> (HTTP binding) operations in the same API.
>>>
>>> *1. Create a Pass-through SOAP API*
>>>
>>> If a user selects this option, an API will be created with "POST /".
>>> This is similar to an API Manager 2.1.0 SOAP API.
>>>
>>> *2. Create an API with HTTP binding operations*
>>>
>>> Then, the operations with HTTP binding are extracted from WSDL and those
>>> are used to create resources in API.
>>>
>>> For example, if we take below binding of the WSDL:
>>>
>>>   >> type="tns:WeatherForecastHttpGet">
>>> 
>>> 
>>>   
>>>   
>>> 
>>>   
>>>   
>>> 
>>>   
>>> 
>>> 
>>>   
>>>   
>>> 
>>>   
>>>   
>>> 
>>>   
>>> 
>>>   
>>>
>>>
>>> These operations can be generated based on above:
>>>
>>> GET /GetWeatherByZipCode
>>> GET /GetWeatherByPlaceName
>>>
>>>
>>> Appreciate your inputs on this.
>>>
>>> Thanks!
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306 <071%20238%203306>
>>>
>>
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306 <+94%2071%20238%203306>
>
> ___
> 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

[Architecture] [APIM 3.0] Product REST APIs service path definition

[Ishara Cooray]

Hi,

I observed below in our product REST APIs.


*Publisher API*

In *publisher-api.yaml *base path is defined as

*/api/am/publisher/v1.0*
There are several micro services serving the publisher API hence, *@Path*
 at the service level (base path) is defined as follows.

/api/am/publisher/v1.[\\d]+/apis
/api/am/publisher/v1.[\\d]+/endpoints
/api/am/publisher/v1.[\\d]+/applications
/api/am/publisher/v1.[\\d]+/environments
/api/am/publisher/v1.[\\d]+/export
/api/am/publisher/v1.[\\d]+/import
/api/am/publisher/v1.[\\d]+/labels
/api/am/publisher/v1.[\\d]+/policies
/api/am/publisher/v1.[\\d]+/subscriptions
/api/am/publisher/v1.[\\d]+/workflows

Due to above path definition, root collection does not have a @Path
annotation defined and @Path annotation for other resources are not
prefixed with the root collection.

ex:* /apis/{apiId*} is defined as

*/{apiId}*So there is an inconsistency in swagger definition and service
definition.
If we read path from swagger we get /apis/{apiId}
whereas from the service annotation we get it as /{apiId}


Same design has followed in store and admin apis as well.

This lead to a problem when doing the scope validation at the interceptor
level.
Because we validate scopes based on the resource path template that is
stored as what we read from swagger doc.

*Option 1*. We can get rid of this by doing an extra string manipulation
but IMHO it is not a good option as this path get hits for each and every
request coming to REST APIs and this is a deviation from what we can have
from the standard.

*Option 2*. If we can have a single Micro service to service entire API we
can define service path as /api/am/publisher/v1.[\\d]  which will solve the
inconsistency.

Do we have extra advantages(performance etc.) to have separate micro
services?

In this use case(scope validation) what could be the best option to follow
from option 1 & 2?

WDYT?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [DEV] Can we bind custom interceptors in msf4j2.3.0-m2

[Ishara Cooray]

+ architecture

I
f you are asking about the dynamic interceptors similar to the dynamic
binding of filters in JAX-RS spec [1],  MSF4J currently do not support
dynamic binding of interceptors.


[1] https://access.redhat.com/documentation/en-us/red_hat_
jboss_fuse/6.3/html/apache_cxf_development_guide/
jaxrs20filters#JAXRS20Filters-DynamicBinding

Yes,

We need a way to bind Interceptors which are coming from a configuration.
But that also has to be per service , not the global.

Because
For instance, We have the publisher REST API implemented as a micro service.
We need to secure this service using interceptors. Further, we are planning
to have one interceptor per authentication type(BasicAuth, OAuth2, etc.).

Now, if someone need to add a custom authenticator, it should be possible
to write a custom authentication interceptor and plug it into the
Microservice.

Can this be supported?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Jun 1, 2017 at 2:25 PM, Vidura Nanayakkara <vidu...@wso2.com> wrote:

> Hi Ishara,
>
> So, can we have the support to be able to plug custom interceptors for
>> microservices?
>
>
> ​
> I
> f you are asking about the dynamic interceptors similar to the dynamic
> binding of filters in JAX-RS spec [1],  MSF4J currently do not support
> dynamic binding of interceptors.
>
>
> [1] https://access.redhat.com/documentation/en-us/red_hat_
> jboss_fuse/6.3/html/apache_cxf_development_guide/
> jaxrs20filters#JAXRS20Filters-DynamicBinding
>
> Best Regards,
> Vidura Nanayakkara
>
> On Thu, Jun 1, 2017 at 1:19 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> Thanks for the clarification Vidura.
>>
>> So, can we have the support to be able to plug custom interceptors for
>> microservices?
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Thu, Jun 1, 2017 at 1:02 PM, Vidura Nanayakkara <vidu...@wso2.com>
>> wrote:
>>
>>> Hi Ishara,
>>>
>>> On Thu, Jun 1, 2017 at 12:29 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>>
>>>> According to the new Interceptor support in msf4j-2.3.0-m2
>>>>
>>>> AFAIU,
>>>> We can bind interceptors for a given microservice as below.
>>>>
>>>> InterceptorService is the micro service that is going to be intercepted by 
>>>> RequestInterceptors and Responseinterceptors annotated by
>>>>
>>>> @RequestInterceptor and @ResponseInterceptor
>>>>
>>>> @Component(
>>>>> name = "InterceptorService",
>>>>> service = Microservice.class,
>>>>> immediate = true
>>>>> )@Path("/interceptor-service")public class InterceptorService implements 
>>>>> Microservice {
>>>>>
>>>>>
>>>>> private static final Logger log = 
>>>>> LoggerFactory.getLogger(InterceptorService.class);
>>>>>
>>>>>
>>>>> /** * Method for getting the micro-service name. * * 
>>>>> @return name of the micro-service. */
>>>>> @GET
>>>>> @Path("/service-name")
>>>>> @RequestInterceptor(
>>>>> ​​
>>>>> HTTPRequestLogger.class)
>>>>> @ResponseInterceptor(HTTPResponseLogger.class)
>>>>> public String getServiceName() {
>>>>> log.info("HTTP Method Execution - getServiceName()");
>>>>> return "WSO2 Service";
>>>>> }
>>>>> }
>>>>>
>>>>> 1. Can we use @RequestInterceptor and @ResponseInterceptor
>>>> annotations to the class level so that it will apply for every resource
>>>> invocation?
>>>>
>>>
>>> ​Yes, you can use @RequestInterceptor and @ResponseInterceptor to the
>>> class level so that it will apply to every resource invocation in the
>>> service.
>>>
>>> Example:
>>>
>>> @Path("/stockquote")
>>>
>>> @RequestInterceptor(
>>> ​
>>> HTTPRequestLogger.class)
>>>
>>> @ResponseInterceptor({HTTPResponseLogger.class, 
>>> LogTextResponseInterceptor.class})
>>>
>>> public class StockQuoteServi

Re: [Architecture] Carbon C5 - Server Configuration Model

[Ishara Cooray]

Thanks Danesh.

Do we have a time line for next carbon-datasources release?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, May 29, 2017 at 7:11 PM, Danesh Kuruppu <dan...@wso2.com> wrote:

> Hi Ishara,
>
> What is the conclusion for supporting database configurations in C5
>> configuration model?
>>
>
> We decided to maintain datasource related configuration in
> deployment.yaml. There is no default values for datasource configuration.
> If any product needs to add datasources, those configurations should
> mention in the deployment.yaml.
>
>
>> In which kernel version we can expect this ?
>>
>
> This is in a separate repository(carbon-datasources)[1]. We are going to
> add this configuration model in next carbon-datasources release.
>
> 1. https://github.com/wso2/carbon-datasources
>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc <https://wso2.com/signature>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] SSO Feature for Publisher/Store Login

[Ishara Cooray]

Hi Naduni,

You need to provide client id and scopes in your request to authorize
endpoint.

As sanjeewa said, you will need to do the token request from the
store/publisher app.
This token request has to be provided with need client secrete.
[1] helps to tryout authorization grant.

How do you handle the token renewal?

IMO, you can use refresh_token to renew access token.
To do that you can store the refresh_token you receive from the access
token request and use that to renew the token using refresh_token grant.
[2] may also be a useful reference.

[1] https://docs.wso2.com/display/IS530/Try+Authorization+Code+Grant
[2]
http://eveonline-third-party-documentation.readthedocs.io/en/latest/sso/authentication.html

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, May 23, 2017 at 10:17 PM, Ishara Karunarathna <isha...@wso2.com>
wrote:

> Hi Naduni,
>
> In this flow user authentication should be done using ID token (you will
> get this with access token )
> And to access the relevant resources you can use access token but need to
> send necessary scopes in the beginning.
>
> And I have following questions regarding this.
>
> 1. How do you configure this IDPs other than WSO2 identity server
> 2. How do you handle logout ?
>
> -Ishara
>
>
> On Mon, May 22, 2017 at 11:12 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>
>> After we receive authorization code browser cannot get token alone. It
>> need to have client keys, secrets, scopes etc. So after 8th step onward
>> token retrieving need to be handle from publisher/store side. Then app need
>> to obtain token and direct user to new page. Also as i remember by the time
>> we get authorization code we need to show scopes and get user consent for
>> scopes.
>>
>> Thanks,
>> sanjeewa.
>>
>> On Mon, May 22, 2017 at 10:38 AM, Naduni Pamudika <nad...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> In API Manager, currently we have basic authentication. In order to move
>>> it into Single Sign On (SSO) for API Manager 3.0 (for Publisher and Store
>>> logins), it was agreed in [1] to use OpenID Connect (OIDC) with
>>> authorization code grant type.
>>>
>>> Following diagram explains the flow of the SSO feature for
>>> Publisher/Store Login.
>>>
>>>
>>> ​
>>> ​
>>> Appreciate your feedback and suggestions on the approach.
>>>
>>> [1] Mail Subject - "[Architecture] [APIM] [C5] Single sign on support in
>>> API Manager 3.0"
>>>
>>> Thank you.
>>> Naduni
>>> --
>>> *Naduni Pamudika*
>>> Software Engineer
>>>
>>> WSO2 Inc: http://wso2.com
>>> Email: nad...@wso2.com
>>> Mobile: 0719143658 <071%20914%203658>
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>
>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <+94%2071%20306%208779>
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>
>
> --
> Ishara Karunarathna
> Associate Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <+94%2071%20799%206791>
>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

[Ishara Cooray]

By considering above discussion and the off line chat we had, it was
concluded that,

we allow the default resource to scope mapping remain in the Swagger doc
and move whatever resource to scope mappings a user needs to
deployment.yaml which is the global configuration file for the product.

This way it avoids the problems encounter if the swagger is given to edit
and it does not have the over head of adding multiple configuration files.

We can define separate name spaces for publisher/store/admin in deployment
yaml.
In each we can define configs for resource to scope mapping.

And then we can read configs in the deploymant.yaml by accessing
configuration map itself from below method in org.wso2.carbon.kernel.configp
rovider.*ConfigProvider*

public Map getConfigurationMap(String namespace)


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, May 16, 2017 at 9:01 AM, Lakmali Baminiwatta <lakm...@wso2.com>
wrote:

>
>
> On 15 May 2017 at 14:41, Nuwan Dias <nuw...@wso2.com> wrote:
>
>> What is the benefit of using operationId instead of the resource path? In
>> the current Swagger we do not have operationIds defined right?
>>
>
> Since it will be just a string, it is less error prone than defining the
> resource path and also even when the resource path is changed in a major
> release, we can keep the operationId unchanged. Yeah, we don't have them
> defined right now.
>
> If we introduce operationIds just for this use case, as developers we need
>> to spend time thinking of operationIds per resource, make sure we don't
>> duplicate operationIds and more importantly never change operationIds in
>> newer versions :).
>>
>
> Through swagger validation we can ensure is is not duplicated. However, as
> you said we don't have a way to ensure no one changes them in new releases.
>
> To me at least something in the form of [http_method] [path] [scope], ex:
>> POST /apis foo, is more natural than artificially built operationIds. So
>> unless there's a huge benefit in using operationIds vs resource paths, I
>> think we should just stick to the resource paths.
>>
>
> If we use operationIds, they should be self descriptive and not just
> unique strings. However, I am ok with the resource path. It is just that I
> think defining operationId will be more easier for the users.
>
>>
>> Regarding scope to role mapping, that is only required for the Key
>> Manager (IS). Since it is the KM who issues and validates tokens, this
>> mapping is only required by the KM AFAIU.
>>
>
>> On Thu, May 11, 2017 at 3:14 PM, Lakmali Baminiwatta <lakm...@wso2.com>
>> wrote:
>>
>>> If we are to avoid migration of modified scopes, I think we have to go
>>> with the second approach of defining resource to scope mapping in an
>>> optional config file. However, rather than defining the resource path in
>>> this file, how about using an unique identifier per operation? In swagger,
>>> we can define an *operationId* per operation which must be unique
>>> [1][2]. This way even if a resource path changes in a major release, 
>>> *operationId
>>> *won't change*. *
>>>
>>> BTW we also have to allow configuring scope to role mapping.
>>>
>>> [1] http://swagger.io/specification/
>>> [2] http://petstore.swagger.io/v2/swagger.json
>>>
>>> Thanks,
>>> Lakmali
>>>
>>> On 10 May 2017 at 11:26, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>> So it seems Sanjeewa's and my view points are clear on this.
>>>>
>>>> 1. Sanjeewa basically says let users (sys-admins) edit the Swagger file
>>>> that define the product REST API. Objective is to avoid duplicating
>>>> resource to scope mappings elsewhere.
>>>>
>>>> 2. I basically say maintain an optional config file so that users
>>>> (sys-admins) can declare the resource to scope mappings they "want to
>>>> override only" in that file. Objective is to separate user configs from
>>>> product configs to minmize risk in someone playing with the product API.
>>>>
>>>> The pros and cons of each approach have been discussed throughly. So we
>>>> basically need more ideas from others now. Either better solutions or a
>>>> preference towards one of the suggested ones.
>>>>
>>>> On Wed, May 10, 2017 at 11:20 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>> No Sanjeewa, in the method I'm proposing the system "will not b

Re: [Architecture] [APIM][C5] Removing "Blocked" state from API lifecycle

[Ishara Cooray]

The provided workarounds for blocking an api is fine with respect to
developer p.o.v
But is it providing the proper end user experience?

End user(who is invoking the api) will not see the correct error message
unless it has sent a customized error messages for this blocking scenario.
Will not this introduce  more work for developer?

It will be only a single click for developer to make an api 'Blocked' if it
has the life cycle state and end user will also receive correct message.

So UX p.o.v i think having Blocked state is better.

wdyt?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <nuw...@wso2.com> wrote:

> Blocking an API temporarily can be a valid scenario. And we already have 3
> ways of doing it (1 for admin 2 for API developer). What I'm saying is that
> "Blocked" is never a standard state in any SDLC. So what's so special about
> an API LC? It is true that older versions of the product had this as a LC
> state, but I think it was wrong to have done that.
>
> @Lalaji, an API publisher has full control of his API. I don't think
> having a state called blocked and making it go through an approval adds a
> lot of value. Because there are many ways he can block his api, such as by
> changing the endpoint, changing the endpoint throttle limits, changing the
> code (ballerina). If I'm not approved to set a LC state as blocked, there
> are many other ways to block my API anyway. So I don't see it as a value
> addition.
>
> On Fri, May 19, 2017 at 9:37 AM, Lalaji Sureshika <lal...@wso2.com> wrote:
>
>> Hi,
>>
>> If we remove the 'blocked' state from  API lifecycle and if we keep the
>> other options [set throttling limit/ballerina config change] to do API
>> blocking,we will loose setting workflow extension to the particular blocked
>> state.[Eg scenario-acknowledge users that API is temporally blocked via a
>> custom workflow]..Isn't that with this,we are going to limit a capability?
>>
>> Thanks;
>>
>> On Thu, May 18, 2017 at 3:44 PM, Lakshman Udayakantha <lakshm...@wso2.com
>> > wrote:
>>
>>> Hi,
>>>
>>> Don't we have an extensible API lifecycle states in c5 implementation?
>>> If we have any user who doesn't want this blocked state can remove from
>>> state configuration and who wants this blocked state can keep this state in
>>> configuration.
>>> WDYT?
>>>
>>> Thanks,
>>> Lakshman
>>>
>>> On Thu, May 18, 2017 at 3:22 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>> If by any chance an API Developer wants to block his entire API
>>>> temporarily, he has two options.
>>>>
>>>> 1) Set the endpoint limit to 0req/min
>>>> 2) Use a temporary ballerina to send an error back to the customer.
>>>>
>>>> On Thu, May 18, 2017 at 12:06 PM, Sanjeewa Malalgoda <sanje...@wso2.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>>
>>>>>> I agree that "Blocked" is never a standard state in any SDLC.
>>>>>> Therefore I don't think its right to have a state called Blocked in the 
>>>>>> API
>>>>>> Lifecycle as well.
>>>>>>
>>>>> There are existing users who heavily use this feature. If we are going
>>>>> to disable then we need to provide alternative. Lets think i'm API
>>>>> developer and i have my back end service as well. At some point i realized
>>>>> my back end not performing and i will temporary set blocked state until i
>>>>> fixed issue. User will see proper message saying access is blocked then he
>>>>> can skip invoking it. If we hack throttle etc to do same then end user 
>>>>> will
>>>>> get incorrect information. Directly modify ballerina and send proper error
>>>>> message is good alternative.
>>>>>
>>>>>>
>>>>>> Blocking is always a temporary action. If you need to take off an API
>>>>>> permanently the usual practice is to deprecate and retire it. Therefore 
>>>>>> it
>>>>>> doesn't sound right to have a state called "Blocked" in the API 
>>>>>> Lifecycle.
>>>>>>
>>>>>> Moreover, I've never seen an API Publisher blocking his entire API.
>>>&g

[Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

[Ishara Cooray]

*Motivation:*
Before c5, API Manager product REST APIs resources have pre defined scopes
and they cannot be changed.

But what if an admin needs to give access to Create, Update, Delete actions
to different users?
if he can customize the scopes associated with each resource, then he will
be able to fine grain the access to each resource.



*Design:*With C5, we thought of allowing admin users to add/change scopes
in product REST APIs to meet their fine grained requirements.

At the moment we can think of two ways to do this.

   1. *Allow to edit the scopes defined per resource  *
   In this case we can copy the swagger file into conf directory at build
   time,  so that it can be maintained as a usual configuration file.

2. *Introduce a new config file to track resource to scope mapping.*
   In this case the issue is resource to scope mapping will be duplicated.

Appreciate your insight on this.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512 <+94%2077%20262%209512>
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi Ishara,

On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray <isha...@wso2.com> wrote:

> Hi,
>
> Previous versions(Before C5) of APIM Publisher, Store Apps front end
> validations were done based on user roles.
>
> But with C5 we think of fine graining User Interfaces by controlling
> access to UI components such as Add, Edit, Delete buttons/links based on
> the user scopes.
>
> 1. We need to find scopes associate with each action (REST api call). This
> can be done in two ways.
>
>- Read the scopes from swagger definition
>
>- Associate scopes with the UI component itself.
>
> Are we going to hard cord this scope for each API ?

scope associate with each resource is defined in the REST API swagger
definition. We plan to use the same scope as a custom data attribute in UI
component itself.
Even though one can enable a button by changing this attribute, it will not
be a problem as back end validation is also there.



Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Apr 25, 2017 at 9:43 AM, Nuwan Dias <nuw...@wso2.com> wrote:

> What's wrong with using OAuth2.0 scopes? The authorization requirements
> are simply to define which role/group is permitted to access a given
> resource. Which is very simply supported OOTB via scopes and the
> configuration is very simple as well.
>
> One of the key design principles here is to keep things simple. Because
> this is something almost all users of the product will be
> configuring/tweaking when setting up a deployment for real. I don't think
> everyone understands XACML. Besides, we do not need the extensive feature
> set offered by XACML for this particular API.
>
> Another key design principle here is to make the API generic so that
> anyone can easily write a UI using it. OAuth2.0 is the de facto security
> standard for REST APIs and anyone using a REST API understands it (now). So
> why move away from the standard? When developing an SPA type UI app, it is
> extremely easy to render (or not) buttons/links when the resource is
> protected via scopes. XACML makes that tougher. Actually I personally
> haven't figured out how to render the html on the client side unless I
> evaluate the XACML policy on the client side, which of course is nearly
> impossible I guess.
>
> Thanks,
> NuwanD.
>
> On Tue, Apr 25, 2017 at 8:55 AM, Harsha Thirimanna <hars...@wso2.com>
> wrote:
>
>>
>>
>> On 21 Apr 2017 5:27 p.m., "Asela Pathberiya" <as...@wso2.com> wrote:
>>
>>
>>
>> On Fri, Apr 21, 2017 at 4:46 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Hi Asela,
>>>
>>> What is reason for using scopes for authorization.. ?  Can't we use
>>> policy based approach such as XACML ?
>>>
>>> Default authentication and authorization protocol we use is oauth, hence
>>> we already have support for scopes in our REST APIs.
>>> Therefore is it straight forward to use scopes as we just need to
>>> validate UI components and it is not required to add the complexities we
>>> can have from XACML.
>>>
>>
>> What is the standard which defines the policies..  In scopes also;  you
>> need to store the authorization mapping in some where.. isn't it ?  Can't
>> we use XACML policies for that ?
>>
>>>
>> I also believe this is real use case of having XACML. Maintainability
>> wise also XACML may be easy. I don't think it will give additional
>> complexity ,because as Asela said anyway you must have this association in
>> somewhere.
>> Performance wise also XACML is good because of its caching layers in
>> different level.
>>
>>
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Thu, Apr 20, 2017 at 6:22 PM, Bhathiya Jayasekara <bhath...@wso2.com>
>>> wrote:
>>>
>>>> Hi Ishara,
>>>>
>>>> Please see my comments inline.
>>>>
>>>> On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray <isha...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Previous versions(Before C5) of APIM Publisher, Store Apps front end
>>>>> validations were done based on user roles.
>>>>>
>>>>> But with C5 we think of fine graining User Interfaces by controlling
>&

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

[Ishara Cooray]

Hi Asela,

What is reason for using scopes for authorization.. ?  Can't we use policy
based approach such as XACML ?

Default authentication and authorization protocol we use is oauth, hence we
already have support for scopes in our REST APIs.
Therefore is it straight forward to use scopes as we just need to validate
UI components and it is not required to add the complexities we can have
from XACML.



Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Apr 20, 2017 at 6:22 PM, Bhathiya Jayasekara <bhath...@wso2.com>
wrote:

> Hi Ishara,
>
> Please see my comments inline.
>
> On Thu, Apr 20, 2017 at 11:08 AM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> Hi,
>>
>> Previous versions(Before C5) of APIM Publisher, Store Apps front end
>> validations were done based on user roles.
>>
>> But with C5 we think of fine graining User Interfaces by controlling
>> access to UI components such as Add, Edit, Delete buttons/links based on
>> the user scopes.
>>
>> 1. We need to find scopes associate with each action (REST api call).
>> This can be done in two ways.
>>
>>- Read the scopes from swagger definition
>>
>>- Associate scopes with the UI component itself.
>>
>> IMO associate scopes with the UI component will be more efficient than
>> processing swagger definition while rendering UI.
>>
>
> Yes, on the other hand it'll be very hard to do this dynamically.
>
>
>>
>> 2. We need to find logged in user scopes and persists in somewhere
>>
>>- We can do a introspect call and get the user scopes.
>>
>>- We can get the roles from logged in user claims and then find
>>scopes based on role to scopes mapping
>>
>> +1 for the 1st option. In the 2nd one, we're doing the same what
> introspect service already does. So we don't have to do that again.
>
>> In both the cases we will need to persist these info in a browser
>> session.
>>
> I believe, here you meant cookies, because in our webapps there won't be a
> session, since ithey're completely client side apps.
>
>> persisting user claims will be helpful for future use cases as well.
>>
> I think there can be security issues of storing user claims in browser
> cookies.
>
>> We can use a secure cookie with HttpOnly and Secure flags enabled to
>> persist these data.
>>
> I don't think we can use HttpOnly here, because they can't be accessed by
> JS.
>
>>
>> *Implementation*
>>
>> There will be a common js function that accepts UI component and then it
>> validates against user scopes. Based on that the UI component will be
>> enabled/ disabled.
>>
>> Followings are the UI components that have identified to be validated
>> among currently available UIs.
>>
>>
>> *-Publisher-*
>>
>> 1.Create API
>> 2. API - Edit
>> 3. API - Delete
>> 4.Change Policies - Update
>> 5. Change Labels - update
>> 6. Change LC status buttons
>> 7. Endpoint Update
>>
> There will be "Endpoint - Add" too.
>
> Thanks,
> Bhathiya
>
>> 8. Resource Add
>> 9. Resource Save
>> 10. Document Add
>> 11. Document Edit/Delete
>> 12. Create new version - Add
>> 13. Access Controll - Not yet Available
>> 14. Mediation - todo
>> 15. Scripting - todo
>>
>> *-Store-*
>> 1. Application - Add
>> 2. application - View
>> 3. application - Edit
>> 4. application - Delete
>> 5. Subscription - todo
>>
>> Appreciate your thoughts.
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com <http://wso2.com>*
>
> *Phone: +94715478185 <071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> <http://www.linkedin.com/in/bhathiyaj>*
> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
> *Blog: http://movingaheadblog.blogspot.com
> <http://movingaheadblog.blogspot.com/>*
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Cooray]

Hi,

Previous versions(Before C5) of APIM Publisher, Store Apps front end
validations were done based on user roles.

But with C5 we think of fine graining User Interfaces by controlling access
to UI components such as Add, Edit, Delete buttons/links based on the user
scopes.

1. We need to find scopes associate with each action (REST api call). This
can be done in two ways.

   - Read the scopes from swagger definition

   - Associate scopes with the UI component itself.

IMO associate scopes with the UI component will be more efficient than
processing swagger definition while rendering UI.

2. We need to find logged in user scopes and persists in somewhere

   - We can do a introspect call and get the user scopes.

   - We can get the roles from logged in user claims and then find scopes
   based on role to scopes mapping

In both the cases we will need to persist these info in a browser session.
persisting user claims will be helpful for future use cases as well.

We can use a secure cookie with HttpOnly and Secure flags enabled to
persist these data.


*Implementation*

There will be a common js function that accepts UI component and then it
validates against user scopes. Based on that the UI component will be
enabled/ disabled.

Followings are the UI components that have identified to be validated among
currently available UIs.


*-Publisher-*

1.Create API
2. API - Edit
3. API - Delete
4.Change Policies - Update
5. Change Labels - update
6. Change LC status buttons
7. Endpoint Update
8. Resource Add
9. Resource Save
10. Document Add
11. Document Edit/Delete
12. Create new version - Add
13. Access Controll - Not yet Available
14. Mediation - todo
15. Scripting - todo

*-Store-*
1. Application - Add
2. application - View
3. application - Edit
4. application - Delete
5. Subscription - todo

Appreciate your thoughts.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Thanks for the update Thusitha.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Apr 4, 2017 at 8:52 AM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Ishara,
>
> We are planning to in co-operating that with the 2.3.0-m2 which scheduled
> to be released by this week.
>
> Thanks
> Thusitha
>
> On Mon, Apr 3, 2017 at 12:18 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> Hi Vidura/Thusitha,
>>
>> Can we have an update on this please?
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Mon, Jan 16, 2017 at 1:13 PM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi Sagara,
>>>
>>> ViduraN has almost implemented this. We will schedule a meeting tomorrow
>>> or day after tomorrow to discuss the current implementation.
>>>
>>> Thanks
>>> Thusitha
>>>
>>> On Mon, Jan 16, 2017 at 12:44 PM, Sagara Gunathunga <sag...@wso2.com>
>>> wrote:
>>>
>>>>
>>>> Can we have an update or review meeting on this ?
>>>>
>>>> Thanks !
>>>>
>>>>
>>>> On Thu, Jan 5, 2017 at 9:50 AM, Ishara Cooray <isha...@wso2.com> wrote:
>>>>
>>>>> Sounds good.
>>>>> Thanks Kishanthan.
>>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah <
>>>>> kishant...@wso2.com> wrote:
>>>>>
>>>>>> We are working on this. We couldn't progress much last week due to
>>>>>> other priorities. The plan is to deliver in two weeks time.
>>>>>>
>>>>>> On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray <isha...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> What could be the status of this? Do we have a time line defined?
>>>>>>>
>>>>>>> Thanks & Regards,
>>>>>>> Ishara Cooray
>>>>>>> Senior Software Engineer
>>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>>>>>> WSO2, Inc. | http://wso2.com/
>>>>>>> Lean . Enterprise . Middleware
>>>>>>>
>>>>>>> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga <sag...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda <
>>>>>>>> sanje...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>> Please find inline comments.
>>>>>>>>>
>>>>>>>>> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga <
>>>>>>>>> sag...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray <isha...@wso2.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> To overcome the above limitation where we cannot plug custom
>>>>>>>>>>> authentication, i came up with the below approach.
>>>>>>>>>>>
>>>>>>>>>>> Having one interceptor and delegate authentication to an
>>>>>>>>>>> interface. Implementation of the interface is configurable so that 
>>>>>>>>>>> we can
>>>>>>>>>>> plug custom authentication as well.
>>>>>>>>>>>
>>>>>>>>>>> [image: Inline image 1]
>>>>>>>>>>>
>>>>>>>>>>> O

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Hi Vidura/Thusitha,

Can we have an update on this please?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512 <+94%2077%20262%209512>
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Jan 16, 2017 at 1:13 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Sagara,
>
> ViduraN has almost implemented this. We will schedule a meeting tomorrow
> or day after tomorrow to discuss the current implementation.
>
> Thanks
> Thusitha
>
> On Mon, Jan 16, 2017 at 12:44 PM, Sagara Gunathunga <sag...@wso2.com>
> wrote:
>
>>
>> Can we have an update or review meeting on this ?
>>
>> Thanks !
>>
>>
>> On Thu, Jan 5, 2017 at 9:50 AM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Sounds good.
>>> Thanks Kishanthan.
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
>>>> We are working on this. We couldn't progress much last week due to
>>>> other priorities. The plan is to deliver in two weeks time.
>>>>
>>>> On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> What could be the status of this? Do we have a time line defined?
>>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga <sag...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda <sanje...@wso2.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>> Please find inline comments.
>>>>>>>
>>>>>>> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga <sag...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray <isha...@wso2.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> To overcome the above limitation where we cannot plug custom
>>>>>>>>> authentication, i came up with the below approach.
>>>>>>>>>
>>>>>>>>> Having one interceptor and delegate authentication to an
>>>>>>>>> interface. Implementation of the interface is configurable so that we 
>>>>>>>>> can
>>>>>>>>> plug custom authentication as well.
>>>>>>>>>
>>>>>>>>> [image: Inline image 1]
>>>>>>>>>
>>>>>>>>> One limitation here is we can have only one auth type active at a
>>>>>>>>> time.
>>>>>>>>>
>>>>>>>>> Hi Sanjeewa,
>>>>>>>>>
>>>>>>>>> Shall we continue with this approach until we get a proper fix
>>>>>>>>> from msf4j?
>>>>>>>>>
>>>>>>>>
>>>>>>>> It's ok to use above  approach as a temporary workaround till we
>>>>>>>> get proper solution from MSF4J, but please make sure to implement only
>>>>>>>> required features in a simple manner because you have to discard this 
>>>>>>>> and
>>>>>>>> have to use proper MSF4J approach before any release.
>>>>>>>>
>>>>>>>> By looking at issues faced by API-M and IS teams we have few issues
>>>>>>>> to solve,
>>>>>>>>
>>>>>>>>
>>>>>>>> 1. Ability to apply/skip Interceptors in global and per-service
>>>>>>>> levels
>>>>>>>> 2. Ability to define t

Re: [Architecture] [C5][APIM] Introducing labels based gateway environments in API Manager

[Ishara Cooray]

Hi Pubudu,

What will be the behavior when an api is updated

   1. From API publisher UI
   2. From the api artifact itself(if it is allowed).


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Tue, Feb 7, 2017 at 10:49 PM, Nuwan Dias <nuw...@wso2.com> wrote:

> Hi Matteo,
>
> To give you some context, this model is suggested for API Manager version
> 3.0.0 which will be on a new Carbon platform version, version 5. Its
> literarily a rewrite of the current API Manager product and hence we're
> rethinking and redesigning all features.
>
> What we're trying to achieve here is to give the ability for APIs to be
> deployed in separate zones. i.e. Internally accessible vs publicly
> accessible. How we supported this earlier was by making the API Publisher
> push APIs to Gateways in different zones when the APIs were being
> published. But deploying APIs in the API Publishing process had its own set
> of problems such as
>
> 1. When it was required to publish to many Gateway, the publishing process
> consumed a lot of time.
> 2. If the API deployment failed partially, we had to record the failures
> while still changing the state of the API. The API publishers had to later
> republish.
> 3. If a new zone is added later, the API publishers had to republish the
> APIs to the new zone.
>
> Most of these problems stemmed from the fact that we were using a "Push"
> model of APIs instead of a "Pull". The model suggested for API Manager
> 3.0.0 is a "Pull" model by which we try to achieve a lot of dynamicity and
> make the API Publishing process more robust at the same time.
>
> Thanks,
> NuwanD.
>
> On Tue, Feb 7, 2017 at 9:53 PM, Matteo Bordin <matteo.bor...@profesia.it>
> wrote:
>
>> Hello
>> why does not it be possible to use the feature “Environment”?
>> I mean the configuration into the api-manager.xml file
>> “
>> 
>> 
>> 
>> 
>> 
>> Production and Sandbox
>> This is a hybrid gateway that handles both
>> production and sandbox token traffic.
>> 
>> https://localhost:$
>> {mgt.transport.https.port}${carbon.context}services/
>> 
>> ${admin.username}
>> 
>> ${admin.password}
>> 
>> http://${carb
>> on.local.ip}:${http.nio.port},https://${carbon.local.ip}:${
>> https.nio.port}
>> 
>> 
>>  “
>>
>> So we create more than one environment, one for each “label”, the
>> configuration could be: one api gateway manager for environment and any
>> number of gateway for manager.
>> When you deploy the API you can decide where you would like to deploy
>> your API, the publisher using the admin service publish the API into the
>> correct gateway, in the store you can see the url of the gateway where you
>> have deployed the API.
>> Probably I don not understand the requirements.
>> Could you provide us a real use case?
>> This is my two cents!
>>
>> bye
>> Matteo
>>
>>
>> Matteo Bordin
>> Profesia s.r.l. - http://www.profesia.it
>> via Po, 1 - 10124 Torino (TO) Tel +39 011 0120371
>> <+39%20011%20012%200371> Fax +39 011 3710371 <+39%20011%20371%200371>
>> Piazzale Luigi Sturzo, 15 - 00144 Roma Tel +39 06 87811323
>> <+39%2006%208781%201323>
>> Cell: +39 346 017 91 68
>> Skype: matteobordin
>> eMail: matteo.bor...@profesia.it
>> —
>> “Profesia, innovation in action"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 7 Feb 2017, at 15:01, Pubudu Gunatilaka <pubu...@wso2.com> wrote:
>>
>> Hi,
>>
>> There can be situations where we need to host public gateways for public
>> traffic as well as private gateways for internal traffic. In general, there
>> can be different gateway environments which serve particular APIs. The
>> publisher can decide which API should be served by which gateway
>> environment.
>>
>> The flow is as follows.
>>
>> 
>> ​
>>
>> 1. When creating an API, the publisher can decide the labels for an API.
>> Labels can be public, private, etc. Users can define labels based on their
>> use cases. Once the  API is published, an event is published to the topic.
>> 2. Gateways are subscribed to the particular topics at the startup and
>> they will receiv

Re: [Architecture] [C5][APIM] Context Loading in API Gateway

[Ishara Cooray]

Hi Abhimaran,

Sorry for delayed response.
Please find my comments in-line.

How do we differentiate context and uriTemplates when a request sent?

For example, if a request come with below URL

https://foo.bar/test/api/request/resource

How we are going to find which is context and which is urItemplate and
check the validity?

These information could be obtained from *org.wso2.msf4j.request* at
interceptor level. And then it can be set in *PrivilegedCarbonContext* as
properties so that we can use them at the ValidationHandler.

Also, don't we need to consider HTTP verb also?
Yes, we need to consider HTTP verb also at the time of resource validation.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Jan 30, 2017 at 2:34 PM, Abimaran Kugathasan <abima...@wso2.com>
wrote:

> Hi Ishara,
>
> How do we differentiate context and uriTemplates when a request sent?
>
> For example, if a request come with below URL
>
> https://foo.bar/test/api/request/resource
>
> How we are going to find which is context and which is urItemplate and
> check the validity?
>
> Also, don't we need to consider HTTP verb also?
>
> On Mon, Jan 30, 2017 at 2:28 PM, Lakmal Warusawithana <lak...@wso2.com>
> wrote:
>
>> +1 for the approach, this is lazy loading.
>>
>> Also we should support and give an option to full api load at startup.
>> Basically we should support lazy loading and full loading which can be
>> switch via a configuration. Full loading may important for some cases which
>> need first api call return fast, but not important of having auto scaling
>> of gateways and satisfy with manual scaling.
>>
>> BTW, images are not properly loading ...
>>
>> On Mon, Jan 30, 2017 at 2:06 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> I am working on $Subject and following is the use case and the approach
>>> we are going to address.
>>>
>>> *Motivation:*
>>> In order to reduce the server startup time we thought of not loading the
>>> apis at the server startup.
>>> Then we need a way to validate api requests to avoid DOS attacks such as
>>> api requests with invalid context, passing to the api core level.
>>>
>>> *Solution:*
>>> Therefore we are planing to load summary of all apis(name, context,
>>> uriTemplates)  into memory at server startup so that when an api request
>>> comes to the gateway it will first validate the availability of that
>>> api/resource.
>>>
>>> To get the api summary info there will be Rest Service in APIM core.
>>>
>>>
>>>
>>>
>>> For newly added apis we  can update the in memory cache via a JMS Topic
>>> (later we can support for other message brokers as well) .
>>>
>>>
>>>
>>> Following components will be written to address these scenarios.
>>>
>>>
>>>1. REST Service to retrieve API summary - *API Core*
>>>2. APISummaryLoader to load APIsSummary at server startup - *GW*
>>>3. JMS Topic receiver - *Core*
>>>4. JSM topic listener - *GW*
>>>5. APIContextValidationHandler - *GW*
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Director - Cloud Architecture; WSO2 Inc.
>> Mobile : +94714289692 <+94%2071%20428%209692>
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer - API Technologies
>
> Email : abima...@wso2.com
> Mobile : +94 773922820 <+94%2077%20392%202820>
>
> <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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][APIM] Context Loading in API Gateway

[Ishara Cooray]

Also we should support and give an option to full api load at startup.
Basically we should support lazy loading and full loading which can be
switch via a configuration. Full loading may important for some cases which
need first api call return fast, but not important of having auto scaling
of gateways and satisfy with manual scaling.

+1

BTW, images are not properly loading ...

Re-attaching the missing images 1 and 2 respectively.

[image: Inline image 1]


[image: Inline image 2]

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Jan 30, 2017 at 2:28 PM, Lakmal Warusawithana <lak...@wso2.com>
wrote:

> +1 for the approach, this is lazy loading.
>
> Also we should support and give an option to full api load at startup.
> Basically we should support lazy loading and full loading which can be
> switch via a configuration. Full loading may important for some cases which
> need first api call return fast, but not important of having auto scaling
> of gateways and satisfy with manual scaling.
>
> BTW, images are not properly loading ...
>
> On Mon, Jan 30, 2017 at 2:06 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> Hi,
>>
>> I am working on $Subject and following is the use case and the approach
>> we are going to address.
>>
>> *Motivation:*
>> In order to reduce the server startup time we thought of not loading the
>> apis at the server startup.
>> Then we need a way to validate api requests to avoid DOS attacks such as
>> api requests with invalid context, passing to the api core level.
>>
>> *Solution:*
>> Therefore we are planing to load summary of all apis(name, context,
>> uriTemplates)  into memory at server startup so that when an api request
>> comes to the gateway it will first validate the availability of that
>> api/resource.
>>
>> To get the api summary info there will be Rest Service in APIM core.
>>
>>
>>
>>
>> For newly added apis we  can update the in memory cache via a JMS Topic
>> (later we can support for other message brokers as well) .
>>
>>
>>
>> Following components will be written to address these scenarios.
>>
>>
>>1. REST Service to retrieve API summary - *API Core*
>>2. APISummaryLoader to load APIsSummary at server startup - *GW*
>>3. JMS Topic receiver - *Core*
>>4. JSM topic listener - *GW*
>>5. APIContextValidationHandler - *GW*
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Lakmal Warusawithana
> Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692 <+94%2071%20428%209692>
> Blog : http://lakmalsview.blogspot.com/
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [C5][APIM] Context Loading in API Gateway

[Ishara Cooray]

Hi,

I am working on $Subject and following is the use case and the approach we
are going to address.

*Motivation:*
In order to reduce the server startup time we thought of not loading the
apis at the server startup.
Then we need a way to validate api requests to avoid DOS attacks such as
api requests with invalid context, passing to the api core level.

*Solution:*
Therefore we are planing to load summary of all apis(name, context,
uriTemplates)  into memory at server startup so that when an api request
comes to the gateway it will first validate the availability of that
api/resource.

To get the api summary info there will be Rest Service in APIM core.




For newly added apis we  can update the in memory cache via a JMS Topic
(later we can support for other message brokers as well) .



Following components will be written to address these scenarios.


   1. REST Service to retrieve API summary - *API Core*
   2. APISummaryLoader to load APIsSummary at server startup - *GW*
   3. JMS Topic receiver - *Core*
   4. JSM topic listener - *GW*
   5. APIContextValidationHandler - *GW*


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512 <+94%2077%20262%209512>
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Sounds good.
Thanks Kishanthan.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Jan 4, 2017 at 5:30 PM, Kishanthan Thangarajah <kishant...@wso2.com>
wrote:

> We are working on this. We couldn't progress much last week due to other
> priorities. The plan is to deliver in two weeks time.
>
> On Tue, Jan 3, 2017 at 1:40 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> Hi,
>>
>> What could be the status of this? Do we have a time line defined?
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga <sag...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
>>> wrote:
>>>
>>>> Hi All,
>>>> Please find inline comments.
>>>>
>>>> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga <sag...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray <isha...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> To overcome the above limitation where we cannot plug custom
>>>>>> authentication, i came up with the below approach.
>>>>>>
>>>>>> Having one interceptor and delegate authentication to an interface.
>>>>>> Implementation of the interface is configurable so that we can plug 
>>>>>> custom
>>>>>> authentication as well.
>>>>>>
>>>>>> [image: Inline image 1]
>>>>>>
>>>>>> One limitation here is we can have only one auth type active at a
>>>>>> time.
>>>>>>
>>>>>> Hi Sanjeewa,
>>>>>>
>>>>>> Shall we continue with this approach until we get a proper fix from
>>>>>> msf4j?
>>>>>>
>>>>>
>>>>> It's ok to use above  approach as a temporary workaround till we get
>>>>> proper solution from MSF4J, but please make sure to implement only 
>>>>> required
>>>>> features in a simple manner because you have to discard this and have to
>>>>> use proper MSF4J approach before any release.
>>>>>
>>>>> By looking at issues faced by API-M and IS teams we have few issues to
>>>>> solve,
>>>>>
>>>>>
>>>>> 1. Ability to apply/skip Interceptors in global and per-service levels
>>>>> 2. Ability to define the order of Interceptors
>>>>> 3. Ability to intercept response messages
>>>>>
>>>> Ability to build security and user context in a way we can access it
>>>> from service implementation.
>>>> Most of the other platforms allowed to do that and people who work on
>>>> service implementation can get real advantage of that.
>>>>
>>>>>
>>>>> The good news is JAX-RS 2.0 spec is already solved these issues and we
>>>>> can adopt their concepts easily to MSF4J programming model. Please refer
>>>>> solution for each issue below.
>>>>>
>>>>>
>>>>> *1. Ability to intercept response messages *
>>>>>
>>>>> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
>>>>> ContainerResponseFilter[2] to intercept request and response messages, IMO
>>>>> these 2 interfaces are much clean and standard then current MSF4J
>>>>> Interceptor[3] concept where response intercepting is not simple.
>>>>>
>>>>>
>>>>> *2.  Ability to apply/skip Interceptors  in global and per-service
>>>>> levels *
>>>>>
>>>>> Annotation driven NameBinding[4] concept defined for JAX-RS Filters is
>>>>> very flexible and easy to use as well. This NameBinding[4] feature enables
>>>>> to apply JAX-RS Filters at global, per-Resource or even per-sub-Resource
>>>>> level.
>>>>>
>>>>> *3. Define the order of Interceptors *
>>>>>
>>>>> JAX-RS defines several message processing extension points such as
>>>>> Pre, Pr

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Hi,

What could be the status of this? Do we have a time line defined?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, Dec 9, 2016 at 2:18 PM, Sagara Gunathunga <sag...@wso2.com> wrote:

>
>
> On Fri, Dec 9, 2016 at 2:15 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>
>> Hi All,
>> Please find inline comments.
>>
>> On Fri, Dec 9, 2016 at 12:49 PM, Sagara Gunathunga <sag...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>>
>>>> To overcome the above limitation where we cannot plug custom
>>>> authentication, i came up with the below approach.
>>>>
>>>> Having one interceptor and delegate authentication to an interface.
>>>> Implementation of the interface is configurable so that we can plug custom
>>>> authentication as well.
>>>>
>>>> [image: Inline image 1]
>>>>
>>>> One limitation here is we can have only one auth type active at a time.
>>>>
>>>> Hi Sanjeewa,
>>>>
>>>> Shall we continue with this approach until we get a proper fix from
>>>> msf4j?
>>>>
>>>
>>> It's ok to use above  approach as a temporary workaround till we get
>>> proper solution from MSF4J, but please make sure to implement only required
>>> features in a simple manner because you have to discard this and have to
>>> use proper MSF4J approach before any release.
>>>
>>> By looking at issues faced by API-M and IS teams we have few issues to
>>> solve,
>>>
>>>
>>> 1. Ability to apply/skip Interceptors in global and per-service levels
>>> 2. Ability to define the order of Interceptors
>>> 3. Ability to intercept response messages
>>>
>> Ability to build security and user context in a way we can access it from
>> service implementation.
>> Most of the other platforms allowed to do that and people who work on
>> service implementation can get real advantage of that.
>>
>>>
>>> The good news is JAX-RS 2.0 spec is already solved these issues and we
>>> can adopt their concepts easily to MSF4J programming model. Please refer
>>> solution for each issue below.
>>>
>>>
>>> *1. Ability to intercept response messages *
>>>
>>> JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and
>>> ContainerResponseFilter[2] to intercept request and response messages, IMO
>>> these 2 interfaces are much clean and standard then current MSF4J
>>> Interceptor[3] concept where response intercepting is not simple.
>>>
>>>
>>> *2.  Ability to apply/skip Interceptors  in global and per-service
>>> levels *
>>>
>>> Annotation driven NameBinding[4] concept defined for JAX-RS Filters is
>>> very flexible and easy to use as well. This NameBinding[4] feature enables
>>> to apply JAX-RS Filters at global, per-Resource or even per-sub-Resource
>>> level.
>>>
>>> *3. Define the order of Interceptors *
>>>
>>> JAX-RS defines several message processing extension points such as Pre,
>>> PreMatch, Post, it's possible to apply Filters during some of these message
>>> processing stages, as an example refer PreMatching[5] annotation.
>>>
>>> Further, to define fine grained order of Filters JAX-RS reuse Java's
>>> standard Priority[1] annotation, through this annotation numeric priority
>>> value can be define per Filters basis. JAX-RS already provide set of
>>> pre-defined Priories here[6]
>>>
>> Ability to engage in different phases is definitely a good feature. But
>> there can be situations where we need to engage multiple interceptors at
>> same phase with order of execution. As example i need to engage both
>> authenticate and authorization interceptors in pre invoke phase but
>> authenticator first and then authorizer as 2nd interceptor. In that case we
>> need to mention phase and order within phase in some way. It seems CXF and
>> other run times already handled this in different ways.
>>
>
> This requirement is well handled by the JAX-RS concept I described above.
>
> Thanks !
>
>>
>>
>> [1]http://cxf.apache.org/docs/interceptors.html
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>>
>>> I have setup a meeting in next Wednesday

Re: [Architecture] [APIM][C5] How to define REST services host , port properties in configuration bean?

[Ishara Cooray]

Thanks Danesh.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, Dec 23, 2016 at 1:06 PM, Danesh Kuruppu <dan...@wso2.com> wrote:

> Hi Ishara,
>
> You can set those variable values in configuration bean constructor.
> Inside the constructor, you read the system properties and assign it to the
> variable.
>
> Thanks
> Danesh
>
> On Fri, Dec 23, 2016 at 12:10 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> With the new Global configuration model in carbon 5.2.0, we need to
>> define default values for configurations in configuration bean.
>>
>> Earlier we used to have some configurations as system properties.
>> For instance we define token url as
>>
>>
>>
>> * tokenURL = "https://${carbon.local.ip}:${https.nio.port}/token"*
>> In C5, what could be the best way to define such properties in
>> configuration bean classes.
>>
>> Can we get the ip and port + port offset from carbonConfiguration and
>> append to derive the value?
>> Or is there a better way to do this as string concatenation is costly?
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc <https://wso2.com/signature>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM][C5] How to define REST services host , port properties in configuration bean?

[Ishara Cooray]

With the new Global configuration model in carbon 5.2.0, we need to define
default values for configurations in configuration bean.

Earlier we used to have some configurations as system properties.
For instance we define token url as



* tokenURL = "https://${carbon.local.ip}:${https.nio.port}/token"*
In C5, what could be the best way to define such properties in
configuration bean classes.

Can we get the ip and port + port offset from carbonConfiguration and
append to derive the value?
Or is there a better way to do this as string concatenation is costly?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Please find my comments in line.

Yes for the moment lets use this approach. Lets have 2 interceptors for
authenticate and authorization. From that lets provide way to add pluggable
authenticators and authorizers.
I guess you mean having two interfaces for authenticate and
authorization.What if we have two methods in one interface?Otherwise  we
will have to maintain two configurations.

Also we may be able to route request through multiple authenticators
according to predefined order(when we need to support multiple auth types
at once).
+1

Also its better both identity and APIM can use same approach as we all are
doing same thing.
Identity team is writing JAAS Login Modules
@Thanuja,
Do you have any input here

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512 <+94%2077%20262%209512>
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Dec 8, 2016 at 9:06 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> Yes for the moment lets use this approach. Lets have 2 interceptors for
> authenticate and authorization. From that lets provide way to add pluggable
> authenticators and authorizers.
> Also we may be able to route request through multiple authenticators
> according to predefined order(when we need to support multiple auth types
> at once).
> Also its better both identity and APIM can use same approach as we all are
> doing same thing.
>
>
> Thanks,
> sanjeewa.
>
> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> To overcome the above limitation where we cannot plug custom
>> authentication, i came up with the below approach.
>>
>> Having one interceptor and delegate authentication to an interface.
>> Implementation of the interface is configurable so that we can plug custom
>> authentication as well.
>>
>> [image: Inline image 1]
>>
>> One limitation here is we can have only one auth type active at a time.
>>
>> Hi Sanjeewa,
>>
>> Shall we continue with this approach until we get a proper fix from msf4j?
>> ​
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Hi Thilina,
>>>>
>>>> And also if there are multiple interceptors and one interceptor returns
>>>> false from its' preCaall then the invocation chain will not continue
>>>> further.
>>>>
>>>> So Is this implies if preCall returns 'true' then the invocation chain
>>>> will continue further?
>>>>
>>>
>>> Yes
>>>
>>> I was thinking to return 'true' if particular auth header type(Basic,
>>> Bearer) is not found in an interceptor, so that it will check the other
>>> available interceptors.
>>> But i guess this approach may also fail if the request header type is
>>> not provided may be by mistake.
>>> Because all the interceptors will return true and will it be taken as a
>>> valid authorization?
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez <az...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>>>
>>>>> Hi Thilina,
>>>>>
>>>>> And also if there are multiple interceptors and one interceptor
>>>>> returns false from its' preCaall then the invocation chain will not
>>>>> continue further.
>>>>>
>>>>> So Is this implies if preCall returns 'true' then the invocation chain
>>>>> will continue further?
>>>>>
>>>>
>>>> Yes
>>>>
>>>>
>>>>> If that is the case we can return true in our overridden preCall
>>>>> method so that it goes to next Interceptor.
>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512 <077%20262%209512>
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>&g

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

To overcome the above limitation where we cannot plug custom
authentication, i came up with the below approach.

Having one interceptor and delegate authentication to an interface.
Implementation of the interface is configurable so that we can plug custom
authentication as well.

[image: Inline image 1]

One limitation here is we can have only one auth type active at a time.

Hi Sanjeewa,

Shall we continue with this approach until we get a proper fix from msf4j?
​


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray <isha...@wso2.com> wrote:

> Hi Thilina,
>>
>> And also if there are multiple interceptors and one interceptor returns
>> false from its' preCaall then the invocation chain will not continue
>> further.
>>
>> So Is this implies if preCall returns 'true' then the invocation chain
>> will continue further?
>>
>
> Yes
>
> I was thinking to return 'true' if particular auth header type(Basic,
> Bearer) is not found in an interceptor, so that it will check the other
> available interceptors.
> But i guess this approach may also fail if the request header type is not
> provided may be by mistake.
> Because all the interceptors will return true and will it be taken as a
> valid authorization?
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez <az...@wso2.com> wrote:
>
>>
>>
>> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Hi Thilina,
>>>
>>> And also if there are multiple interceptors and one interceptor returns
>>> false from its' preCaall then the invocation chain will not continue
>>> further.
>>>
>>> So Is this implies if preCall returns 'true' then the invocation chain
>>> will continue further?
>>>
>>
>> Yes
>>
>>
>>> If that is the case we can return true in our overridden preCall method
>>> so that it goes to next Interceptor.
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez <az...@wso2.com> wrote:
>>>
>>>> How about supporting JAXRS filters?
>>>>
>>>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
>>>> thusit...@wso2.com> wrote:
>>>>
>>>>> Hi Ishara,
>>>>>
>>>>> As you have mentioned, with the current architecture we can't set the
>>>>> specific interceptor for a particular service but rather to all services 
>>>>> in
>>>>> the registry. And also if there are multiple interceptors and one
>>>>> interceptor returns false from its' preCaall then the invocation chain 
>>>>> will
>>>>> not continue further.
>>>>>
>>>>> IMHO we have few options
>>>>>
>>>>>- We can implement a way to register specific interceptors to
>>>>>specific services
>>>>>- We can support JAX-RS Filters
>>>>>- We can provide a way to skip some interceptors for specific
>>>>>services
>>>>>
>>>>> @Azeez WDYT?
>>>>>
>>>>> Thanks
>>>>> Thusitha
>>>>>
>>>>>
>>>>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray <isha...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> HI,
>>>>>>
>>>>>> We are using MSF4J interceptor for securing REST APIs in API Manager.
>>>>>> [1] As for now Interceptor registration happens at the class level
>>>>>> @Component annotation as below.
>>>>>>
>>>>>> @Component(
>>>>>> name = "org.wso2.carbon.apimgt.rest.a
>>>>>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>>>>>> service = Interceptor.class,
>>>>>> immediate = true
>>>>>> )
>>>>>> The limitation

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

>
> Hi Thilina,
>
> And also if there are multiple interceptors and one interceptor returns
> false from its' preCaall then the invocation chain will not continue
> further.
>
> So Is this implies if preCall returns 'true' then the invocation chain
> will continue further?
>

Yes

I was thinking to return 'true' if particular auth header type(Basic,
Bearer) is not found in an interceptor, so that it will check the other
available interceptors.
But i guess this approach may also fail if the request header type is not
provided may be by mistake.
Because all the interceptors will return true and will it be taken as a
valid authorization?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez <az...@wso2.com> wrote:

>
>
> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> Hi Thilina,
>>
>> And also if there are multiple interceptors and one interceptor returns
>> false from its' preCaall then the invocation chain will not continue
>> further.
>>
>> So Is this implies if preCall returns 'true' then the invocation chain
>> will continue further?
>>
>
> Yes
>
>
>> If that is the case we can return true in our overridden preCall method
>> so that it goes to next Interceptor.
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez <az...@wso2.com> wrote:
>>
>>> How about supporting JAXRS filters?
>>>
>>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
>>> thusit...@wso2.com> wrote:
>>>
>>>> Hi Ishara,
>>>>
>>>> As you have mentioned, with the current architecture we can't set the
>>>> specific interceptor for a particular service but rather to all services in
>>>> the registry. And also if there are multiple interceptors and one
>>>> interceptor returns false from its' preCaall then the invocation chain will
>>>> not continue further.
>>>>
>>>> IMHO we have few options
>>>>
>>>>- We can implement a way to register specific interceptors to
>>>>specific services
>>>>- We can support JAX-RS Filters
>>>>- We can provide a way to skip some interceptors for specific
>>>>services
>>>>
>>>> @Azeez WDYT?
>>>>
>>>> Thanks
>>>> Thusitha
>>>>
>>>>
>>>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray <isha...@wso2.com>
>>>> wrote:
>>>>
>>>>> HI,
>>>>>
>>>>> We are using MSF4J interceptor for securing REST APIs in API Manager.
>>>>> [1] As for now Interceptor registration happens at the class level
>>>>> @Component annotation as below.
>>>>>
>>>>> @Component(
>>>>> name = "org.wso2.carbon.apimgt.rest.a
>>>>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>>>>> service = Interceptor.class,
>>>>> immediate = true
>>>>> )
>>>>> The limitations here are
>>>>>
>>>>>1. it is not possible to have more than one interceptor that will
>>>>>dynamically pick when an api call is received(Because the order 
>>>>> matters and
>>>>>we are not certain which interceptor will take into effect ).
>>>>>2. We cannot explicitly configure to use Custom interceptors
>>>>>because of the above[1] reason.
>>>>>
>>>>> Do we have any plans for these limitations?
>>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> d...@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thusit

Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.

[Ishara Cooray]

Hi Thilina,

And also if there are multiple interceptors and one interceptor returns
false from its' preCaall then the invocation chain will not continue
further.

So Is this implies if preCall returns 'true' then the invocation chain will
continue further?
If that is the case we can return true in our overridden preCall method so
that it goes to next Interceptor.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez <az...@wso2.com> wrote:

> How about supporting JAXRS filters?
>
> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi Ishara,
>>
>> As you have mentioned, with the current architecture we can't set the
>> specific interceptor for a particular service but rather to all services in
>> the registry. And also if there are multiple interceptors and one
>> interceptor returns false from its' preCaall then the invocation chain will
>> not continue further.
>>
>> IMHO we have few options
>>
>>- We can implement a way to register specific interceptors to
>>specific services
>>- We can support JAX-RS Filters
>>- We can provide a way to skip some interceptors for specific services
>>
>> @Azeez WDYT?
>>
>> Thanks
>> Thusitha
>>
>>
>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> HI,
>>>
>>> We are using MSF4J interceptor for securing REST APIs in API Manager.
>>> [1] As for now Interceptor registration happens at the class level
>>> @Component annotation as below.
>>>
>>> @Component(
>>> name = "org.wso2.carbon.apimgt.rest.a
>>> pi.common.interceptors.OAUTH2SecurityInterceptor",
>>> service = Interceptor.class,
>>> immediate = true
>>> )
>>> The limitations here are
>>>
>>>1. it is not possible to have more than one interceptor that will
>>>dynamically pick when an api call is received(Because the order matters 
>>> and
>>>we are not certain which interceptor will take into effect ).
>>>2. We cannot explicitly configure to use Custom interceptors because
>>>of the above[1] reason.
>>>
>>> Do we have any plans for these limitations?
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Thusitha Dayaratne
>> Software Engineer
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> Mobile  +94712756809 <071%20275%206809>
>> Blog  alokayasoya.blogspot.com
>> Abouthttp://about.me/thusithathilina
>> <http://wso2.com/signature>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Afkham Azeez*
> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>*
> *email: **az...@wso2.com* <az...@wso2.com>
> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: *
> *http://blog.afkham.org* <http://blog.afkham.org>
> *twitter: **http://twitter.com/afkham_azeez*
> <http://twitter.com/afkham_azeez>
> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
> <http://lk.linkedin.com/in/afkhamazeez>*
>
> *Lean . Enterprise . Middleware*
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Authentication and Authorization for Rest APIs in Carbon Products

[Ishara Cooray]

Hi Johann,

Assuming this implementation is for C5,

Since API Manager REST APIs are written as micro services we thought of
using msf4j security interceptors for securing REST apis.
It uses introspect endpoint to get the authentication/authorization info.

How the proposed implementation would help in this scenario?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Nov 10, 2016 at 11:40 AM, Nuwan Dias <nuw...@wso2.com> wrote:

> Hi Johann,
>
> I think it would help if you can come up with a sequence diagram which
> explains the exact points in the authentication/authorization process and
> what they actually do :).
>
> Although we decide the granularity of our resource permissions, when it
> comes to customer deployments the granularity we define would be too
> coarse-grained for some customers and too fine-grained for some others.
> Basically the carbon permissions strings we define may or may not be
> sufficient. They may want to define their own and configure. And what
> customers have at their end are users and their groups. So what they would
> at the end of the day do is to map their user groups with these resources
> directly or indirectly. Can you explain the steps needed to be performed by
> a customer to define their own carbon permission (assume they require a new
> one) and how they would map their groups to these resources?
>
> When it comes to REST API resources, having /t/tenantdomain is not
> natural. Therefore I don't think we should mandate having the tenant domain
> in the resource URI. Besides, this model is for C5 right? In which case I
> assume there aren't cases where one tenant accesses services of another
> tenant as such?
>
> Thanks,
> NuwanD.
>
> On Thu, Nov 10, 2016 at 9:21 AM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Authentication and authorization are common requirements for Rest APIs.
>> Since SOAP was the common API standard so far in C4, when it comes to Rest
>> APIs, each product has implemented its own authentication and authorization
>> mechanism. In Identity server so far we haven't had a common authentication
>> and authorization module for Rest APIs. SCIM and OAuth2 Token endpoints
>> were the only Rest APIs in IS so far which had built in authentication and
>> authorization.
>>
>> For IS 5.3.0 we added more Rest APIs and needed a common authentication
>> and authorization module which is externalized, extensible and
>> configuration driven for all the authorization requirements we have had so
>> far.
>>
>> The approach we took for authentication is to write a OSGi service and
>> expose a Java API, which takes in a defined object model which will do the
>> authentication and return the result. Behind the service API we have
>> provided an SPI to plug-in authenticators such as Basic Auth, OAuth2, etc.
>> The clients of this API can be a cxf filter, cxf interceptor, servlet
>> filter or tomcat valve. You can use which ever you want depending on your
>> use case. We can use the relevant configuration files for filters,
>> interceptors, valves, etc. to configure the context paths which need
>> authentication for.
>>
>> Currently we have 3 authenticator implementations.
>> 1. Username/Password
>> 2. OAuth2
>> 3. X509 -
>> Although technically it is possible to authenticate the end user using
>> X509 certificates, by having a certificate per user and authenticating the
>> user using the CN of the certificate, practically we don't use X509
>> authentication that way. How we use it in practice is,
>>
>> A. Client certificate authentication without username
>>
>> This approach is used when there is no end user based authorization
>> requirements. As long as the client who is sending the request is trusted
>> and valid. E.g.
>>
>> B. Client certificate authentication with username (trusted sub-system)
>>
>> This is required when there are authorization requirements based on end
>> user. Basically we trust the client that it has authenticated the user
>> successfully and IS will only do the authorization for the user.
>>
>>
>> Another two authenticators in the pipeline are "System User" and "Signed
>> JWT" authenticator. "System User" authenticator means having couple of
>> system wide usernames and passwords that is configured in a text file and
>> secured, which client can authenticate with.
>>
>> For authorization we have provided another OSGi service API, which will
>> also takes in a defined object model and returns the

[Architecture] [C5][APIM] REST API scope validation

[Ishara Cooray]

Hi,

According to the current APIM 2.0 implementation it supports Swagger 2.0
yet using the old custom security definition
*x-wso2-security*
Swagger 2.0 we can use a declaration of the security schemes as below.

api_key:
  type: apiKey
  name: api_key
  in: headerpetstore_auth:
  type: oauth2
  authorizationUrl: http://swagger.io/api/oauth/dialog
  flow: implicit
  scopes:
write:pets: modify pets in your account
read:pets: read your pets

But this *does not have* the support for *roles* as we do in custom
security definition *x-wso2-security *as below.
x-wso2-security:
  apim:
x-wso2-scopes:
  - description: ""
roles: admin
name: apim:api_view
key: apim:api_view

According to the current REST API scope validation implementation [1] it
only validates scopes but not roles.

So for C5 what could be the definition to supported?
 I think we can drop *x-wso2-security *and stick to Swagger OOTB support
but again there should be a custom way to support roles.

Or shall we continue to use *x-wso2-security *until Swagger OOTB support
for roles?

Appreciate your input on this.


[1]
https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.rest.api.util/src/main/java/org/wso2/carbon/apimgt/rest/api/util/impl/WebAppAuthenticatorImpl.java

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] OSGI Service to provision users and roles based on the SAML response.

[Ishara Cooray]

Hi Ishara,

There is an extension point if the logic needs to be customized. where it
can implement SAML2SSOUserProvisioner interface and override the
provisionUser method.

And it can be configured in the configuration "SAML2SSOUserProvisionerImpl"
that is used to get the impl class at runtime.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Thu, Sep 29, 2016 at 1:15 PM, Ishara Karunarathna <isha...@wso2.com>
wrote:

> Hi Ishara,
>
> Just noticed the thread.
> Is there a extension point in this component to add any additional check.
> Let say we define a policy to decide the condition that need to be
> evaluate before doing the jit operation.
>
> If jit not available can we have that as well.
>
> Thanks,
> Ishara
>
> On Mon, Sep 26, 2016 at 4:52 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> Hi Johann,
>>
>> I have written a custom OSGI service that can be used to provision users
>> based on the SAML response which i can contribute since it is reusable in
>> any application that needs user provision.
>>
>> Appreciate if you can suggest me suitable repository for this.
>>
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Mon, Sep 5, 2016 at 10:47 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Thanks for all your inputs.
>>>
>>> This is an independent osgi service and it does not implement
>>> CarbonServerAuthenticator because it needs to integrate with any jaggery
>>> app such as apim store /publisher, greg store/publisher.
>>>
>>> Yes, it calls external java code(the provision service) from jaggery_acs
>>> file and do jit operation.
>>> It provisions users to a central location that can be configured as
>>> 'ProvisioningDefaultUserstore'
>>>
>>> As the current scope this was written for the super tenant mode only.
>>> But we can extend it to tenant mode as well.
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Mon, Sep 5, 2016 at 7:36 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
>>> wrote:
>>>
>>>> Even with current application implementation you may call external java
>>>> code from jaggery_acs file and do jit operation. If need you may add
>>>> assertion/ response validation from same java component.
>>>>
>>>> Did we think how this should work in multi tenants scenario. Do we
>>>> provision users to central place or tenant defined user store? Then can
>>>> they configure this per tenant basis?
>>>>
>>>> Thanks
>>>> sanjeewa.
>>>>
>>>> Sent from my phone.
>>>>
>>>> On Sep 5, 2016 1:25 PM, "Johann Nallathamby" <joh...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 5, 2016 at 1:19 PM, Malaka Silva <mal...@wso2.com> wrote:
>>>>>
>>>>>> Hi Ishara,
>>>>>>
>>>>>> I guess we can use application-authentication.xml for this purpose?
>>>>>>
>>>>>> We are maintaining the configs for local authenticators from store.
>>>>>>
>>>>>
>>>>> This is the old carbon authenticators we are talking about.
>>>>> application-authentication.xml is for the new authentication framework.
>>>>> That won't work for this.
>>>>>
>>>>>
>>>>>>
>>>>>> On Mon, Sep 5, 2016 at 10:21 AM, Dimuthu Leelarathne <
>>>>>> dimut...@wso2.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Ishara,
>>>>>>>
>>>>>>> On Fri, Sep 2, 2016 at 11:19 AM, Ishara Cooray <isha...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I thought of introducing a new Authenticator config to
>>>>>>>> repository/conf/security/authenticators.xml
>>>>>>>> And it will use only below properties to do the $Subject.
>>

Re: [Architecture] [Dev] OSGI Service to provision users and roles based on the SAML response.

[Ishara Cooray]

Hi Johann,

I have written a custom OSGI service that can be used to provision users
based on the SAML response which i can contribute since it is reusable in
any application that needs user provision.

Appreciate if you can suggest me suitable repository for this.



Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Sep 5, 2016 at 10:47 PM, Ishara Cooray <isha...@wso2.com> wrote:

> Thanks for all your inputs.
>
> This is an independent osgi service and it does not implement
> CarbonServerAuthenticator because it needs to integrate with any jaggery
> app such as apim store /publisher, greg store/publisher.
>
> Yes, it calls external java code(the provision service) from jaggery_acs
> file and do jit operation.
> It provisions users to a central location that can be configured as
> 'ProvisioningDefaultUserstore'
>
> As the current scope this was written for the super tenant mode only. But
> we can extend it to tenant mode as well.
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Mon, Sep 5, 2016 at 7:36 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>
>> Even with current application implementation you may call external java
>> code from jaggery_acs file and do jit operation. If need you may add
>> assertion/ response validation from same java component.
>>
>> Did we think how this should work in multi tenants scenario. Do we
>> provision users to central place or tenant defined user store? Then can
>> they configure this per tenant basis?
>>
>> Thanks
>> sanjeewa.
>>
>> Sent from my phone.
>>
>> On Sep 5, 2016 1:25 PM, "Johann Nallathamby" <joh...@wso2.com> wrote:
>>
>>>
>>>
>>> On Mon, Sep 5, 2016 at 1:19 PM, Malaka Silva <mal...@wso2.com> wrote:
>>>
>>>> Hi Ishara,
>>>>
>>>> I guess we can use application-authentication.xml for this purpose?
>>>>
>>>> We are maintaining the configs for local authenticators from store.
>>>>
>>>
>>> This is the old carbon authenticators we are talking about.
>>> application-authentication.xml is for the new authentication framework.
>>> That won't work for this.
>>>
>>>
>>>>
>>>> On Mon, Sep 5, 2016 at 10:21 AM, Dimuthu Leelarathne <dimut...@wso2.com
>>>> > wrote:
>>>>
>>>>>
>>>>> Hi Ishara,
>>>>>
>>>>> On Fri, Sep 2, 2016 at 11:19 AM, Ishara Cooray <isha...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I thought of introducing a new Authenticator config to
>>>>>> repository/conf/security/authenticators.xml
>>>>>> And it will use only below properties to do the $Subject.
>>>>>>
>>>>>> 
>>>>>>     9
>>>>>> 
>>>>>> http
>>>>>> ://wso2.org/claims/role
>>>>>> ,
>>>>>>     true
>>>>>> PRIMARY
>>>>>> 
>>>>>> 
>>>>>>
>>>>>> Any objections?
>>>>>>
>>>>>
>>>>> I think the existing SAMLSSOAuthenticator should allow JIT
>>>>> provisioning when we switch on a configuration. If we keep adding more and
>>>>> more Authenticators for small functionalities it will be cluttered
>>>>> collection in the end. The same happened to Carbon components. We have so
>>>>> many components and can't make the head or tail out of it.
>>>>>
>>>>> thanks,
>>>>> Dimuthu
>>>>>
>>>>>
>>>>>> Thanks & Regards,
>>>>>> Ishara Cooray
>>>>>> Senior Software Engineer
>>>>>> Mobile : +9477 262 9512
>>>>>> WSO2, Inc. | http://wso2.com/
>>>>>> Lean . Enterprise . Middleware
>>>>>>
>>>>>> On Wed, Aug 31, 2016 at 1:43 PM, Ishara Cooray <isha...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> + Prabath, Johann
>>>>>>>
>>>>>>> Thanks & Regards,
>>>>&g

Re: [Architecture] [Dev] OSGI Service to provision users and roles based on the SAML response.

[Ishara Cooray]

Thanks for all your inputs.

This is an independent osgi service and it does not implement
CarbonServerAuthenticator because it needs to integrate with any jaggery
app such as apim store /publisher, greg store/publisher.

Yes, it calls external java code(the provision service) from jaggery_acs
file and do jit operation.
It provisions users to a central location that can be configured as
'ProvisioningDefaultUserstore'

As the current scope this was written for the super tenant mode only. But
we can extend it to tenant mode as well.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Sep 5, 2016 at 7:36 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> Even with current application implementation you may call external java
> code from jaggery_acs file and do jit operation. If need you may add
> assertion/ response validation from same java component.
>
> Did we think how this should work in multi tenants scenario. Do we
> provision users to central place or tenant defined user store? Then can
> they configure this per tenant basis?
>
> Thanks
> sanjeewa.
>
> Sent from my phone.
>
> On Sep 5, 2016 1:25 PM, "Johann Nallathamby" <joh...@wso2.com> wrote:
>
>>
>>
>> On Mon, Sep 5, 2016 at 1:19 PM, Malaka Silva <mal...@wso2.com> wrote:
>>
>>> Hi Ishara,
>>>
>>> I guess we can use application-authentication.xml for this purpose?
>>>
>>> We are maintaining the configs for local authenticators from store.
>>>
>>
>> This is the old carbon authenticators we are talking about.
>> application-authentication.xml is for the new authentication framework.
>> That won't work for this.
>>
>>
>>>
>>> On Mon, Sep 5, 2016 at 10:21 AM, Dimuthu Leelarathne <dimut...@wso2.com>
>>> wrote:
>>>
>>>>
>>>> Hi Ishara,
>>>>
>>>> On Fri, Sep 2, 2016 at 11:19 AM, Ishara Cooray <isha...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I thought of introducing a new Authenticator config to
>>>>> repository/conf/security/authenticators.xml
>>>>> And it will use only below properties to do the $Subject.
>>>>>
>>>>> 
>>>>> 9
>>>>> 
>>>>> http
>>>>> ://wso2.org/claims/role
>>>>> ,
>>>>> true
>>>>>     PRIMARY
>>>>> 
>>>>> 
>>>>>
>>>>> Any objections?
>>>>>
>>>>
>>>> I think the existing SAMLSSOAuthenticator should allow JIT provisioning
>>>> when we switch on a configuration. If we keep adding more and more
>>>> Authenticators for small functionalities it will be cluttered collection in
>>>> the end. The same happened to Carbon components. We have so many components
>>>> and can't make the head or tail out of it.
>>>>
>>>> thanks,
>>>> Dimuthu
>>>>
>>>>
>>>>> Thanks & Regards,
>>>>> Ishara Cooray
>>>>> Senior Software Engineer
>>>>> Mobile : +9477 262 9512
>>>>> WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> On Wed, Aug 31, 2016 at 1:43 PM, Ishara Cooray <isha...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> + Prabath, Johann
>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Ishara Cooray
>>>>>> Senior Software Engineer
>>>>>> Mobile : +9477 262 9512
>>>>>> WSO2, Inc. | http://wso2.com/
>>>>>> Lean . Enterprise . Middleware
>>>>>>
>>>>>> On Wed, Aug 31, 2016 at 1:27 PM, Pamod Sylvester <pa...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Would it make sense to have it under "user-mgt.xml" ?
>>>>>>>
>>>>>>> On Wed, Aug 31, 2016 at 1:00 PM, Ishara Cooray <isha...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I am working on the $Subject.
>>>>>>>>
>>>>>>>> *Motivation:*
>>>>>>>> I have a use case where i want to authorize user

Re: [Architecture] OSGI Service to provision users and roles based on the SAML response.

[Ishara Cooray]

Hi All,

I thought of introducing a new Authenticator config to
repository/conf/security/authenticators.xml
And it will use only below properties to do the $Subject.


9

http://wso2.org/claims/role

,
true

PRIMARY



Any objections?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Aug 31, 2016 at 1:43 PM, Ishara Cooray <isha...@wso2.com> wrote:

> + Prabath, Johann
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Aug 31, 2016 at 1:27 PM, Pamod Sylvester <pa...@wso2.com> wrote:
>
>> Would it make sense to have it under "user-mgt.xml" ?
>>
>> On Wed, Aug 31, 2016 at 1:00 PM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Hi,
>>> I am working on the $Subject.
>>>
>>> *Motivation:*
>>> I have a use case where i want to authorize users who are logged into
>>> API publisher/ store but APIM does not have the access to underline user
>>> store.
>>>
>>> *Plan:*
>>> The plan is to write an osgi service that should do the Just In Time
>>> provisioning before the permission check to authorize the user. And it will
>>> get the roles from the SAML response and do the provisioning.
>>>
>>> But we will have to do the same role/permission mapping manually for now.
>>>
>>> If we write a generic service  we can plug it into any wso2 product that
>>> need JIT provision initiated by the Service provider.
>>> However we need to maintain few configurations here.
>>>
>>>1. isServiceProvierInitiatedJITProvisioningEnabled
>>>2. User store to be provisioned
>>>3. Implementation class (extension point)
>>>
>>> What could be the best place to maintain this configuration if the
>>> component is written as a generic component to any wso2 product?
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Pamod Sylvester *
>>
>> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
>> cell: +94 77 7779495
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OSGI Service to provision users and roles based on the SAML response.

[Ishara Cooray]

+ Prabath, Johann

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Aug 31, 2016 at 1:27 PM, Pamod Sylvester <pa...@wso2.com> wrote:

> Would it make sense to have it under "user-mgt.xml" ?
>
> On Wed, Aug 31, 2016 at 1:00 PM, Ishara Cooray <isha...@wso2.com> wrote:
>
>> Hi,
>> I am working on the $Subject.
>>
>> *Motivation:*
>> I have a use case where i want to authorize users who are logged into API
>> publisher/ store but APIM does not have the access to underline user store.
>>
>> *Plan:*
>> The plan is to write an osgi service that should do the Just In Time
>> provisioning before the permission check to authorize the user. And it will
>> get the roles from the SAML response and do the provisioning.
>>
>> But we will have to do the same role/permission mapping manually for now.
>>
>> If we write a generic service  we can plug it into any wso2 product that
>> need JIT provision initiated by the Service provider.
>> However we need to maintain few configurations here.
>>
>>1. isServiceProvierInitiatedJITProvisioningEnabled
>>2. User store to be provisioned
>>3. Implementation class (extension point)
>>
>> What could be the best place to maintain this configuration if the
>> component is written as a generic component to any wso2 product?
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Pamod Sylvester *
>
> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
> cell: +94 77 7779495
>
> ___
> 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

[Architecture] OSGI Service to provision users and roles based on the SAML response.

[Ishara Cooray]

Hi,
I am working on the $Subject.

*Motivation:*
I have a use case where i want to authorize users who are logged into API
publisher/ store but APIM does not have the access to underline user store.

*Plan:*
The plan is to write an osgi service that should do the Just In Time
provisioning before the permission check to authorize the user. And it will
get the roles from the SAML response and do the provisioning.

But we will have to do the same role/permission mapping manually for now.

If we write a generic service  we can plug it into any wso2 product that
need JIT provision initiated by the Service provider.
However we need to maintain few configurations here.

   1. isServiceProvierInitiatedJITProvisioningEnabled
   2. User store to be provisioned
   3. Implementation class (extension point)

What could be the best place to maintain this configuration if the
component is written as a generic component to any wso2 product?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Log Analyzer Tool logs are displayed in GMT

[Ishara Cooray]

With the workaround provided by Sameera, it shows the local TZ as below.

*Welcome to the live log viewer.*
*Mon Jun 13 2016 09:46:14 GMT+0530 (IST)
org.wso2.carbon.core.deployment.DeploymentInterceptor*

Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Jun 13, 2016 at 11:47 AM, Sameera Ramasinghe <samee...@wso2.com>
wrote:

> @Ruwan
>
> Yah storing in epoch time is correct. But in the thread, it was mentioned
> that in the DAS, the time is displayed as IST. That time is not relevent to
> us. That's why I mentioned it is only the log published time to DAS :).
>
> On Mon, Jun 13, 2016 at 11:43 AM, Sameera Ramasinghe <samee...@wso2.com>
> wrote:
>
>> Hi,
>>
>> as a quick work around, in main.js of the livelogviewer, there is a line
>>
>> var tempDay = new 
>> Date(parseInt(obj[i].values._eventTimeStamp)).toUTCString();
>>
>>
>> change it to
>>
>> var tempDay = new Date(parseInt(obj[i].values._eventTimeStamp)).toString();
>>
>> this will change the timezone to browser time zone.
>>
>> On Mon, Jun 13, 2016 at 11:32 AM, Sameera Ramasinghe <samee...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> That IST time-zone showing in the DAS explorer is the time the logs are
>>> published to the DAS. Not the time contained in the logs. The log times are
>>> in the "eventimestamp" field as epoch time. So we need to convert this
>>> epoch time in JS level. I will work on a fix and let you know. If we can
>>> get the server time zone, we can do as Ruwan said.
>>>
>>> On Mon, Jun 13, 2016 at 11:27 AM, Ruwan Abeykoon <ruw...@wso2.com>
>>> wrote:
>>>
>>>> Hi All,
>>>> The time zone is something we need on all the Log Analyzer gadgets to
>>>> handle properly, in the same way.
>>>>
>>>> Why we can not get the server time zone in AWS?
>>>>
>>>> What time zone a user is interested while looking at the logs and
>>>> errors. I think it is the server time zone. This is the time the logs are
>>>> being printed in respective carbon.log (if any).
>>>>
>>>>
>>>> Cheers,
>>>> Ruwan
>>>>
>>>> On Mon, Jun 13, 2016 at 11:16 AM, Ishara Cooray <isha...@wso2.com>
>>>> wrote:
>>>>
>>>>> (+ architecture)
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2016 at 10:48 AM, Ishara Cooray <isha...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> In fact, in cloud we cannot get the server time zone as hosted in
>>>>>> AWS. So need to get the Browser Time Zone.
>>>>>>
>>>>>> *@Sameera,*
>>>>>> Can we have this option in Log Analyzer Tool?
>>>>>>
>>>>>> Ishara Cooray
>>>>>> Senior Software Engineer
>>>>>> Mobile : +9477 262 9512
>>>>>> WSO2, Inc. | http://wso2.com/
>>>>>> Lean . Enterprise . Middleware
>>>>>>
>>>>>> On Mon, Jun 13, 2016 at 10:20 AM, Ruwan Abeykoon <ruw...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> +1
>>>>>>> This should be based on Server Time Zone rather than Browser Time
>>>>>>> Zone, I guess.
>>>>>>> Or should there be an option to set the TZ as server or Browser ? If
>>>>>>> so all the Log Analyzer gadgets should have the same option.
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ruwan
>>>>>>>
>>>>>>> On Mon, Jun 13, 2016 at 10:02 AM, Ishara Cooray <isha...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> In the Log Analyzer tool, the logs are shown with GMT time where as
>>>>>>>> in DAS Data Explorer it is shown for me in IST.
>>>>>>>>
>>>>>>>> So i guess Log Analyzer Tool should show the localized time.
>>>>>>>>
>>>>>>>> *@Amila,*
>>>>>>>> WDUT?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Ishara Cooray
>>>>>>>> Senior Software Engineer
>>>>>>>> Mobile : +9477 262 9512
>>>>>>>> WSO2, Inc. | http://wso2.com/
>>>>>>>> Lean . Enterprise . Middleware
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Ruwan Abeykoon*
>>>>>>> *Associate Director/Architect**,*
>>>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
>>>>>>> *lean.enterprise.middleware.*
>>>>>>>
>>>>>>> email: ruw...@wso2.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Ruwan Abeykoon*
>>>> *Associate Director/Architect**,*
>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
>>>> *lean.enterprise.middleware.*
>>>>
>>>> email: ruw...@wso2.com
>>>>
>>>
>>>
>>>
>>> --
>>> *Sameera Ramasinghe*
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> mobile: *+94 714489682*
>>>
>>
>>
>>
>> --
>> *Sameera Ramasinghe*
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> mobile: *+94 714489682*
>>
>
>
>
> --
> *Sameera Ramasinghe*
> Software Engineer, WSO2 Inc.; http://wso2.com
> mobile: *+94 714489682*
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Log Analyzer Tool logs are displayed in GMT

[Ishara Cooray]

(+ architecture)

On Mon, Jun 13, 2016 at 10:48 AM, Ishara Cooray <isha...@wso2.com> wrote:

> In fact, in cloud we cannot get the server time zone as hosted in AWS. So
> need to get the Browser Time Zone.
>
> *@Sameera,*
> Can we have this option in Log Analyzer Tool?
>
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Mon, Jun 13, 2016 at 10:20 AM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
>
>> +1
>> This should be based on Server Time Zone rather than Browser Time Zone, I
>> guess.
>> Or should there be an option to set the TZ as server or Browser ? If so
>> all the Log Analyzer gadgets should have the same option.
>>
>>
>> Cheers,
>> Ruwan
>>
>> On Mon, Jun 13, 2016 at 10:02 AM, Ishara Cooray <isha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> In the Log Analyzer tool, the logs are shown with GMT time where as in
>>> DAS Data Explorer it is shown for me in IST.
>>>
>>> So i guess Log Analyzer Tool should show the localized time.
>>>
>>> *@Amila,*
>>> WDUT?
>>>
>>> Thanks.
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
>> *lean.enterprise.middleware.*
>>
>> email: ruw...@wso2.com
>>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Tenant Level Throttling for API Manager

[Ishara Cooray]

Motivation;
We need to have TPS limit across the whole tenant based on their
subscription level, that we can change, but tenant admins cannot.So that we
can inform the customers that the subscription plan needs to be upgraded.

Design:

1. Write a custom handler by extending
org.apache.synapse.rest.AbstractHandler

2. Configure subscription plans(tiers) in a xml file and store it the file
system . /repository/conf/throttling/tenant_tiers.xml

3. Make the custom handler an osgi bundle and within the bundle activation,
initialize the throttling policy based on the said configurations file.

4. As api call hits the handler, get the subscription plan from database
and cache it in memory so that next time it will pick from the cache.

5.Pass the subscription plan to throttle engine get the results as a
boolean.

6.Write a background task that updates and clean up the cache in regular
intervals (1 hour).

7.Add the handler configuration to velocity_template.xml


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Fwd: Kafka transport for WSO2 ESB

[Ishara Cooray]

Sending to architecture group

Ishara Cooray
Senior Software Engineer

+9477 262 9510


-- Forwarded message --
From: Ishara Cooray isha...@wso2.com
Date: Sun, Jul 6, 2014 at 12:39 PM
Subject: [Architecture] Kafka transport for WSO2 ESB
To:
Cc: Kasun Indrasiri ka...@wso2.com, Srinath Perera srin...@wso2.com,
Samisa Abeysinghe sam...@wso2.com, Kathees Rajendram kath...@wso2.com


Hi,

we have come up with a high level architecture design for the kafka
transport, which is attached here with for your kind review.

Architecture - kafka transport for ESB
https://docs.google.com/a/wso2.com/document/d/19Eq9JSynneAcwIrBfshP_S6qr0l6ydNjQp_tVMt3xTo/edit


Your feedback is highly appreciated.


Thanks  Regards,
Ishara Cooray
Senior Software Engineer

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

Re: [Architecture] Fwd: Kafka transport for WSO2 ESB

[Ishara Cooray]

Hi Mohan,

Thanks for the reply.

Here KAFKA Connector publishes events to brokers where as Inbound transport
consumes through zookeeper.




Ishara Cooray
Senior Software Engineer

+9477 262 9510


On Sun, Jul 6, 2014 at 10:47 PM, Mohanadarshan Vivekanandalingam 
mo...@wso2.com wrote:

 Hi Ishara,

 I believe you have gone through the Kafka documentation. AFAIK, to consume
 events from kafka we communicate with zookeeper and to publish events we
 dealt with brokers. Here ESB connector does both consuming and publishing
 right ? .Then kafka connector needs to connect with zookeeper to consume
 events isn't it ? Then it should reflect in the diagram right. Please
 correct me if i am wrong..

 Thanks,
 Mohan




 On Sun, Jul 6, 2014 at 12:57 PM, Ishara Cooray isha...@wso2.com wrote:


 Sending to architecture group

 Ishara Cooray
 Senior Software Engineer

 +9477 262 9510


 -- Forwarded message --
 From: Ishara Cooray isha...@wso2.com
 Date: Sun, Jul 6, 2014 at 12:39 PM
 Subject: [Architecture] Kafka transport for WSO2 ESB
 To:
 Cc: Kasun Indrasiri ka...@wso2.com, Srinath Perera srin...@wso2.com,
 Samisa Abeysinghe sam...@wso2.com, Kathees Rajendram kath...@wso2.com


 Hi,

 we have come up with a high level architecture design for the kafka
 transport, which is attached here with for your kind review.

 Architecture - kafka transport for ESB
 https://docs.google.com/a/wso2.com/document/d/19Eq9JSynneAcwIrBfshP_S6qr0l6ydNjQp_tVMt3xTo/edit


 Your feedback is highly appreciated.


 Thanks  Regards,
 Ishara Cooray
 Senior Software Engineer

 +9477 262 9510


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




 --
 *V. Mohanadarshan*
 *Software Engineer,*
 *Data Technologies Team,*
 *WSO2, Inc. http://wso2.com http://wso2.com *
 *lean.enterprise.middleware.*

 email: mo...@wso2.com
 phone:(+94) 771117673

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


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

Re: [Architecture] Fwd: Kafka transport for WSO2 ESB

[Ishara Cooray]

Please refer the updated document. Kafka Transport for ESB
https://docs.google.com/a/wso2.com/document/d/19Eq9JSynneAcwIrBfshP_S6qr0l6ydNjQp_tVMt3xTo/edit
Thanks.

Ishara Cooray
Senior Software Engineer

+9477 262 9510


On Mon, Jul 7, 2014 at 10:03 AM, Ishara Cooray isha...@wso2.com wrote:

 Hi Mohan,

 Thanks for the reply.

 Here KAFKA Connector publishes events to brokers where as Inbound
 transport consumes through zookeeper.




 Ishara Cooray
 Senior Software Engineer

 +9477 262 9510


 On Sun, Jul 6, 2014 at 10:47 PM, Mohanadarshan Vivekanandalingam 
 mo...@wso2.com wrote:

 Hi Ishara,

 I believe you have gone through the Kafka documentation. AFAIK, to
 consume events from kafka we communicate with zookeeper and to publish
 events we dealt with brokers. Here ESB connector does both consuming and
 publishing right ? .Then kafka connector needs to connect with zookeeper to
 consume events isn't it ? Then it should reflect in the diagram right.
 Please correct me if i am wrong..

 Thanks,
 Mohan




 On Sun, Jul 6, 2014 at 12:57 PM, Ishara Cooray isha...@wso2.com wrote:


 Sending to architecture group

 Ishara Cooray
 Senior Software Engineer

 +9477 262 9510


 -- Forwarded message --
 From: Ishara Cooray isha...@wso2.com
 Date: Sun, Jul 6, 2014 at 12:39 PM
 Subject: [Architecture] Kafka transport for WSO2 ESB
 To:
 Cc: Kasun Indrasiri ka...@wso2.com, Srinath Perera srin...@wso2.com,
 Samisa Abeysinghe sam...@wso2.com, Kathees Rajendram kath...@wso2.com
 


 Hi,

 we have come up with a high level architecture design for the kafka
 transport, which is attached here with for your kind review.

 Architecture - kafka transport for ESB
 https://docs.google.com/a/wso2.com/document/d/19Eq9JSynneAcwIrBfshP_S6qr0l6ydNjQp_tVMt3xTo/edit


 Your feedback is highly appreciated.


 Thanks  Regards,
 Ishara Cooray
 Senior Software Engineer

 +9477 262 9510


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




 --
 *V. Mohanadarshan*
 *Software Engineer,*
 *Data Technologies Team,*
 *WSO2, Inc. http://wso2.com http://wso2.com *
 *lean.enterprise.middleware.*

 email: mo...@wso2.com
 phone:(+94) 771117673

 ___
 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