Re: [Architecture] [APIM][C5] Subesource access permissions in store

[Fazlan Nazeem]

Hi Nuwan/Bhathiya,

On Tue, May 9, 2017 at 10:19 AM, Nuwan Dias  wrote:

> I think what Bhathiya is suggesting is to bring in our usual permissions
> model (in APIM 3.0.0) to comments as well. This will require more data to
> be saved in the DB but will address the issue at hand.
>
>
Are you suggesting we should have an extra column in Comments table in
the db to fulfill this?

I am thinking of using the AM_API_PERMISSION column introduced in AM_API
table to decide on who can update/delete a specific comment. Apart from the
user who commented, If a user can delete or update an API he can
delete/update any comment for that API. This way we do not need to save
extra information in the db, and can use the api permission information to
control the comment actions.

There are two levels of permissions required here. One is "who can
> add/update/remove comments in general" and the other is "whose comments can
> I update/remove".
>
> The first can be simply achieved using scopes. Basically say which scope
> is permitted for the /comments API. The second can be solved by using our
> usual permission model in APIM v3.0.0.
>
> On Tue, May 9, 2017 at 10:10 AM, Ayyoob Hamza  wrote:
>
>> This won't tackle the problem Musthaq suggested which requires validation
>> in the backend.
>>
>> *Ayyoob Hamza*
>> *Senior Software Engineer*
>> WSO2 Inc.; http://wso2.com
>> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>>
>> On Tue, May 9, 2017 at 10:01 AM, Ayyoob Hamza  wrote:
>>
>>> Hi,
>>>
>>> We had a similar requirement to have a fine grained access for users in
>>> IoTS and we went with the approach of assigning permission for scope rather
>>> than roles.
>>>
>>> *Ayyoob Hamza*
>>> *Senior Software Engineer*
>>> WSO2 Inc.; http://wso2.com
>>> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>>>
>>> On Tue, May 9, 2017 at 9:51 AM, Mushthaq Rumy  wrote:
>>>
 Hi Prasanna/Pubudu,

 I think if we use scope based validation there will be an issue here.
 Lets take the same example.



 *GET /apis/{apiId}/comments/{commentId}  -
  comment-add-scopeDELETE /apis/{apiId}/documents/{documentId}  -
  comment-delete-scopeUPDATE /apis/{apiId}/documents/{documentId}  -
  comment-update-scope*

 Scope and roles matching are as follows.

 *comment-add-scope : subscriber-role, **admin-role*
 *comment-**update**-scope :  **subscriber-role, **admin-role*
 *comment-delete-scope : **admin-role*

 Lets say there are two store users *A* and *B* who have the 
 *subscriber-role.
 *And user *A* adds a comment to an API (*comment-add-scope*). Then
 user *B *logs in and he will be able to update that particular comment
 which user *A *has added since user *B *has the *subscriber-role* too.

 IMO this should not be allowed. AFAIC we might have to go with user
 validation.
 If we can get the logged in user's roles and if that user has
 admin-role or that particular comment is added by the logged in user we can
 allow this user to update or delete the comment. WDYT?

 Thanks & Regards,
 Mushthaq

 On Tue, May 9, 2017 at 6:31 AM, Prasanna Dangalla 
 wrote:

> Hi Fazlan,
>
> I think as Ishara and Pubudu have mentioned we can use the scope
> validation.
>
> On Tue, May 9, 2017 at 12:03 AM, Pubudu Gunatilaka 
> wrote:
>
>> + Adding architecture mail group
>>
>> On Mon, May 8, 2017 at 11:59 PM, Pubudu Gunatilaka 
>> wrote:
>>
>>> Hi Fazlan,
>>>
>>> As Ishara mentioned above, we can do this with scope validation.
>>> Each and every resource has a scope. The scope is associated with one or
>>> more roles. Consider the following example.
>>>
>>> Resource and scope matching are as follows.
>>>
>>>
>>>
>>> *GET /apis/{apiId}/comments/{commentId}  -
>>>  comment-add-scopeDELETE /apis/{apiId}/documents/{documentId}  -
>>>  comment-manage-scopeUPDATE /apis/{apiId}/documents/{documentId}  -
>>>  comment-manage-scope*
>>>
>>> Scope and roles matching are as follows.
>>>
>>> *comment-add-scope : subscriber-role, **admin-role*
>>> *comment-manage-scope :  admin-role*
>>>
>>
> @Pubudu:
>
> IMO a person who adds a comment should have the UPDATE privilege as
> well. DELETE can be restricted to admin. Like wise we might find many
> combinations with different use cases. So I think its better to decouple
> this  *comment-manage-scope *to two different scopes as
> *comment-update-scope *and *comment-delete-scope. *If we do this, we
> can assign it to respective roles in scope and role mapping for different
> use cases.
>
> Thanks
> Prasanna
>
>>

Re: [Architecture] [APIM][C5] API Editor Application

[Nuwan Dias]

This Editor is basically an IDE for APIs. I don't think documentation fits
in there. Users can of course edit the Swagger docs, which is kind of
similar to writing Java docs. But I don't think we should be allowing
people to update .doc, .pdf, etc type of docs using this editor. Its not
standard practice we follow when writing usual code.

With regard to importing and collaborating, I think they're two different
aspects. Importing basically means you "download" something from a known
server. Collaborating simply means doing a git pull. When writing Java
code, we usually git pull and start editing, we don't "import" code as
such. So I don't see "import" as a critical part to have , at least in the
first iteration.

I think its important to think of this editor like a standard IDE. If we're
doing something on this editor that we don't usually do on a standard IDE,
then we need to think twice to see if its really necessary. Since this is a
completely new component to the product, I think we should keep things as
simple as possible and focus on the most critical parts to get the job
done. We can of course keep adding stuff on demand, if users require them.

On Wed, May 17, 2017 at 5:28 PM, Tharika Madurapperuma 
wrote:

> Hi Chamin,
>
> On Wed, May 17, 2017 at 12:29 PM, Chamin Dias  wrote:
>
>> Since this is a subset of API Publisher, it would be better to list down
>> and finalize the features of API Editor which are going to be inherited
>> from Publisher. The reason is, it will help us to come up with an effective
>> implementation mechanism (like reusing existing functions etc.). WDYT?
>
>
> As of now the following are the main features inherited by the API Editor
> from the API Publisher,
>
>- Creating an API
>   - With endpoints
>   - By importing a swagger definition
>   - As a Mock API
>- Specifying API resources
>- API level endpoints
>- Mediation
>- Scripting
>- API Import Export
>
> API Editor can have its own functionalities which are not in the API
> Publisher such as,
>
>- API Console for testing the API
>
> Will keep the list updated with any changes.
> Thanks,
> Tharika.
>
> --
> *Tharika Madurapperuma*
> Software Engineer | WSO2, Inc.
>
> Email : thar...@wso2.com
> Mobile : +94777875624 <+94%2077%20787%205624>
> Web : http://wso2.com
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Nuwan Dias

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

Re: [Architecture] [UUF] Extensible Authorization for UUF

[Imesh Gunaratne]

Thanks for the clarifications Sajith and Vidura!!

On Wed, May 17, 2017 at 5:46 PM, Vidura Nanayakkara 
wrote:

> Hi Imesh,
>
> Thanks Vidura! Would you mind explaining why each product has to implement
>> it's own authorizer?
>
>
> At the moment, AFAIK there is no common permission model for WSO2
> products. For WSO2 Identity Server, we have [1] and there is currently a
> discussion going on regarding the permission model for WSO2 Message Broker
> 4 in [2]. If we are to decide on a common permission model for WSO2
> products then we can provide a default Authorizer that would be packaged
> with Carbon UUF. Even in this case we should not use the implemented
> default Authorizer if it is not explicitly specified in the 'app.yaml'
> configuration. The reason for this is that Carbon UUF is an UI framework
> and should be able to be reused by any other product (should be loosely
> coupled).
>
> WDYT?
>
> Also, should we have a common permission model across the platform?
>
> [1] https://github.com/wso2/carbon-identity-mgt
> [2] Architecture mail thread "C5 based permission model for MB-4"
>
> Best Regards,
> Vidura Nanayakkara
>
> On Wed, May 17, 2017 at 4:30 PM, Imesh Gunaratne  wrote:
>
>>
>>
>> On Wed, May 17, 2017 at 11:57 AM, Vidura Nanayakkara 
>> wrote:
>>
>>
>>> Since we are not aware of the 'Authorizer' implementations that can be
>>> in a product (persisting and retrieving permissions logic) we cannot
>>> provide a default implementation to the 'Authorizer'.
>>>
>>
>> Thanks Vidura! Would you mind explaining why each product has to
>> implement it's own authorizer?
>>
>> Thanks
>> Imesh
>> ​
>>
>>> This has been documented in the 'Authorizer' interface [1].
>>>
>>> [1] https://github.com/wso2/carbon-uuf/blob/3fbf10907747806d
>>> 6311acef2095e5a8b623e339/components/uuf-core/src/main/java/
>>> org/wso2/carbon/uuf/spi/auth/Authorizer.java
>>>
>>> Best Regards,
>>> Vidura Nanayakkara
>>>
>>> On Wed, May 17, 2017 at 10:27 AM, Chandana Napagoda 
>>> wrote:
>>>
 Hi Imesh,

 I think during the offline meeting, we have already discussed about the
 default implementation.

 @ViduraN, Can you please elaborate it in here?

 Regards,
 Chandana

 On Wed, May 17, 2017 at 10:08 AM, Imesh Gunaratne 
 wrote:

> As we discussed offline I think it would be better to provide a
> default implementation for $subject while providing the extension point.
>
> Thanks
>
> On Wed, May 3, 2017 at 10:47 AM, SajithAR Ariyarathna <
> sajit...@wso2.com> wrote:
>
>> Hi All,
>>
>> We are in the process of introducing an extensible authorizer for
>> Carbon UUF.
>>
>> At the moment authorization is done via the
>> org.wso2.carbon.uuf.spi.auth.User interface [1]. When creating an
>> user session, implementation of the User interface (e.g. CaasUser [2]) 
>> should
>> be passed. The main drawback of this approach is, the logic in the
>> hasPermission() method has to be serializable. Usually this is
>> difficult to achieve because in order to evaluate permissions one might
>> need to access some user management services (e.g. Realm Service) which
>> cannot be serialized. Hence moving the hasPermission() method out of
>> the User class and allowing to plug-in a custom authorizer would be
>> a better approach.
>>
>> WDYT?
>>
>> [1] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/compo
>> nents/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/Us
>> er.java#L28
>> [2] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/sampl
>> es/osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundl
>> e/src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle
>> /CaasUser.java
>>
>> Thanks.
>> --
>> Sajith Janaprasad Ariyarathna
>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>> 
>>
>
>
>
> --
> *Imesh Gunaratne*
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 *Chandana Napagoda*
 Associate Technical Lead
 WSO2 Inc. - http://wso2.org

 *Email  :  chand...@wso2.com **Mobile :
 +94718169299 <+94%2071%20816%209299>*

 *Blog  :http://cnapagoda.blogspot.com
  | http://chandana.napagoda.com
 *

 *Linkedin : http://www.linkedin.com/in/chandananapagoda
 *


>>>
>>>

Re: [Architecture] Distinguish between local and federated users in oauth tables

[Ishara Karunarathna]

On Wed, May 17, 2017 at 10:17 PM, Prabath Siriwardena 
wrote:

> Yes - we know the issuer of the token - so we can control what to
> provision
>
If we provision the user how do we treat him in the oauth tables as a
federated user of local user ?
I think we have to treat it as a local user and store relevant user domain
as well And still we have the usecase of handling federated users here.

So I think better 1st implement federated scenario and go for provisioning
scenario.
-Ishara

>
> Thanks & regards,
> -Prabath
>
> On Wed, May 17, 2017 at 9:11 AM, Farasath Ahamed 
> wrote:
>
>> In the current implementation of SAML and JWT bearer grants we treat the
>> user coming with the grants as federated users always.
>>
>> This is not always the case since there are scenarios where the SAML/JWT
>> token will be issued by the same IS instance that will accept them later as
>> bearer grants  and issue tokens. Therefore ideally we need to treat these
>> users as local users.
>>
>> Since we are planning to do an improvement to provision federated users I
>> think this improvement would be necessary. Otherwise we would be blindly
>> provisioning all the users irrespective of whether they are local or
>> federated users.
>>
>> There was a discussion[1] related this for SAML bearer grant earlier as
>> well. I think we could consider that improvement along with this fix.
>>
>> WDYT?
>>
>>
>> [1] [Dev] Validate user against given user store and save correct user
>> domain in saml2-bearer grant type
>>
>> On Wednesday, May 17, 2017, Prabath Siriwardena  wrote:
>>
>>> Can we give the option to provision the user...? This requires no UI
>>> changes - can read the option from the IdP config...
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>> On Tue, May 16, 2017 at 10:26 PM, Ishara Karunarathna 
>>> wrote:
>>>


 On Wed, May 17, 2017 at 10:37 AM, Prabath Siriwardena  wrote:

>
>
> On Tue, May 16, 2017 at 10:04 PM, Ishara Karunarathna <
> isha...@wso2.com> wrote:
>
>>
>>
>> On Wed, May 17, 2017 at 10:26 AM, Prabath Siriwardena <
>> prab...@wso2.com> wrote:
>>
>>> Also - related to JWT/SAML grant types - do we have an option to JIT
>>> provision the user...?
>>>
>> This is not available in the current implementation.
>>
>>> The expectation is - when you enable JIT provisioning under the
>>> trusted IdP - and pick the userstore to provision the users - then the 
>>> user
>>> should be JIT provisioned...
>>>
>> If we need to support OIDC with JWT/SAML grant types we need to have
>> this this feature. even though OIDC spec does not talk about supporting
>> OIDC with custom grant types
>> this can be treated as token exchange mechanism And +1 for supporting
>> this.
>>
>
> In fact this not related directly related ODIC - just the JWT grant
> type (JWT grant type for OAuth 2.0)..
>
> if this is not supported then - in API M - how do we generate the JWT
> for the backend - when users come from a federate JWT..?
>
 In this case we only provide sub element, APIM should do the same

>
> Thanks & regards,
> -Prabath
>
>
>
>>
>> -Ishara
>>
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>>
>>> On Tue, May 16, 2017 at 8:58 PM, Pushpalanka Jayawardhana <
>>> la...@wso2.com> wrote:
>>>


 On Tue, May 16, 2017 at 11:15 PM, Ishara Karunarathna <
 isha...@wso2.com> wrote:

>
>
> On Tue, May 16, 2017 at 10:25 PM, Prabath Siriwardena <
> prab...@wso2.com> wrote:
>
>> How do you figure out users from different idps?
>>
> In this way we can only identify whether use is federated or local
> user.
>
> But we can use a convention to keep IDP name as well if we need to
> go without schema changes
> Ex FEDERATED:IDP1
>

 Is this to address any future issues or cater for features?

 I can see a conceptual fault saving same domain name for different
 IDPs, along with the unique key constraint we have. This can lead to 
 treat
 two identities as same, since we will only know they are federated.

 CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TE
 NANT_ID,*USER_DOMAIN*,USER_TYPE,TOKEN_SCOPE_HASH,


  TOKEN_STATE,TOKEN_STATE_ID)

 What will be the places we will make use of the knowledge of
 authenticated IDP?

>
> -Ishara
>
>>
>> Thanks & regards,
>> -Prabath
>>
>> On Tue, May 16, 2017 at 7:23 AM, Pushpalanka Jayawardhana <
>> la...@wso2.com> wrote:
>>
>>> Hi 

Re: [Architecture] Distinguish between local and federated users in oauth tables

[Prabath Siriwardena]

Yes - we know the issuer of the token - so we can control what to
provision

Thanks & regards,
-Prabath

On Wed, May 17, 2017 at 9:11 AM, Farasath Ahamed  wrote:

> In the current implementation of SAML and JWT bearer grants we treat the
> user coming with the grants as federated users always.
>
> This is not always the case since there are scenarios where the SAML/JWT
> token will be issued by the same IS instance that will accept them later as
> bearer grants  and issue tokens. Therefore ideally we need to treat these
> users as local users.
>
> Since we are planning to do an improvement to provision federated users I
> think this improvement would be necessary. Otherwise we would be blindly
> provisioning all the users irrespective of whether they are local or
> federated users.
>
> There was a discussion[1] related this for SAML bearer grant earlier as
> well. I think we could consider that improvement along with this fix.
>
> WDYT?
>
>
> [1] [Dev] Validate user against given user store and save correct user
> domain in saml2-bearer grant type
>
> On Wednesday, May 17, 2017, Prabath Siriwardena  wrote:
>
>> Can we give the option to provision the user...? This requires no UI
>> changes - can read the option from the IdP config...
>>
>> Thanks & regards,
>> -Prabath
>>
>> On Tue, May 16, 2017 at 10:26 PM, Ishara Karunarathna 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 17, 2017 at 10:37 AM, Prabath Siriwardena 
>>> wrote:
>>>


 On Tue, May 16, 2017 at 10:04 PM, Ishara Karunarathna  wrote:

>
>
> On Wed, May 17, 2017 at 10:26 AM, Prabath Siriwardena <
> prab...@wso2.com> wrote:
>
>> Also - related to JWT/SAML grant types - do we have an option to JIT
>> provision the user...?
>>
> This is not available in the current implementation.
>
>> The expectation is - when you enable JIT provisioning under the
>> trusted IdP - and pick the userstore to provision the users - then the 
>> user
>> should be JIT provisioned...
>>
> If we need to support OIDC with JWT/SAML grant types we need to have
> this this feature. even though OIDC spec does not talk about supporting
> OIDC with custom grant types
> this can be treated as token exchange mechanism And +1 for supporting
> this.
>

 In fact this not related directly related ODIC - just the JWT grant
 type (JWT grant type for OAuth 2.0)..

 if this is not supported then - in API M - how do we generate the JWT
 for the backend - when users come from a federate JWT..?

>>> In this case we only provide sub element, APIM should do the same
>>>

 Thanks & regards,
 -Prabath



>
> -Ishara
>
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>> On Tue, May 16, 2017 at 8:58 PM, Pushpalanka Jayawardhana <
>> la...@wso2.com> wrote:
>>
>>>
>>>
>>> On Tue, May 16, 2017 at 11:15 PM, Ishara Karunarathna <
>>> isha...@wso2.com> wrote:
>>>


 On Tue, May 16, 2017 at 10:25 PM, Prabath Siriwardena <
 prab...@wso2.com> wrote:

> How do you figure out users from different idps?
>
 In this way we can only identify whether use is federated or local
 user.

 But we can use a convention to keep IDP name as well if we need to
 go without schema changes
 Ex FEDERATED:IDP1

>>>
>>> Is this to address any future issues or cater for features?
>>>
>>> I can see a conceptual fault saving same domain name for different
>>> IDPs, along with the unique key constraint we have. This can lead to 
>>> treat
>>> two identities as same, since we will only know they are federated.
>>>
>>> CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TENANT_ID,
>>> *USER_DOMAIN*,USER_TYPE,TOKEN_SCOPE_HASH,
>>>
>>>
>>>  TOKEN_STATE,TOKEN_STATE_ID)
>>>
>>> What will be the places we will make use of the knowledge of
>>> authenticated IDP?
>>>

 -Ishara

>
> Thanks & regards,
> -Prabath
>
> On Tue, May 16, 2017 at 7:23 AM, Pushpalanka Jayawardhana <
> la...@wso2.com> wrote:
>
>> Hi All,
>>
>> We have below 3 issues that are caused mainly because we don't
>> have a clear way to distinguish local and federated users in oauth 
>> related
>> tables (authorization code and access token storage).
>> There are few more issues related to sending subject claim in
>> proper format in IDtoken, that needs to identify the user as 
>> federated or
>> local.
>>
>> In order to address these issues  we need to check whether user
>> is from a federated IDP. To fix this without 

[Architecture] Force Delete Identity Providers

[Prabath Siriwardena]

At the moment we can't delete an identity provider, if its associated with
one or more service providers.

Also - for the user there is no way to find out the associated service
providers for a given identity provider - without going through each and
every service provider config.

This is fine (or just okay) if we have 2 or 3 service providers in the
system - but its not the case today.

Can we provide a feature to force delete an identity provider? If not at
the UI - at least at the API level..

If we agree - can we please prioritize this...?

Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

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

[Architecture] Distinguish between local and federated users in oauth tables

[Farasath Ahamed]

In the current implementation of SAML and JWT bearer grants we treat the
user coming with the grants as federated users always.

This is not always the case since there are scenarios where the SAML/JWT
token will be issued by the same IS instance that will accept them later as
bearer grants  and issue tokens. Therefore ideally we need to treat these
users as local users.

Since we are planning to do an improvement to provision federated users I
think this improvement would be necessary. Otherwise we would be blindly
provisioning all the users irrespective of whether they are local or
federated users.

There was a discussion[1] related this for SAML bearer grant earlier as
well. I think we could consider that improvement along with this fix.

WDYT?


[1] [Dev] Validate user against given user store and save correct user
domain in saml2-bearer grant type

On Wednesday, May 17, 2017, Prabath Siriwardena > wrote:

> Can we give the option to provision the user...? This requires no UI
> changes - can read the option from the IdP config...
>
> Thanks & regards,
> -Prabath
>
> On Tue, May 16, 2017 at 10:26 PM, Ishara Karunarathna 
> wrote:
>
>>
>>
>> On Wed, May 17, 2017 at 10:37 AM, Prabath Siriwardena 
>> wrote:
>>
>>>
>>>
>>> On Tue, May 16, 2017 at 10:04 PM, Ishara Karunarathna 
>>> wrote:
>>>


 On Wed, May 17, 2017 at 10:26 AM, Prabath Siriwardena  wrote:

> Also - related to JWT/SAML grant types - do we have an option to JIT
> provision the user...?
>
 This is not available in the current implementation.

> The expectation is - when you enable JIT provisioning under the
> trusted IdP - and pick the userstore to provision the users - then the 
> user
> should be JIT provisioned...
>
 If we need to support OIDC with JWT/SAML grant types we need to have
 this this feature. even though OIDC spec does not talk about supporting
 OIDC with custom grant types
 this can be treated as token exchange mechanism And +1 for supporting
 this.

>>>
>>> In fact this not related directly related ODIC - just the JWT grant type
>>> (JWT grant type for OAuth 2.0)..
>>>
>>> if this is not supported then - in API M - how do we generate the JWT
>>> for the backend - when users come from a federate JWT..?
>>>
>> In this case we only provide sub element, APIM should do the same
>>
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>>
>>>

 -Ishara

>
> Thanks & regards,
> -Prabath
>
>
> On Tue, May 16, 2017 at 8:58 PM, Pushpalanka Jayawardhana <
> la...@wso2.com> wrote:
>
>>
>>
>> On Tue, May 16, 2017 at 11:15 PM, Ishara Karunarathna <
>> isha...@wso2.com> wrote:
>>
>>>
>>>
>>> On Tue, May 16, 2017 at 10:25 PM, Prabath Siriwardena <
>>> prab...@wso2.com> wrote:
>>>
 How do you figure out users from different idps?

>>> In this way we can only identify whether use is federated or local
>>> user.
>>>
>>> But we can use a convention to keep IDP name as well if we need to
>>> go without schema changes
>>> Ex FEDERATED:IDP1
>>>
>>
>> Is this to address any future issues or cater for features?
>>
>> I can see a conceptual fault saving same domain name for different
>> IDPs, along with the unique key constraint we have. This can lead to 
>> treat
>> two identities as same, since we will only know they are federated.
>>
>> CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TENANT_ID,
>> *USER_DOMAIN*,USER_TYPE,TOKEN_SCOPE_HASH,
>>
>>TOKEN_STATE,TOKEN_STATE_ID)
>>
>> What will be the places we will make use of the knowledge of
>> authenticated IDP?
>>
>>>
>>> -Ishara
>>>

 Thanks & regards,
 -Prabath

 On Tue, May 16, 2017 at 7:23 AM, Pushpalanka Jayawardhana <
 la...@wso2.com> wrote:

> Hi All,
>
> We have below 3 issues that are caused mainly because we don't
> have a clear way to distinguish local and federated users in oauth 
> related
> tables (authorization code and access token storage).
> There are few more issues related to sending subject claim in
> proper format in IDtoken, that needs to identify the user as 
> federated or
> local.
>
> In order to address these issues  we need to check whether user is
> from a federated IDP. To fix this without having DB schema changes, 
> IsharaK
> came up with this idea to use 'UserStoreDomain' column,
> to store the value 'FEDERATED' as user store domain for tokens and
> authorization codes issued to federated users. The relevant 

Re: [Architecture] C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

[Vidura Nanayakkara]

Hi Jayanga and Ruwan,

​
> Can we look into a way this can be triggered selectively with some
> command-line option or an offline command? Reason to keep this logic from
> slowing down the startup in production run.​


+1 for having a separate command-line option to apply the temporary patch.
The reason is applying a temporary log patch to collect logs is a special
case scenario and is not worth checking the files list in the
[product_home]/lib to check whether there are any changes to the files. If
the client can put the effort to apply a log patch and collect the logs
certainly the client can start the server with an additional parameter.

WDYT?

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake 
wrote:

> Hi Ruwan,
>
> Thanks for the comments.
>
> In every server startup, it checks the files list in the
> [product_home]/lib to check whether there are any changes to the files.
> Yes, we could save some 'time' in the server startup if we provide a
> separate tool. But there is a possibility that someone would miss running
> that script and expect the new changes. Anyway, I'll check on the
> possibilities of minimizing startup time taken.
>
> Regarding the checkpointing thing, the suggested approach keep the
> original bundles.info file as a backup and always update it with the
> bundles given in the [product_home]/lib. And we haven planned on keeping
> the historical changes. Hence it will always be from original state to
> latest state change.
>
> Thanks,
> Jayanga.
>
>
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259 <+94%2077%20220%207259>
> 
>
> On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon  wrote:
>
>> + 1 on the idea of the four steps mentioned.
>> Can we look into a way this can be triggered selectively with some
>> command-line option or an offline command? Reason to keep this logic from
>> slowing down the startup in production run.
>>
>> In addition to that, in future, we could able to enhance the same logic
>> to allow similar behavior like "windows System Restore Point" or "OSX time
>> machine" to revert to known point of WUM, by version controlling the
>> bundle-info and the respective jars/configs.
>>
>> Cheers,
>> Ruwan
>>
>> On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake 
>> wrote:
>>
>>> Hi All,
>>>
>>> Existing OSGi deployment logic [1] keep updating the bundles.info file
>>> as and when a bundle is added/removed from the [product_home]/lib directory.
>>>
>>> 1. It first read the bundles.info file of the current runtime
>>> 2. Then take the list of bundles coming from "plugins" directory.
>>> 3. Adds the bundles in the [product_home]/lib directory to the previous
>>> list
>>> 4. Get distinct bundles based on the bundle symbolic name and version.
>>> (ignores bundles with same symbolic name and version already in the list,
>>> hence bundles in the plugins directory get the priority)
>>> 5. Update the bundles.info file
>>>
>>> The above-mentioned approach assumes all basic bundles for the runtime
>>> coming from the "plugins" directory and adds the external bundles on top of
>>> it.
>>>
>>> Recently we were looking into the C5 update/patching model and there was
>>> a concern on how we could add a temporary log patches, etc. to identify an
>>> issue. (in a case where all other possibilities failed).
>>>
>>> The most convenient to the client is to just add the given log patch to
>>> the pack, restart, collect the relevant logs, and finally revert the log
>>> patch. Any additional steps would be an overhead as the client is already
>>> undergoing a severe issue and client is trying to help us to identify the
>>> issue by applying the log patch. Hence this should be modeled in a
>>> convenient way to the users.
>>>
>>> There is a possibility to let the clients add the log patch into the
>>>  [product_home]/lib directory and remove it once done. But with the current
>>> OSGi bundle deployment logic, we can't do that as it always gives the
>>> priority to the bundles in the plugins directory. If we put a bundle with
>>> the same bundle-symbolic-name and version into the plugins directory it
>>> will be ignored.
>>>
>>> To achieve this behavior we have to modify the existing OSGi bundle
>>> deployment logic as follows.
>>>
>>> 1. In the first run make a backup of the original bundles.info file
>>> (bundles.info.original this will be used as the baseline for each time it
>>> updated the bundles.info file)
>>> 2. Read the bundles.info.original file
>>> 3. Add the bundles in the [product_home]/lib directory
>>> 4. Update the  bundles.info file
>>> And
>>> The logic in selecting effective bundles list should be changed to not
>>> to give priority to bundles in the plugins directory. Instead modify the
>>> entries, if a similar bundle (symbolic name and version) 

Re: [Architecture] C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)

[Jayanga Dissanayake]

Hi Ruwan,

Thanks for the comments.

In every server startup, it checks the files list in the [product_home]/lib
to check whether there are any changes to the files. Yes, we could save
some 'time' in the server startup if we provide a separate tool. But there
is a possibility that someone would miss running that script and expect the
new changes. Anyway, I'll check on the possibilities of minimizing startup
time taken.

Regarding the checkpointing thing, the suggested approach keep the original
bundles.info file as a backup and always update it with the bundles given
in the [product_home]/lib. And we haven planned on keeping the historical
changes. Hence it will always be from original state to latest state change.

Thanks,
Jayanga.


*Jayanga Dissanayake*
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: jaya...@wso2.com
mobile: +94772207259


On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon  wrote:

> + 1 on the idea of the four steps mentioned.
> Can we look into a way this can be triggered selectively with some
> command-line option or an offline command? Reason to keep this logic from
> slowing down the startup in production run.
>
> In addition to that, in future, we could able to enhance the same logic to
> allow similar behavior like "windows System Restore Point" or "OSX time
> machine" to revert to known point of WUM, by version controlling the
> bundle-info and the respective jars/configs.
>
> Cheers,
> Ruwan
>
> On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake 
> wrote:
>
>> Hi All,
>>
>> Existing OSGi deployment logic [1] keep updating the bundles.info file
>> as and when a bundle is added/removed from the [product_home]/lib directory.
>>
>> 1. It first read the bundles.info file of the current runtime
>> 2. Then take the list of bundles coming from "plugins" directory.
>> 3. Adds the bundles in the [product_home]/lib directory to the previous
>> list
>> 4. Get distinct bundles based on the bundle symbolic name and version.
>> (ignores bundles with same symbolic name and version already in the list,
>> hence bundles in the plugins directory get the priority)
>> 5. Update the bundles.info file
>>
>> The above-mentioned approach assumes all basic bundles for the runtime
>> coming from the "plugins" directory and adds the external bundles on top of
>> it.
>>
>> Recently we were looking into the C5 update/patching model and there was
>> a concern on how we could add a temporary log patches, etc. to identify an
>> issue. (in a case where all other possibilities failed).
>>
>> The most convenient to the client is to just add the given log patch to
>> the pack, restart, collect the relevant logs, and finally revert the log
>> patch. Any additional steps would be an overhead as the client is already
>> undergoing a severe issue and client is trying to help us to identify the
>> issue by applying the log patch. Hence this should be modeled in a
>> convenient way to the users.
>>
>> There is a possibility to let the clients add the log patch into the
>>  [product_home]/lib directory and remove it once done. But with the current
>> OSGi bundle deployment logic, we can't do that as it always gives the
>> priority to the bundles in the plugins directory. If we put a bundle with
>> the same bundle-symbolic-name and version into the plugins directory it
>> will be ignored.
>>
>> To achieve this behavior we have to modify the existing OSGi bundle
>> deployment logic as follows.
>>
>> 1. In the first run make a backup of the original bundles.info file
>> (bundles.info.original this will be used as the baseline for each time it
>> updated the bundles.info file)
>> 2. Read the bundles.info.original file
>> 3. Add the bundles in the [product_home]/lib directory
>> 4. Update the  bundles.info file
>> And
>> The logic in selecting effective bundles list should be changed to not to
>> give priority to bundles in the plugins directory. Instead modify the
>> entries, if a similar bundle (symbolic name and version) is found in the
>> [product_home]/lib
>>
>> Above suggested approach allows easily add the patched jars into the
>> [product_home]/lib directory for temporary purposes. And reverting the
>> patch is also possible as we have a backup of the original bundles.info
>>  file
>>
>> WDYT?
>>
>> [1] https://github.com/wso2/carbon-kernel/blob/v5.2.0-m3/lau
>> ncher/src/main/java/org/wso2/carbon/launcher/extensions/OSGi
>> LibBundleDeployerUtils.java
>>
>> Thanks,
>> *Jayanga Dissanayake*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.com/
>> lean . enterprise . middleware
>> email: jaya...@wso2.com
>> mobile: +94772207259 <+94%2077%20220%207259>
>> 
>>
>
>
>
> --
>
> *Ruwan Abeykoon*
> *Associate Director/Architect**,*
> *WSO2, Inc. http://wso2.com  *
> *lean.enterprise.middleware.*
>
>
___
Architecture 

Re: [Architecture] [UUF] Extensible Authorization for UUF

[Vidura Nanayakkara]

Hi Imesh,

Thanks Vidura! Would you mind explaining why each product has to implement
> it's own authorizer?


At the moment, AFAIK there is no common permission model for WSO2 products.
For WSO2 Identity Server, we have [1] and there is currently a discussion
going on regarding the permission model for WSO2 Message Broker 4 in [2].
If we are to decide on a common permission model for WSO2 products then we
can provide a default Authorizer that would be packaged with Carbon UUF.
Even in this case we should not use the implemented default Authorizer if
it is not explicitly specified in the 'app.yaml' configuration. The reason
for this is that Carbon UUF is an UI framework and should be able to be
reused by any other product (should be loosely coupled).

WDYT?

Also, should we have a common permission model across the platform?

[1] https://github.com/wso2/carbon-identity-mgt
[2] Architecture mail thread "C5 based permission model for MB-4"

Best Regards,
Vidura Nanayakkara

On Wed, May 17, 2017 at 4:30 PM, Imesh Gunaratne  wrote:

>
>
> On Wed, May 17, 2017 at 11:57 AM, Vidura Nanayakkara 
> wrote:
>
>
>> Since we are not aware of the 'Authorizer' implementations that can be in
>> a product (persisting and retrieving permissions logic) we cannot provide a
>> default implementation to the 'Authorizer'.
>>
>
> Thanks Vidura! Would you mind explaining why each product has to implement
> it's own authorizer?
>
> Thanks
> Imesh
> ​
>
>> This has been documented in the 'Authorizer' interface [1].
>>
>> [1] https://github.com/wso2/carbon-uuf/blob/3fbf10907747806d
>> 6311acef2095e5a8b623e339/components/uuf-core/src/main/
>> java/org/wso2/carbon/uuf/spi/auth/Authorizer.java
>>
>> Best Regards,
>> Vidura Nanayakkara
>>
>> On Wed, May 17, 2017 at 10:27 AM, Chandana Napagoda 
>> wrote:
>>
>>> Hi Imesh,
>>>
>>> I think during the offline meeting, we have already discussed about the
>>> default implementation.
>>>
>>> @ViduraN, Can you please elaborate it in here?
>>>
>>> Regards,
>>> Chandana
>>>
>>> On Wed, May 17, 2017 at 10:08 AM, Imesh Gunaratne 
>>> wrote:
>>>
 As we discussed offline I think it would be better to provide a default
 implementation for $subject while providing the extension point.

 Thanks

 On Wed, May 3, 2017 at 10:47 AM, SajithAR Ariyarathna <
 sajit...@wso2.com> wrote:

> Hi All,
>
> We are in the process of introducing an extensible authorizer for
> Carbon UUF.
>
> At the moment authorization is done via the org.wso2.carbon.uuf.spi.au
> th.User interface [1]. When creating an user session, implementation
> of the User interface (e.g. CaasUser [2]) should be passed. The main
> drawback of this approach is, the logic in the hasPermission() method
> has to be serializable. Usually this is difficult to achieve because in
> order to evaluate permissions one might need to access some user 
> management
> services (e.g. Realm Service) which cannot be serialized. Hence moving the
> hasPermission() method out of the User class and allowing to plug-in
> a custom authorizer would be a better approach.
>
> WDYT?
>
> [1] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/compo
> nents/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/Us
> er.java#L28
> [2] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/sampl
> es/osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundl
> e/src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle
> /CaasUser.java
>
> Thanks.
> --
> Sajith Janaprasad Ariyarathna
> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
> 
>



 --
 *Imesh Gunaratne*
 WSO2 Inc: http://wso2.com
 T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
 W: https://medium.com/@imesh TW: @imesh
 lean. enterprise. middleware


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


>>>
>>>
>>> --
>>> *Chandana Napagoda*
>>> Associate Technical Lead
>>> WSO2 Inc. - http://wso2.org
>>>
>>> *Email  :  chand...@wso2.com **Mobile : +94718169299
>>> <+94%2071%20816%209299>*
>>>
>>> *Blog  :http://cnapagoda.blogspot.com
>>>  | http://chandana.napagoda.com
>>> *
>>>
>>> *Linkedin : http://www.linkedin.com/in/chandananapagoda
>>> *
>>>
>>>
>>
>>
>> --
>> Best Regards,
>>
>> *Vidura Nanayakkara*
>> Software Engineer
>>
>> Email : vidu...@wso2.com
>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
>> Web : http://wso2.com
>> Blog : https://medium.com/@viduran 
>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
>> 

Re: [Architecture] [APIM][C5] API Editor Application

[Tharika Madurapperuma]

Hi Chamin,

On Wed, May 17, 2017 at 12:29 PM, Chamin Dias  wrote:

> Since this is a subset of API Publisher, it would be better to list down
> and finalize the features of API Editor which are going to be inherited
> from Publisher. The reason is, it will help us to come up with an effective
> implementation mechanism (like reusing existing functions etc.). WDYT?


As of now the following are the main features inherited by the API Editor
from the API Publisher,

   - Creating an API
  - With endpoints
  - By importing a swagger definition
  - As a Mock API
   - Specifying API resources
   - API level endpoints
   - Mediation
   - Scripting
   - API Import Export

API Editor can have its own functionalities which are not in the API
Publisher such as,

   - API Console for testing the API

Will keep the list updated with any changes.
Thanks,
Tharika.

-- 
*Tharika Madurapperuma*
Software Engineer | WSO2, Inc.

Email : thar...@wso2.com
Mobile : +94777875624 <+94%2077%20787%205624>
Web : http://wso2.com


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

Re: [Architecture] [UUF] Extensible Authorization for UUF

[SajithAR Ariyarathna]

Hi Imesh,

On Wed, May 17, 2017 at 4:30 PM, Imesh Gunaratne  wrote:

>
>
> On Wed, May 17, 2017 at 11:57 AM, Vidura Nanayakkara 
> wrote:
>
>
>> Since we are not aware of the 'Authorizer' implementations that can be in
>> a product (persisting and retrieving permissions logic) we cannot provide a
>> default implementation to the 'Authorizer'.
>>
>
> Thanks Vidura! Would you mind explaining why each product has to implement
> it's own authorizer?
>
> Every product doesn't need to implement their own Authorizer. For example,
IoT product can use the SSO Authorizer provided by the IS. However webapp
developer needs to configure the desired Authorizer for their webapp.

Thanks.

> Thanks
> Imesh
> ​
>
>> This has been documented in the 'Authorizer' interface [1].
>>
>> [1] https://github.com/wso2/carbon-uuf/blob/3fbf10907747806d
>> 6311acef2095e5a8b623e339/components/uuf-core/src/main/
>> java/org/wso2/carbon/uuf/spi/auth/Authorizer.java
>>
>> Best Regards,
>> Vidura Nanayakkara
>>
>> On Wed, May 17, 2017 at 10:27 AM, Chandana Napagoda 
>> wrote:
>>
>>> Hi Imesh,
>>>
>>> I think during the offline meeting, we have already discussed about the
>>> default implementation.
>>>
>>> @ViduraN, Can you please elaborate it in here?
>>>
>>> Regards,
>>> Chandana
>>>
>>> On Wed, May 17, 2017 at 10:08 AM, Imesh Gunaratne 
>>> wrote:
>>>
 As we discussed offline I think it would be better to provide a default
 implementation for $subject while providing the extension point.

 Thanks

 On Wed, May 3, 2017 at 10:47 AM, SajithAR Ariyarathna <
 sajit...@wso2.com> wrote:

> Hi All,
>
> We are in the process of introducing an extensible authorizer for
> Carbon UUF.
>
> At the moment authorization is done via the org.wso2.carbon.uuf.spi.au
> th.User interface [1]. When creating an user session, implementation
> of the User interface (e.g. CaasUser [2]) should be passed. The main
> drawback of this approach is, the logic in the hasPermission() method
> has to be serializable. Usually this is difficult to achieve because in
> order to evaluate permissions one might need to access some user 
> management
> services (e.g. Realm Service) which cannot be serialized. Hence moving the
> hasPermission() method out of the User class and allowing to plug-in
> a custom authorizer would be a better approach.
>
> WDYT?
>
> [1] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/compo
> nents/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/Us
> er.java#L28
> [2] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/sampl
> es/osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundl
> e/src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle
> /CaasUser.java
>
> Thanks.
> --
> Sajith Janaprasad Ariyarathna
> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
> 
>



 --
 *Imesh Gunaratne*
 WSO2 Inc: http://wso2.com
 T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
 W: https://medium.com/@imesh TW: @imesh
 lean. enterprise. middleware


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


>>>
>>>
>>> --
>>> *Chandana Napagoda*
>>> Associate Technical Lead
>>> WSO2 Inc. - http://wso2.org
>>>
>>> *Email  :  chand...@wso2.com **Mobile : +94718169299
>>> <+94%2071%20816%209299>*
>>>
>>> *Blog  :http://cnapagoda.blogspot.com
>>>  | http://chandana.napagoda.com
>>> *
>>>
>>> *Linkedin : http://www.linkedin.com/in/chandananapagoda
>>> *
>>>
>>>
>>
>>
>> --
>> Best Regards,
>>
>> *Vidura Nanayakkara*
>> Software Engineer
>>
>> Email : vidu...@wso2.com
>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
>> Web : http://wso2.com
>> Blog : https://medium.com/@viduran 
>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
>> 
>>
>
>
>
> --
> *Imesh Gunaratne*
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sajith Janaprasad Ariyarathna
Senior Software Engineer; WSO2, Inc.;  http://wso2.com/

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

Re: [Architecture] [UUF] Extensible Authorization for UUF

[Imesh Gunaratne]

On Wed, May 17, 2017 at 11:57 AM, Vidura Nanayakkara 
wrote:


> Since we are not aware of the 'Authorizer' implementations that can be in
> a product (persisting and retrieving permissions logic) we cannot provide a
> default implementation to the 'Authorizer'.
>

Thanks Vidura! Would you mind explaining why each product has to implement
it's own authorizer?

Thanks
Imesh
​

> This has been documented in the 'Authorizer' interface [1].
>
> [1] https://github.com/wso2/carbon-uuf/blob/3fbf10907747806d6311acef2095e5
> a8b623e339/components/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/
> Authorizer.java
>
> Best Regards,
> Vidura Nanayakkara
>
> On Wed, May 17, 2017 at 10:27 AM, Chandana Napagoda 
> wrote:
>
>> Hi Imesh,
>>
>> I think during the offline meeting, we have already discussed about the
>> default implementation.
>>
>> @ViduraN, Can you please elaborate it in here?
>>
>> Regards,
>> Chandana
>>
>> On Wed, May 17, 2017 at 10:08 AM, Imesh Gunaratne  wrote:
>>
>>> As we discussed offline I think it would be better to provide a default
>>> implementation for $subject while providing the extension point.
>>>
>>> Thanks
>>>
>>> On Wed, May 3, 2017 at 10:47 AM, SajithAR Ariyarathna >> > wrote:
>>>
 Hi All,

 We are in the process of introducing an extensible authorizer for
 Carbon UUF.

 At the moment authorization is done via the org.wso2.carbon.uuf.spi.au
 th.User interface [1]. When creating an user session, implementation
 of the User interface (e.g. CaasUser [2]) should be passed. The main
 drawback of this approach is, the logic in the hasPermission() method
 has to be serializable. Usually this is difficult to achieve because in
 order to evaluate permissions one might need to access some user management
 services (e.g. Realm Service) which cannot be serialized. Hence moving the
 hasPermission() method out of the User class and allowing to plug-in a
 custom authorizer would be a better approach.

 WDYT?

 [1] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/compo
 nents/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/User.java#L28
 [2] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/sampl
 es/osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundl
 e/src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle
 /CaasUser.java

 Thanks.
 --
 Sajith Janaprasad Ariyarathna
 Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
 

>>>
>>>
>>>
>>> --
>>> *Imesh Gunaratne*
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
>>> W: https://medium.com/@imesh TW: @imesh
>>> lean. enterprise. middleware
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Chandana Napagoda*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.org
>>
>> *Email  :  chand...@wso2.com **Mobile : +94718169299
>> <+94%2071%20816%209299>*
>>
>> *Blog  :http://cnapagoda.blogspot.com 
>> | http://chandana.napagoda.com *
>>
>> *Linkedin : http://www.linkedin.com/in/chandananapagoda
>> *
>>
>>
>
>
> --
> Best Regards,
>
> *Vidura Nanayakkara*
> Software Engineer
>
> Email : vidu...@wso2.com
> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
> Web : http://wso2.com
> Blog : https://medium.com/@viduran 
> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
> 
>



-- 
*Imesh Gunaratne*
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] API Editor Application

[Chanaka Jayasena]

org.wso2.carbon.apimgt.publisher.commons component is use to share
fragments, layouts etc between different apps. This can be use to share any
UI level common functionalities.

thanks,
Chanaka

On Wed, May 17, 2017 at 12:29 PM, Chamin Dias  wrote:

> Hi Tharika,
>
>
   In API Manager, we will be exposing an application called the API
 Editor which is basically a subset of the API Publisher.

>>>
> Since this is a subset of API Publisher, it would be better to list down
> and finalize the features of API Editor which are going to be inherited
> from Publisher. The reason is, it will help us to come up with an effective
> implementation mechanism (like reusing existing functions etc.). WDYT?
>
>
>> The Editor application is *run locally* in the API developers machine
 and is used primarily for API *testing purposes*.

>>>
> --
> Chamin Dias
> Mobile : +94 (0) 716 097455 <%2B94%20%280%29%20773%20451194>
> Email : cham...@wso2.com
> LinkedIn : https://www.linkedin.com/in/chamindias
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Chanaka Jayasena
Associate Tech Lead,
email: chan...@wso2.com; cell: +94 77 4464006
blog: http://chanaka3d.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [PET] Microsoft Dynamics CRM Connector

[Kanapriya Kuleswararajan]

Hi All,

I have planned to implement a Microsoft Dynamics Customer Relationship
Management (CRM) connector with the following Methods [1] for initial
version.

Microsoft Dynamics CRM [2]  is now known as Microsoft Dynamics 365 for
Sales, Marketing, and Service. The Web API [3] which is new for Microsoft
Dynamics 365 (online & on-premises), provides a development experience that
can be used across a wide variety of programming languages, platforms, and
devices. The Web API implements the OData (Open Data Protocol), version
4.0, an OASIS standard for building and consuming RESTful APIs over rich
data sources.
Here We have to register a Dynamics 365 app with Azure Active Directory as
mentioned in [4]
( ie, The user must have a Microsoft Dynamics 365 (online) system user
account with administrator role for the Microsoft Office 365 subscription).
So that it can connect to the Microsoft Dynamics 365 server, authenticate
using OAuth [5], and access the web services.

[1]

   - Create - This example creates a new account entity. The response
   OData-EntityId header contains the Uri of the created entity.
   - Associate entities on create - To associate new entities to existing
   entities when they are created and need to set the value of single-valued
   navigation properties using the @odata.bind annotation.
   - Create with data returned - All the data from the created record will
   be returned with a status of 201 (Created).
   - Retrieve - Returns data for an account entity instance with the
   primary key value
   - Retrieve specific properties - To retrieve the entities with the
   specific property values
   - Retrieve using an alternate key - If an entity has an alternate key
   defined, then use the alternate key to retrieve the entity instead of the
   unique identifier for the entity.
   - Retrieve a single property value - To retrieve the value of a single
   property for an entity,
   - Update - Updates an existing account record with the accountid value
   - Update with data returned - To retrieve data from an entity you are
   updating you can compose your PATCH request so that data from the created
   record will be returned with a status of 200 (OK).
   - Update a single property value - To update only a single property value
   - Delete a single property value - To delete the value of a single
   property
   - Upsert an entity - An upsert operation is exactly like an update. The
   difference is that if the entity doesn’t exist it will be created. If it
   already exists, it will be updated.
   - Delete - To delete an entity

[2] https://en.wikipedia.org/wiki/Microsoft_Dynamics_CRM
[3] https://msdn.microsoft.com/en-us/library/mt593051.aspx
[4] https://msdn.microsoft.com/en-us/library/mt622431.aspx
[5]
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code

Please let me know if you have any suggestions on this?

Thanks
Kanapriya Kuleswararajan
Software Engineer | WSO2
Mobile : - 0774894438
Mail : - kanapr...@wso2.com
LinkedIn : - https://www.linkedin.com/in/kanapriya-kules-94712685/

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

Re: [Architecture] [APIM][C5] API Editor Application

[Tharindu Dharmarathna]

Hi Tharika,

After the new implementation of Endpoints. We had removed the Endpoints
directory, and If we only have global endpoints to API it will stored under
this folder. For Api Level Endpoints we stored in same
api-.json file.

On Wed, May 17, 2017 at 11:44 AM, Tharika Madurapperuma 
wrote:

> Hi all,
>
>   In API Manager, we will be exposing an application called the API
> Editor which is basically a subset of the API Publisher. The Editor
> application is *run locally* in the API developers machine and is used
> primarily for API *testing purposes*.
>
> What can be done through the Editor Application?
>
>
>- APIs will be created and stored in the local file system.
>
>   The file structure of the created API will be,
>
>   [image: Inline image 1]
>
>  where *--* is the folder in
> which the configuration files for the API are stored. The Endpoints folder
> contains the api level endpoints for the API.
>
>- API level endpoints are used instead of global endpoints.
>
>


>
>-
>- After creating and testing an API from within the API Editor, the
>API developer can export the API to the Publisher.
>- It supports API import and export.
>- The API can be exported as a zip file and it contains the above file
>structure.
>
> Appreciate your thoughts and concerns.
>
> Thanks,
> Tharika.
>
> --
> *Tharika Madurapperuma*
> Software Engineer | WSO2, Inc.
>
> Email : thar...@wso2.com
> Mobile : +94777875624 <+94%2077%20787%205624>
> Web : http://wso2.com
>
> 
>



-- 

*Tharindu Dharmarathna*Senior Software Engineer
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

Re: [Architecture] [APIM][C5] API Editor Application

[Chamin Dias]

Hi Tharika,


>>>   In API Manager, we will be exposing an application called the API
>>> Editor which is basically a subset of the API Publisher.
>>>
>>
Since this is a subset of API Publisher, it would be better to list down
and finalize the features of API Editor which are going to be inherited
from Publisher. The reason is, it will help us to come up with an effective
implementation mechanism (like reusing existing functions etc.). WDYT?


> The Editor application is *run locally* in the API developers machine and
>>> is used primarily for API *testing purposes*.
>>>
>>
-- 
Chamin Dias
Mobile : +94 (0) 716 097455 <%2B94%20%280%29%20773%20451194>
Email : cham...@wso2.com
LinkedIn : https://www.linkedin.com/in/chamindias
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] API Editor Application

[Lakmali Baminiwatta]

On 17 May 2017 at 12:05, Rajith Roshan  wrote:

> Hi,
>
>
> On Wed, May 17, 2017 at 11:44 AM, Tharika Madurapperuma 
> wrote:
>
>> Hi all,
>>
>>   In API Manager, we will be exposing an application called the API
>> Editor which is basically a subset of the API Publisher. The Editor
>> application is *run locally* in the API developers machine and is used
>> primarily for API *testing purposes*.
>>
>> What can be done through the Editor Application?
>>
>>
>>- APIs will be created and stored in the local file system.
>>
>>   The file structure of the created API will be,
>>
>>   [image: Inline image 1]
>>
>>  where *--* is the folder
>> in which the configuration files for the API are stored. The Endpoints
>> folder contains the api level endpoints for the API.
>>
>>- API level endpoints are used instead of global endpoints.
>>- After creating and testing an API from within the API Editor, the
>>API developer can export the API to the Publisher.
>>- It supports API import and export.
>>
>> Is it necessary to support import feature on the editor. Is there a valid
> use case to import apis into editor.
>

When the developers want to later change the already exported APIs and also
to share the API development through source controlling, importing feature
is required.

Thanks,
Lakmali

>
>>-
>>- The API can be exported as a zip file and it contains the above
>>file structure.
>>
>> Appreciate your thoughts and concerns.
>>
>> Thanks,
>> Tharika.
>>
>> --
>> *Tharika Madurapperuma*
>> Software Engineer | WSO2, Inc.
>>
>> Email : thar...@wso2.com
>> Mobile : +94777875624 <+94%2077%20787%205624>
>> Web : http://wso2.com
>>
>> 
>>
>
>
>
> --
> Rajith Roshan
> Software Engineer, WSO2 Inc.
> Mobile: +94-7 <%2B94-71-554-8430>17-064-214
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Lakmali Baminiwatta
Associate Technical Lead
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
mobile:  +94 71 2335936
blog : lakmali.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] API Editor Application

[Anuruddha Liyanarachchi]

Hi Abimaran,

APIs have some metadata like Icon, Documentation, etc. Don't we have any
> plans to include them? Because API Export/Import should have those as well.


The icon will be exported in the editor but not the documentation.
Documentation is not supported in the editor.

On Wed, May 17, 2017 at 11:59 AM, Abimaran Kugathasan 
wrote:

> Hi Tharika,
>
> APIs have some metadata like Icon, Documentation, etc. Don't we have any
> plans to include them? Because API Export/Import should have those as well.
>
> On Wed, May 17, 2017 at 11:44 AM, Tharika Madurapperuma 
> wrote:
>
>> Hi all,
>>
>>   In API Manager, we will be exposing an application called the API
>> Editor which is basically a subset of the API Publisher. The Editor
>> application is *run locally* in the API developers machine and is used
>> primarily for API *testing purposes*.
>>
>> What can be done through the Editor Application?
>>
>>
>>- APIs will be created and stored in the local file system.
>>
>>   The file structure of the created API will be,
>>
>>   [image: Inline image 1]
>>
>>  where *--* is the folder
>> in which the configuration files for the API are stored. The Endpoints
>> folder contains the api level endpoints for the API.
>>
>>- API level endpoints are used instead of global endpoints.
>>- After creating and testing an API from within the API Editor, the
>>API developer can export the API to the Publisher.
>>- It supports API import and export.
>>- The API can be exported as a zip file and it contains the above
>>file structure.
>>
>> Appreciate your thoughts and concerns.
>>
>> Thanks,
>> Tharika.
>>
>> --
>> *Tharika Madurapperuma*
>> Software Engineer | WSO2, Inc.
>>
>> Email : thar...@wso2.com
>> Mobile : +94777875624 <+94%2077%20787%205624>
>> Web : http://wso2.com
>>
>> 
>>
>
>
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer - API Technologies
>
> Email : abima...@wso2.com
> Mobile : +94 773922820 <+94%2077%20392%202820>
>
> 
> 
>   
> 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Thanks and Regards,*
Anuruddha Lanka Liyanarachchi
Software Engineer - WSO2
Mobile : +94 (0) 712762611
Tel  : +94 112 145 345
a nurudd...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] API Editor Application

[Rajith Roshan]

Hi,


On Wed, May 17, 2017 at 11:44 AM, Tharika Madurapperuma 
wrote:

> Hi all,
>
>   In API Manager, we will be exposing an application called the API
> Editor which is basically a subset of the API Publisher. The Editor
> application is *run locally* in the API developers machine and is used
> primarily for API *testing purposes*.
>
> What can be done through the Editor Application?
>
>
>- APIs will be created and stored in the local file system.
>
>   The file structure of the created API will be,
>
>   [image: Inline image 1]
>
>  where *--* is the folder in
> which the configuration files for the API are stored. The Endpoints folder
> contains the api level endpoints for the API.
>
>- API level endpoints are used instead of global endpoints.
>- After creating and testing an API from within the API Editor, the
>API developer can export the API to the Publisher.
>- It supports API import and export.
>
> Is it necessary to support import feature on the editor. Is there a valid
use case to import apis into editor.

>
>-
>- The API can be exported as a zip file and it contains the above file
>structure.
>
> Appreciate your thoughts and concerns.
>
> Thanks,
> Tharika.
>
> --
> *Tharika Madurapperuma*
> Software Engineer | WSO2, Inc.
>
> Email : thar...@wso2.com
> Mobile : +94777875624 <+94%2077%20787%205624>
> Web : http://wso2.com
>
> 
>



-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Nuwan Dias]

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.

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. There
are cases when he needs to blocks certain Apps but never his entire API. So
I think its a very edge case requirement to have a Blocked state in the
lifecycle and hence I don't think we should be supporting it as a first
class feature. Therefore I suggest that we take off the capability of
blocking APIs from the Publisher app completely. The admin can still block
APIs in the usual way (through the admin portal).

If by any chance this edge case requirement comes up, the publisher can
either set the endpoint throttling limit to 0req/min or put up a temporary
ballerina code to say the API is blocked. This way we avoid having many
mechanisms of performing the same action (lesser complications = increased
stability) and avoid having to support a feature for a minority user base
(actually 0 in my personal experience).

On Wed, May 17, 2017 at 11:50 AM, Yasima Dewmini  wrote:

> Hi All,
>
> As in the previous APIM versions, there were 4 ways to block an
> API/Subscription.
>
> *1. Block an API using API lifecycle "Blocked" state*
>
> API owner can block an API in publisher using API lifecycle. This will
> temporarily block an API and can be promoted to "Published" state again.
>
>
>
> *2. Block a subscription*
> Publisher can block subscriptions using manage subscription. This can be
> used to block an app in Production level or in both Production and Sandbox
> levels.
>
>
>
> *3. Throttle level blocking*
> An specific endpoint can be blocked by setting Production and Sandbox TPS to
> 0 in publisher .
>
>
>
> *4. Block an API using Admin dashboard*An API can be blocked using Black
> List feature in Admin dashboard.
>
> As per discussion within the team, we came to a conclusion to remove the
> "Blocked" state from API lifecycle which is used to block an API, since it
> is an edge case where API owner blocks his own API in publisher. If an API
> needs to be blocked it can be done using 2,3 or 4.
>
> Please share your thoughts on this.
>
> Regards,
> Yasima.
>
> --
> http://wso2.com/signatureYasima Dewmini
> Software Engineer, WSO2, Inc.
> Email: yas...@wso2.com
> Mobile: +94713117081 <+94%2071%20311%207081>
>



-- 
Nuwan Dias

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

Re: [Architecture] [APIM][C5] API Editor Application

[Abimaran Kugathasan]

Hi Tharika,

APIs have some metadata like Icon, Documentation, etc. Don't we have any
plans to include them? Because API Export/Import should have those as well.

On Wed, May 17, 2017 at 11:44 AM, Tharika Madurapperuma 
wrote:

> Hi all,
>
>   In API Manager, we will be exposing an application called the API
> Editor which is basically a subset of the API Publisher. The Editor
> application is *run locally* in the API developers machine and is used
> primarily for API *testing purposes*.
>
> What can be done through the Editor Application?
>
>
>- APIs will be created and stored in the local file system.
>
>   The file structure of the created API will be,
>
>   [image: Inline image 1]
>
>  where *--* is the folder in
> which the configuration files for the API are stored. The Endpoints folder
> contains the api level endpoints for the API.
>
>- API level endpoints are used instead of global endpoints.
>- After creating and testing an API from within the API Editor, the
>API developer can export the API to the Publisher.
>- It supports API import and export.
>- The API can be exported as a zip file and it contains the above file
>structure.
>
> Appreciate your thoughts and concerns.
>
> Thanks,
> Tharika.
>
> --
> *Tharika Madurapperuma*
> Software Engineer | WSO2, Inc.
>
> Email : thar...@wso2.com
> Mobile : +94777875624 <+94%2077%20787%205624>
> Web : http://wso2.com
>
> 
>



-- 
Thanks
Abimaran Kugathasan
Senior Software Engineer - API Technologies

Email : abima...@wso2.com
Mobile : +94 773922820


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

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

[Nirmal Fernando]

On Wed, May 17, 2017 at 11:50 AM, Yasima Dewmini  wrote:

> Hi All,
>
> As in the previous APIM versions, there were 4 ways to block an
> API/Subscription.
>
> *1. Block an API using API lifecycle "Blocked" state*
>
> API owner can block an API in publisher using API lifecycle. This will
> temporarily block an API and can be promoted to "Published" state again.
>
>
>
> *2. Block a subscription*
> Publisher can block subscriptions using manage subscription. This can be
> used to block an app in Production level or in both Production and Sandbox
> levels.
>
>
>
> *3. Throttle level blocking*
> An specific endpoint can be blocked by setting Production and Sandbox TPS to
> 0 in publisher .
>
>
>
> *4. Block an API using Admin dashboard*An API can be blocked using Black
> List feature in Admin dashboard.
>
> As per discussion within the team, we came to a conclusion to remove the
> "Blocked" state from API lifecycle which is used to block an API, since it
> is an edge case where API owner blocks his own API in publisher. If an API
> needs to be blocked it can be done using 2,3 or 4.
>

Aren't those work-arounds? I think users would prefer to have a single
place to block further invocations/subscriptions of an API.

>
> Please share your thoughts on this.
>
> Regards,
> Yasima.
>
> --
> http://wso2.com/signatureYasima Dewmini
> Software Engineer, WSO2, Inc.
> Email: yas...@wso2.com
> Mobile: +94713117081 <+94%2071%20311%207081>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

Thanks & regards,
Nirmal

Technical Lead, WSO2 Inc.
Mobile: +94715779733
Blog: http://nirmalfdo.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Yasima Dewmini]

Hi All,

As in the previous APIM versions, there were 4 ways to block an
API/Subscription.

*1. Block an API using API lifecycle "Blocked" state*

API owner can block an API in publisher using API lifecycle. This will
temporarily block an API and can be promoted to "Published" state again.



*2. Block a subscription*
Publisher can block subscriptions using manage subscription. This can be
used to block an app in Production level or in both Production and Sandbox
levels.



*3. Throttle level blocking*
An specific endpoint can be blocked by setting Production and Sandbox TPS to
0 in publisher .



*4. Block an API using Admin dashboard*An API can be blocked using Black
List feature in Admin dashboard.

As per discussion within the team, we came to a conclusion to remove the
"Blocked" state from API lifecycle which is used to block an API, since it
is an edge case where API owner blocks his own API in publisher. If an API
needs to be blocked it can be done using 2,3 or 4.

Please share your thoughts on this.

Regards,
Yasima.

-- 
http://wso2.com/signatureYasima Dewmini
Software Engineer, WSO2, Inc.
Email: yas...@wso2.com
Mobile: +94713117081 <+94%2071%20311%207081>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM][C5] API Editor Application

[Tharika Madurapperuma]

Hi all,

  In API Manager, we will be exposing an application called the API
Editor which is basically a subset of the API Publisher. The Editor
application is *run locally* in the API developers machine and is used
primarily for API *testing purposes*.

What can be done through the Editor Application?


   - APIs will be created and stored in the local file system.

  The file structure of the created API will be,

  [image: Inline image 1]

 where *--* is the folder in
which the configuration files for the API are stored. The Endpoints folder
contains the api level endpoints for the API.

   - API level endpoints are used instead of global endpoints.
   - After creating and testing an API from within the API Editor, the API
   developer can export the API to the Publisher.
   - It supports API import and export.
   - The API can be exported as a zip file and it contains the above file
   structure.

Appreciate your thoughts and concerns.

Thanks,
Tharika.

-- 
*Tharika Madurapperuma*
Software Engineer | WSO2, Inc.

Email : thar...@wso2.com
Mobile : +94777875624
Web : http://wso2.com


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