Re: [Architecture] Carbon C5 - Server Configuration Model

[Imesh Gunaratne]

Thanks for the clarification Danesh! In that situation, we might need to
maintain a default value configuration file per feature or component.

On Wed, Mar 8, 2017 at 10:37 AM, Danesh Kuruppu  wrote:

> Hi Imesh,
>
> Shall we use the same default.yaml to define datasources with default
>>> configuration of the product. because in carbon-datasources, we don't have
>>> default database configurations and there are coming from different
>>> components. but we read datasources configuration from carbon-datasources.
>>> So we need a place to get the default values, if it is not specified in
>>> deployment.yaml.
>>>
>>
>> ​According to the initial discussion we had, may be we can have the
>> default values in the code using annotations. Do we see any problems with
>> that?
>>
>
> The Problem here is, bean classes related to datasources are defined in
> carbon-datasources, but the component doesn't contain any default values.
> It creates databsource objects based on the config files in the datasources
> directory(in C4, it is based on master-datasources.xml, etc) and
> configuration files are created or modified at product level.
>
> e.g.: If APIM needs separate datasource, it adds related configuration to
> the datasource config files. So at runtime, carbon-datasources component
> reads configuration and creates related datasource objects.
>
> With the new config model, it is not mandatory to have those configuration
> in deployment.yaml. So we need to have a place where we can get the default
> values if it is not specified in the deployment.yaml.
>
> Thanks
> Danesh
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc 
>
>


-- 
*Imesh Gunaratne*
Software Architect
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] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Imesh,

Shall we use the same default.yaml to define datasources with default
>> configuration of the product. because in carbon-datasources, we don't have
>> default database configurations and there are coming from different
>> components. but we read datasources configuration from carbon-datasources.
>> So we need a place to get the default values, if it is not specified in
>> deployment.yaml.
>>
>
> ​According to the initial discussion we had, may be we can have the
> default values in the code using annotations. Do we see any problems with
> that?
>

The Problem here is, bean classes related to datasources are defined in
carbon-datasources, but the component doesn't contain any default values.
It creates databsource objects based on the config files in the datasources
directory(in C4, it is based on master-datasources.xml, etc) and
configuration files are created or modified at product level.

e.g.: If APIM needs separate datasource, it adds related configuration to
the datasource config files. So at runtime, carbon-datasources component
reads configuration and creates related datasource objects.

With the new config model, it is not mandatory to have those configuration
in deployment.yaml. So we need to have a place where we can get the default
values if it is not specified in the deployment.yaml.

Thanks
Danesh
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Imesh Gunaratne]

On Tue, Mar 7, 2017 at 11:09 PM, Danesh Kuruppu  wrote:

> Hi all,
>
> Shall we use the same default.yaml to define datasources with default
> configuration of the product. because in carbon-datasources, we don't have
> default database configurations and there are coming from different
> components. but we read datasources configuration from carbon-datasources.
> So we need a place to get the default values, if it is not specified in
> deployment.yaml.
>

​According to the initial discussion we had, may be we can have the default
values in the code using annotations. Do we see any problems with that?

Thanks
Imesh


> Thanks
> Danesh
>
> On Thu, Feb 2, 2017 at 10:16 AM, Sagara Gunathunga 
> wrote:
>
>>
>> We (myself and Azeez) had a offline chat about this requirement, it seems
>> it would be much flexible for both users and product teams if
>> deployment.yaml processing framework can support 3 levels instead of 2 :
>> Component, Product, User
>>
>> Component level  : - Component author define default values within the
>> bean class if  'default values' concept is applicable.
>> Product level:-  Product team override component level default
>> values using 'defaults.yaml' file ( within the WSO2 file space )
>> User level :-  User can override component or product level
>> default values using deployment.yaml file
>>
>> The main advantage here is we can clearly separate responsibilities and
>> scope of each group and possible to ship deployment.yaml with absolutely
>> zero content.  This is the same concept suggested by Ruwan with few
>> modifications.
>>
>> Thanks !
>>
>> On Thu, Feb 2, 2017 at 9:36 AM, Afkham Azeez  wrote:
>>
>>> This is out of the scope of the deployment.yaml processing framework
>>> Danesh wrote. If you want to have default connectors or config, you can
>>> either write a product-specific component which programmatically creates
>>> those, or you can ship that in the product specific deployment.yaml.
>>>
>>> On Thu, Feb 2, 2017 at 7:24 AM, Sagara Gunathunga 
>>> wrote:
>>>


 On Wed, Feb 1, 2017 at 11:11 PM, Danesh Kuruppu 
 wrote:

> Hi Jayanga,
>
> it is defaulted to the component. any product which is using the
> component will get the same default values. If a product need values other
> than the default value, they have to override it in the deployment.yaml.
> default values should be component related values, not related for the
> specific product.
>

 This is true in ideal cases but practically we have more complex use
 cases, taking the same example identity-mgt is a generic F/W kind of a
 component which allows to register/manage IdentityStore connectors and
 there is no component level default connector concept, it's just a
 registration/management capability, only in product level(IS) we ship
 default  IdentityStore connectors.  Here we have 2 options ..

 1.) As there is no default connector in component level, all the
 products including IS has to provide default connectors  in
  deployment.yaml, then this is not kind of value overridden and when number
 of such components increase default size of the deployment.yaml will
 increase which again result into deviate from original motivation of
 deployment.yaml.


 2. ) In cases of components do not have default values we can hard cord
 default values according to the base product, in this way at least base
 product  can keep deployment.yaml clean.

 WDYT ?


 Thanks !


>
> Thanks
> Danesh
>
> On Wed, Feb 1, 2017 at 3:58 AM, Jayanga Kaushalya 
> wrote:
>
>> Hi,
>>
>> If we are hard-coding default values to the bean class, are those
>> values should be default to the component or to the product which is
>> (frequently) using that component ? If we use default values related to 
>> the
>> product then we can use that values directly in the specific product and 
>> if
>> some other product is using that component, they have to override it in 
>> the
>> deployment.yaml. For example product-is is using component identity-mgt. 
>> So
>> what should be the default values for the config files coming from
>> identity-mgt component ? Are those should be defaulted to the product-is
>> related values or to the component related values and product-is should
>> always override them from deployment.yaml.
>>
>> Thanks!
>>
>> *Jayanga Kaushalya*
>> Software Engineer
>> Mobile: +94777860160 <+94%2077%20786%200160>
>> WSO2 Inc. | http://wso2.com
>> lean.enterprise.middleware
>>
>> On Wed, Nov 30, 2016 at 10:57 AM, Danesh Kuruppu 
>> wrote:
>>
>>> Hi Dilan,
>>>
>>> If all user-configurable properties are 

Re: [Architecture] Claim dialect must have two special attributes indicating "userid" claim URI and "role" claim URI.

[Isuru Haththotuwa]

Hi Johann,

On Mon, Mar 6, 2017 at 3:09 AM, Johann Nallathamby  wrote:

> Hi All,
>
> Any foreign dialect that we define using claim management, must have two
> special attributes indicating the "userid" claim and the "role" claim.
>
> "userid" claim is required for use cases like authentication and
> provisioning. "role" claim is needed for role mapping and access control.
>
Apologies if this is something obvious, what exactly does the user id mean
in a claim context? Is it related to the issuer, or the subject?


>
> In C4 we had this at the IDP configuration level. In C5, since we have
> extracted all the claim configuration from IDP to "claim management", and
> just refer to the dialect alone in IDP configuration, we need to identify
> these two special attributes also in the claim dialect management level.
> This configuration will be fixed for any real IDP.
>
> What are your ideas?
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks and Regards,

Isuru H.
+94 716 358 048* *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] WSO2 IoT server supporting OMA Lightweight M2M protocol (OMA LWM2M)

[Inosh Perera]

Hi Ching,

Thanks for the references.

Regards,
Inosh

On Tue, Mar 7, 2017 at 8:21 PM, Ching Shi  wrote:

> OMA DM is a device management protocol which was introduced by Open Mobile
> Alliance for Smart Phones, Tablets and Laptops. OMA Lightweight M2M (LWM2M)
> was then introduced for the IoT market. LWM2M is applicable for various
> radio technologies. (devices just need IP connectivity).
>
> A detailed documentation is available in the below link.
>
> https://www.iab.org/wp-content/IAB-uploads/2016/03/
> OMA_LightweighM2M_Resource_Model_Summary.pdf
>
> I edited the original Eclipse Leshan Server to handle security and the
> repository could be found in the below link.
>
> https://github.com/ctienshi/SSO-Leshan
>
> A detailed documentation on how to configure Single Sign On with the WSO2
> IoT 5.0.0 pack could be found in the below blog.
> https://stienblog.wordpress.com/2017/03/06/configuring-
> eclipse-leshan-server-with-wso2-iot-server/
>
> Thanks and Best Regards.
>
> On Tue, Mar 7, 2017 at 4:30 PM, Kamidu Punchihewa 
> wrote:
>
>> Hi Inosh,
>>
>> LWM2M Leshan server provides a restful interface where all the
>> characteristics/properties are represent by an integer. You can find a more
>> details including the features and the usability of Leshan server in there
>> home page's getting started section[1] .
>>
>> Thanks and Best Regards,
>>
>> Kamidu Sachith Punchihewa
>> *Software Engineer*
>> WSO2, Inc.
>> lean . enterprise . middleware
>> Mobile : +94 (0) 770566749 <%2B94%20%280%29%20773%20451194>
>>
>> Please Note that I have dyslexia and it may results in few misspelled
>> words in the content.
>>
>> Disclaimer: This communication may contain privileged or other
>> confidential information and is intended exclusively for the addressee/s.
>> If you are not the intended recipient/s, or believe that you may have
>> received this communication in error, please reply to the sender indicating
>> that fact and delete the copy you received and in addition, you should not
>> print, copy, retransmit, disseminate, or otherwise use the information
>> contained in this communication. Internet communications cannot be
>> guaranteed to be timely, secure, error or virus-free. The sender does not
>> accept liability for any errors or omissions.
>>
>> On Tue, Mar 7, 2017 at 3:38 PM, Sumedha Rubasinghe 
>> wrote:
>>
>>> Hi Ching,
>>> Could you list out the exact set of steps needed to get this to working
>>> please?
>>>
>>>
>>> On Tue, Mar 7, 2017 at 9:53 AM, Ching Shi  wrote:
>>>
 Hi all,

 OMA Lightweight M2M protocol is from the Open Mobile Alliance for IoT
 device management. This protocol provides,

1. Device management functionalities over sensor or cellular
networks
2. Transfer service data from the network to devices

 Lightweight M2M enabler defines the application layer communication
 protocol between a LWM2M server and a LWM2M client. The target LWM2M
 devices for this enabler are mainly resource constrained devices. Therefore
 this enabler makes use of a light and compact protocol as well as an
 efficient resource data model.

 Eclipse Leshan is an open source project which consists of a
 Lightweight M2M server. Leshan also consists of a LWM2M client which could
 run on any Linux Distribution. For example if the LWM2M client is running
 in a Raspberry Pi it could communicate with the LWM2M Server.

 The Eclipse Leshan Server is now integrated with the WSO2 IoT Server
 providing OMA Lightweight M2M. Initially the Eclipse Leshan Server wasn't
 handling any security. Authentication and authorisation is now handled in
 the Eclipse Leshan Server and Single Sign On (SSO) is configured with the
 WSO2 IoT Server.


 --
 Ching Tien Shi
 Intern - Engineering
 Mobile : +94770186272 <077%20018%206272>



 --
 Ching Tien Shi
 Intern - Engineering
 Mobile : +94770186272 <077%20018%206272>


>>>
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Ching Tien Shi
> Intern - Engineering
> Mobile : +94770186272 <+94%2077%20018%206272>
>



-- 
Inosh Perera
Senior Software Engineer, WSO2 Inc.
Tel: 077813 7285, 0785293686
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] A Claim MUST have a Issuer

[Prabath Siriwardena]

+1 for issuer - but please plan this post IS 6.0.0

Thanks & regards,
-Prabath

On Tue, Mar 7, 2017 at 11:16 AM, Johann Nallathamby  wrote:

>
>
> On Tue, Mar 7, 2017 at 2:12 PM, Ishara Karunarathna 
> wrote:
>
>> Hi Johan,
>>
>>
>>
>> On Mon, Feb 27, 2017 at 10:51 AM, Johann Nallathamby 
>> wrote:
>>
>>> In claims based identity management we MUST have a "Issuer" for each
>>> claim. Each claim is made by an issuer, and you trust the claim only as
>>> much as you trust the issuer.
>>>
>>> For example, you will trust a claim made by your organization's internal
>>> IDP connected to the internal identity store, more than you trust a claim
>>> made by the user himself.
>>>
>> Are we going to use this within the server. For example we can write a
>> policy using issuer of the claims.
>>
>
> Yes, that the idea.
>
>
>>
>> And do we expect to send these information to connecting service
>> providers.
>> if so it may be a custom attribute that we need to send to customers such
>> as authenticated IDP list.
>>
>
> Have to check the SAML2 spec properly, but I am thinking if it in fact
> supports this as part of the standard itself. Can we have multiple
> assertions in a SAML2 response with each assertion issued by a different
> issuer? Then there can be attribute statements under each assertion that
> can contain the claims issued by that particular issuer.
>
> We may be able to come up with something semantic that is similar for JWT
> (OIDC).
>
> The question that came to mind is how do we store the issuer values for
> the claims? Because the claims themselves are stored as attributes in LDAP
> user stores. Then how can we have a associated property for the attribute
> which specifies the issuer? What I thought was we should be able to use the
> issuer value for processing requests on the fly, e.g. authorization, etc.
> But if we want to store them we need to be able to use our multiple user
> domain feature to split the user profile by issuer and store in multiple
> identity stores. This way each identity store will contain attribute from
> one issuer if we want to provision them. I think most other implementation
> out there also mention their identity store as the issuer.
>
> Regards,
> Johann.
>
>
>>
>> -Ishara
>>
>>
>>>
>>> Our current "Claim" object model contains following attributes [1].
>>> 1. Dialect URI
>>> 2. Claim URI
>>> 3. Value
>>>
>>> Can we add "Issuer" attribute also to this model?
>>>
>>> [1] https://github.com/wso2/carbon-identity-mgt/blob/master/
>>> components/org.wso2.carbon.identity.mgt/src/main/java/org/ws
>>> o2/carbon/identity/mgt/claim/Claim.java
>>>
>>> Regards,
>>> Johann.
>>>
>>> --
>>>
>>> *Johann Dilantha Nallathamby*
>>> Technical Lead & Product Lead of WSO2 Identity Server
>>> Governance Technologies Team
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+9476950*
>>> Blog - *http://nallaa.wordpress.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>
>>
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>



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

Re: [Architecture] A Claim MUST have a Issuer

[Johann Nallathamby]

On Tue, Mar 7, 2017 at 2:12 PM, Ishara Karunarathna 
wrote:

> Hi Johan,
>
>
>
> On Mon, Feb 27, 2017 at 10:51 AM, Johann Nallathamby 
> wrote:
>
>> In claims based identity management we MUST have a "Issuer" for each
>> claim. Each claim is made by an issuer, and you trust the claim only as
>> much as you trust the issuer.
>>
>> For example, you will trust a claim made by your organization's internal
>> IDP connected to the internal identity store, more than you trust a claim
>> made by the user himself.
>>
> Are we going to use this within the server. For example we can write a
> policy using issuer of the claims.
>

Yes, that the idea.


>
> And do we expect to send these information to connecting service providers.
> if so it may be a custom attribute that we need to send to customers such
> as authenticated IDP list.
>

Have to check the SAML2 spec properly, but I am thinking if it in fact
supports this as part of the standard itself. Can we have multiple
assertions in a SAML2 response with each assertion issued by a different
issuer? Then there can be attribute statements under each assertion that
can contain the claims issued by that particular issuer.

We may be able to come up with something semantic that is similar for JWT
(OIDC).

The question that came to mind is how do we store the issuer values for the
claims? Because the claims themselves are stored as attributes in LDAP user
stores. Then how can we have a associated property for the attribute which
specifies the issuer? What I thought was we should be able to use the
issuer value for processing requests on the fly, e.g. authorization, etc.
But if we want to store them we need to be able to use our multiple user
domain feature to split the user profile by issuer and store in multiple
identity stores. This way each identity store will contain attribute from
one issuer if we want to provision them. I think most other implementation
out there also mention their identity store as the issuer.

Regards,
Johann.


>
> -Ishara
>
>
>>
>> Our current "Claim" object model contains following attributes [1].
>> 1. Dialect URI
>> 2. Claim URI
>> 3. Value
>>
>> Can we add "Issuer" attribute also to this model?
>>
>> [1] https://github.com/wso2/carbon-identity-mgt/blob/master/
>> components/org.wso2.carbon.identity.mgt/src/main/java/org/ws
>> o2/carbon/identity/mgt/claim/Claim.java
>>
>> Regards,
>> Johann.
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Technical Lead & Product Lead of WSO2 Identity Server
>> Governance Technologies Team
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.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>
>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS-6.0.0] SCIM list resources with multiple user stores

[Johann Nallathamby]

On Tue, Mar 7, 2017 at 9:43 AM, Ishara Karunarathna 
wrote:

> Hi,
>
> In SCIM domain is used to represent the whole administrative provisioning
> system . So I don't think domain discuss in the spec directly map to the
> domain concept we have.
>
> In the spec when defining the tenants they have the option to use tenant
> domain as a path parameter or sub domain.
>
> A URL prefix: "https://www.example.com/Tenants/{tenant_id}/v2/Users;.
> A sub-domain: "https://{tenant_id}.example.com/v2/Groups;.
>
> I think better if we can follow the same patter to userDomains.
>

The  problem with this approach is we can't cater for Omindu's requirement,
to be able to give multiple domains and say to search from them. So I also
feel going with query parameters is a good option, since SCIM 2.0 allows to
use custom parameters. Also we don't need to represent a identity store as
part of the resource URL. Its OK for tenants because one tenant will only
have one URL. But when it comes to identity stores, one tenant will then
have multiple URLs which is not spec compliant I guess.

So +1 for query parameters. And by the way +1 to use a different name to
avoid confusion.

Regards,
Johann.


> -Ishara
>
> On Sat, Mar 4, 2017 at 8:01 PM, Vindula Jayawardana <
> vindula...@cse.mrt.ac.lk> wrote:
>
>> Hi,
>>
>> According to SCIM protocol specification[1], SCIM service providers may
>> support additional query parameters apart from the standard set of query
>> parameters in querying resources. Hence +1 for what Gayan has proposed here.
>>
>> I also agree with what Omindu has proposed. I think we could even add the
>> domain as an extension attribute rather adding it to username if necessary.
>> However, due to the fact that IS only supports one simple filter with "eq"
>> as the filter operation, by doing this way, we are limiting the client's
>> ability to query a resource using another filter. For an example what if
>> the client wants to query all users with "userType+EQ+student" in a domain
>> of "". Since one filter is already used, this kind of queries will not
>> be fitted in. But in the Gayan's method this can be done with the following
>> query request.
>>
>> /scim/v2/Users?filter=userType+EQ+student=
>>
>>
>> [1] - https://tools.ietf.org/html/rfc7644#section-3.4.2
>>
>> *Vindula Jayawardana*
>> Computer Science and Engineering Dept.
>> University of Moratuwa
>> mobile : +713462554
>> Email : vindul...@gmail.com
>>
>> 
>> 
>> 
>> 
>>
>> *“Respect is how to treat everyone, not just those you want to impress. "*
>>
>>
>> *-Richard Branson-*
>>
>>
>>
>> On 3 March 2017 at 18:41, Omindu Rathnaweera  wrote:
>>
>>> Hi Gayan,
>>>
>>> Does the protocol permits introducing custom parameters as domain? If so
>>>  +1 for using a param. Else, we can include the domain name as a part of
>>> the username (IINM we support this in C4 as well), so searching only in a
>>> particular domain will look like below.
>>>
>>> /scim/v2/Users?filter=userName+EQ+FOODOMAIN/*
>>>
>>> Also, should we look into searching within multiple domains ? Currently
>>> we can only search either in a single domain or in all domains. However,
>>> the identity store does not have this support yet.
>>>
>>> Regards,
>>> Omindu.
>>>
>>> On Thu, Mar 2, 2017 at 11:41 PM, Gayan Gunawardana 
>>> wrote:
>>>
 Hi All,

 How are we going to support SCIM list all users and list all groups
 operations when we have multiple user store domains. In C4 we could iterate
 through all user stores and fetch results but in C5 we highly discourage
 such a functionality due to performance impact.

 Basically client need to provide user store domain, when it requires
 data from secondary user store domains.

 My suggestion is to support custom parameter like "domain" so requests
 will be like below.

 /scim/v2/Users?domain=

 /scim/v2/Users?startIndex=1=2=


 /scim/v2/Users?filter=userName+EQ+vindula=


 @Ishara, Johann, Ayoma appreciate your input.


 Thanks,

 Gayan

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

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


>>>
>>>
>>> --
>>> Omindu Rathnaweera
>>> Software Engineer, WSO2 Inc.
>>> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> 

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi all,

Shall we use the same default.yaml to define datasources with default
configuration of the product. because in carbon-datasources, we don't have
default database configurations and there are coming from different
components. but we read datasources configuration from carbon-datasources.
So we need a place to get the default values, if it is not specified in
deployment.yaml.

Thanks
Danesh

On Thu, Feb 2, 2017 at 10:16 AM, Sagara Gunathunga  wrote:

>
> We (myself and Azeez) had a offline chat about this requirement, it seems
> it would be much flexible for both users and product teams if
> deployment.yaml processing framework can support 3 levels instead of 2 :
> Component, Product, User
>
> Component level  : - Component author define default values within the
> bean class if  'default values' concept is applicable.
> Product level:-  Product team override component level default
> values using 'defaults.yaml' file ( within the WSO2 file space )
> User level :-  User can override component or product level
> default values using deployment.yaml file
>
> The main advantage here is we can clearly separate responsibilities and
> scope of each group and possible to ship deployment.yaml with absolutely
> zero content.  This is the same concept suggested by Ruwan with few
> modifications.
>
> Thanks !
>
> On Thu, Feb 2, 2017 at 9:36 AM, Afkham Azeez  wrote:
>
>> This is out of the scope of the deployment.yaml processing framework
>> Danesh wrote. If you want to have default connectors or config, you can
>> either write a product-specific component which programmatically creates
>> those, or you can ship that in the product specific deployment.yaml.
>>
>> On Thu, Feb 2, 2017 at 7:24 AM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Wed, Feb 1, 2017 at 11:11 PM, Danesh Kuruppu  wrote:
>>>
 Hi Jayanga,

 it is defaulted to the component. any product which is using the
 component will get the same default values. If a product need values other
 than the default value, they have to override it in the deployment.yaml.
 default values should be component related values, not related for the
 specific product.

>>>
>>> This is true in ideal cases but practically we have more complex use
>>> cases, taking the same example identity-mgt is a generic F/W kind of a
>>> component which allows to register/manage IdentityStore connectors and
>>> there is no component level default connector concept, it's just a
>>> registration/management capability, only in product level(IS) we ship
>>> default  IdentityStore connectors.  Here we have 2 options ..
>>>
>>> 1.) As there is no default connector in component level, all the
>>> products including IS has to provide default connectors  in
>>>  deployment.yaml, then this is not kind of value overridden and when number
>>> of such components increase default size of the deployment.yaml will
>>> increase which again result into deviate from original motivation of
>>> deployment.yaml.
>>>
>>>
>>> 2. ) In cases of components do not have default values we can hard cord
>>> default values according to the base product, in this way at least base
>>> product  can keep deployment.yaml clean.
>>>
>>> WDYT ?
>>>
>>>
>>> Thanks !
>>>
>>>

 Thanks
 Danesh

 On Wed, Feb 1, 2017 at 3:58 AM, Jayanga Kaushalya 
 wrote:

> Hi,
>
> If we are hard-coding default values to the bean class, are those
> values should be default to the component or to the product which is
> (frequently) using that component ? If we use default values related to 
> the
> product then we can use that values directly in the specific product and 
> if
> some other product is using that component, they have to override it in 
> the
> deployment.yaml. For example product-is is using component identity-mgt. 
> So
> what should be the default values for the config files coming from
> identity-mgt component ? Are those should be defaulted to the product-is
> related values or to the component related values and product-is should
> always override them from deployment.yaml.
>
> Thanks!
>
> *Jayanga Kaushalya*
> Software Engineer
> Mobile: +94777860160 <+94%2077%20786%200160>
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>
> On Wed, Nov 30, 2016 at 10:57 AM, Danesh Kuruppu 
> wrote:
>
>> Hi Dilan,
>>
>> If all user-configurable properties are not readily available in the
>>> .yaml file by default, how would a user know which
>>> properties are configurable and which are not ?
>>>
>>
>> All the configurable properties and their default values will be
>> documented. We are going to create this config document automatically by
>> reading the config bean class (using maven plugin).
>> 

Re: [Architecture] WSO2 IoT server supporting OMA Lightweight M2M protocol (OMA LWM2M)

[Ching Shi]

OMA DM is a device management protocol which was introduced by Open Mobile
Alliance for Smart Phones, Tablets and Laptops. OMA Lightweight M2M (LWM2M)
was then introduced for the IoT market. LWM2M is applicable for various
radio technologies. (devices just need IP connectivity).

A detailed documentation is available in the below link.

https://www.iab.org/wp-content/IAB-uploads/2016/03/OMA_LightweighM2M_Resource_Model_Summary.pdf

I edited the original Eclipse Leshan Server to handle security and the
repository could be found in the below link.

https://github.com/ctienshi/SSO-Leshan

A detailed documentation on how to configure Single Sign On with the WSO2
IoT 5.0.0 pack could be found in the below blog.
https://stienblog.wordpress.com/2017/03/06/configuring-eclipse-leshan-server-with-wso2-iot-server/

Thanks and Best Regards.

On Tue, Mar 7, 2017 at 4:30 PM, Kamidu Punchihewa  wrote:

> Hi Inosh,
>
> LWM2M Leshan server provides a restful interface where all the
> characteristics/properties are represent by an integer. You can find a more
> details including the features and the usability of Leshan server in there
> home page's getting started section[1] .
>
> Thanks and Best Regards,
>
> Kamidu Sachith Punchihewa
> *Software Engineer*
> WSO2, Inc.
> lean . enterprise . middleware
> Mobile : +94 (0) 770566749 <%2B94%20%280%29%20773%20451194>
>
> Please Note that I have dyslexia and it may results in few misspelled
> words in the content.
>
> Disclaimer: This communication may contain privileged or other
> confidential information and is intended exclusively for the addressee/s.
> If you are not the intended recipient/s, or believe that you may have
> received this communication in error, please reply to the sender indicating
> that fact and delete the copy you received and in addition, you should not
> print, copy, retransmit, disseminate, or otherwise use the information
> contained in this communication. Internet communications cannot be
> guaranteed to be timely, secure, error or virus-free. The sender does not
> accept liability for any errors or omissions.
>
> On Tue, Mar 7, 2017 at 3:38 PM, Sumedha Rubasinghe 
> wrote:
>
>> Hi Ching,
>> Could you list out the exact set of steps needed to get this to working
>> please?
>>
>>
>> On Tue, Mar 7, 2017 at 9:53 AM, Ching Shi  wrote:
>>
>>> Hi all,
>>>
>>> OMA Lightweight M2M protocol is from the Open Mobile Alliance for IoT
>>> device management. This protocol provides,
>>>
>>>1. Device management functionalities over sensor or cellular networks
>>>2. Transfer service data from the network to devices
>>>
>>> Lightweight M2M enabler defines the application layer communication
>>> protocol between a LWM2M server and a LWM2M client. The target LWM2M
>>> devices for this enabler are mainly resource constrained devices. Therefore
>>> this enabler makes use of a light and compact protocol as well as an
>>> efficient resource data model.
>>>
>>> Eclipse Leshan is an open source project which consists of a Lightweight
>>> M2M server. Leshan also consists of a LWM2M client which could run on any
>>> Linux Distribution. For example if the LWM2M client is running in a
>>> Raspberry Pi it could communicate with the LWM2M Server.
>>>
>>> The Eclipse Leshan Server is now integrated with the WSO2 IoT Server
>>> providing OMA Lightweight M2M. Initially the Eclipse Leshan Server wasn't
>>> handling any security. Authentication and authorisation is now handled in
>>> the Eclipse Leshan Server and Single Sign On (SSO) is configured with the
>>> WSO2 IoT Server.
>>>
>>>
>>> --
>>> Ching Tien Shi
>>> Intern - Engineering
>>> Mobile : +94770186272 <077%20018%206272>
>>>
>>>
>>>
>>> --
>>> Ching Tien Shi
>>> Intern - Engineering
>>> Mobile : +94770186272 <077%20018%206272>
>>>
>>>
>>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>


-- 
Ching Tien Shi
Intern - Engineering
Mobile : +94770186272
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] WSO2 IoT server supporting OMA Lightweight M2M protocol (OMA LWM2M)

[Kamidu Punchihewa]

Hi Inosh,

LWM2M Leshan server provides a restful interface where all the
characteristics/properties are represent by an integer. You can find a more
details including the features and the usability of Leshan server in there
home page's getting started section[1] .

Thanks and Best Regards,

Kamidu Sachith Punchihewa
*Software Engineer*
WSO2, Inc.
lean . enterprise . middleware
Mobile : +94 (0) 770566749 <%2B94%20%280%29%20773%20451194>

Please Note that I have dyslexia and it may results in few misspelled words
in the content.

Disclaimer: This communication may contain privileged or other confidential
information and is intended exclusively for the addressee/s. If you are not
the intended recipient/s, or believe that you may have received this
communication in error, please reply to the sender indicating that fact and
delete the copy you received and in addition, you should not print, copy,
retransmit, disseminate, or otherwise use the information contained in this
communication. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.

On Tue, Mar 7, 2017 at 3:38 PM, Sumedha Rubasinghe  wrote:

> Hi Ching,
> Could you list out the exact set of steps needed to get this to working
> please?
>
>
> On Tue, Mar 7, 2017 at 9:53 AM, Ching Shi  wrote:
>
>> Hi all,
>>
>> OMA Lightweight M2M protocol is from the Open Mobile Alliance for IoT
>> device management. This protocol provides,
>>
>>1. Device management functionalities over sensor or cellular networks
>>2. Transfer service data from the network to devices
>>
>> Lightweight M2M enabler defines the application layer communication
>> protocol between a LWM2M server and a LWM2M client. The target LWM2M
>> devices for this enabler are mainly resource constrained devices. Therefore
>> this enabler makes use of a light and compact protocol as well as an
>> efficient resource data model.
>>
>> Eclipse Leshan is an open source project which consists of a Lightweight
>> M2M server. Leshan also consists of a LWM2M client which could run on any
>> Linux Distribution. For example if the LWM2M client is running in a
>> Raspberry Pi it could communicate with the LWM2M Server.
>>
>> The Eclipse Leshan Server is now integrated with the WSO2 IoT Server
>> providing OMA Lightweight M2M. Initially the Eclipse Leshan Server wasn't
>> handling any security. Authentication and authorisation is now handled in
>> the Eclipse Leshan Server and Single Sign On (SSO) is configured with the
>> WSO2 IoT Server.
>>
>>
>> --
>> Ching Tien Shi
>> Intern - Engineering
>> Mobile : +94770186272 <077%20018%206272>
>>
>>
>>
>> --
>> Ching Tien Shi
>> Intern - Engineering
>> Mobile : +94770186272 <077%20018%206272>
>>
>>
>
>
>
>
> ___
> 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] WSO2 IoT server supporting OMA Lightweight M2M protocol (OMA LWM2M)

[Sumedha Rubasinghe]

Hi Ching,
Could you list out the exact set of steps needed to get this to working
please?


On Tue, Mar 7, 2017 at 9:53 AM, Ching Shi  wrote:

> Hi all,
>
> OMA Lightweight M2M protocol is from the Open Mobile Alliance for IoT
> device management. This protocol provides,
>
>1. Device management functionalities over sensor or cellular networks
>2. Transfer service data from the network to devices
>
> Lightweight M2M enabler defines the application layer communication
> protocol between a LWM2M server and a LWM2M client. The target LWM2M
> devices for this enabler are mainly resource constrained devices. Therefore
> this enabler makes use of a light and compact protocol as well as an
> efficient resource data model.
>
> Eclipse Leshan is an open source project which consists of a Lightweight
> M2M server. Leshan also consists of a LWM2M client which could run on any
> Linux Distribution. For example if the LWM2M client is running in a
> Raspberry Pi it could communicate with the LWM2M Server.
>
> The Eclipse Leshan Server is now integrated with the WSO2 IoT Server
> providing OMA Lightweight M2M. Initially the Eclipse Leshan Server wasn't
> handling any security. Authentication and authorisation is now handled in
> the Eclipse Leshan Server and Single Sign On (SSO) is configured with the
> WSO2 IoT Server.
>
>
> --
> Ching Tien Shi
> Intern - Engineering
> Mobile : +94770186272 <077%20018%206272>
>
>
>
> --
> Ching Tien Shi
> Intern - Engineering
> Mobile : +94770186272 <077%20018%206272>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] A Claim MUST have a Issuer

[Darshana Gunawardana]

On Tue, Mar 7, 2017 at 2:12 PM, Ishara Karunarathna 
wrote:

> Hi Johan,
>
>
>
> On Mon, Feb 27, 2017 at 10:51 AM, Johann Nallathamby 
> wrote:
>
>> In claims based identity management we MUST have a "Issuer" for each
>> claim. Each claim is made by an issuer, and you trust the claim only as
>> much as you trust the issuer.
>>
>> For example, you will trust a claim made by your organization's internal
>> IDP connected to the internal identity store, more than you trust a claim
>> made by the user himself.
>>
> Are we going to use this within the server. For example we can write a
> policy using issuer of the claims.
>

Yes, there are use cases like, it might allow only claims from perticular
issuers to be used as subject claim.

In simple words, for a subject claim it can only use claims that are
inherited values from the system; not a claim that is allowed change by the
user.

So, +1 for adding the issuer.

Thanks,

>
> And do we expect to send these information to connecting service providers.
> if so it may be a custom attribute that we need to send to customers such
> as authenticated IDP list.
>
> -Ishara
>
>
>>
>> Our current "Claim" object model contains following attributes [1].
>> 1. Dialect URI
>> 2. Claim URI
>> 3. Value
>>
>> Can we add "Issuer" attribute also to this model?
>>
>> [1] https://github.com/wso2/carbon-identity-mgt/blob/master/
>> components/org.wso2.carbon.identity.mgt/src/main/java/org/
>> wso2/carbon/identity/mgt/claim/Claim.java
>>
>> Regards,
>> Johann.
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Technical Lead & Product Lead of WSO2 Identity Server
>> Governance Technologies Team
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.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>
>
>
>


-- 
Regards,


*Darshana Gunawardana*Associate Technical Lead
WSO2 Inc.; http://wso2.com

*E-mail: darsh...@wso2.com *
*Mobile: +94718566859*Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] A Claim MUST have a Issuer

[Ishara Karunarathna]

Hi Johan,



On Mon, Feb 27, 2017 at 10:51 AM, Johann Nallathamby 
wrote:

> In claims based identity management we MUST have a "Issuer" for each
> claim. Each claim is made by an issuer, and you trust the claim only as
> much as you trust the issuer.
>
> For example, you will trust a claim made by your organization's internal
> IDP connected to the internal identity store, more than you trust a claim
> made by the user himself.
>
Are we going to use this within the server. For example we can write a
policy using issuer of the claims.

And do we expect to send these information to connecting service providers.
if so it may be a custom attribute that we need to send to customers such
as authenticated IDP list.

-Ishara


>
> Our current "Claim" object model contains following attributes [1].
> 1. Dialect URI
> 2. Claim URI
> 3. Value
>
> Can we add "Issuer" attribute also to this model?
>
> [1] https://github.com/wso2/carbon-identity-mgt/blob/master/
> components/org.wso2.carbon.identity.mgt/src/main/java/
> org/wso2/carbon/identity/mgt/claim/Claim.java
>
> Regards,
> Johann.
>
> --
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>



-- 
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS-6.0.0] SCIM list resources with multiple user stores

[Ishara Karunarathna]

On Tue, Mar 7, 2017 at 12:49 PM, Gayan Gunawardana  wrote:

>
>
> On Tue, Mar 7, 2017 at 9:43 AM, Ishara Karunarathna 
> wrote:
>
>> Hi,
>>
>> In SCIM domain is used to represent the whole administrative provisioning
>> system . So I don't think domain discuss in the spec directly map to the
>> domain concept we have.
>>
> We are not discussing here provisioning system (domain) concept in the
> spec. If name 'domain' is not suitable we can use better name to represent
> user store domains.
>
I think what I said was not clear to you. Since there is a domain concept
in the spec using domain name will confused people.
So better if we can use name for this.

>
>> In the spec when defining the tenants they have the option to use tenant
>> domain as a path parameter or sub domain.
>>
>> A URL prefix: "https://www.example.com/Tenants/{tenant_id}/v2/Users;.
>> A sub-domain: "https://{tenant_id}.example.com/v2/Groups;.
>>
>> I think better if we can follow the same patter to userDomains.
>>
> We can... but I do not see significant advantage of doing that.
>
>>
>> -Ishara
>>
>> On Sat, Mar 4, 2017 at 8:01 PM, Vindula Jayawardana <
>> vindula...@cse.mrt.ac.lk> wrote:
>>
>>> Hi,
>>>
>>> According to SCIM protocol specification[1], SCIM service providers may
>>> support additional query parameters apart from the standard set of query
>>> parameters in querying resources. Hence +1 for what Gayan has proposed here.
>>>
>>> I also agree with what Omindu has proposed. I think we could even add
>>> the domain as an extension attribute rather adding it to username if
>>> necessary. However, due to the fact that IS only supports one simple filter
>>> with "eq" as the filter operation, by doing this way, we are limiting the
>>> client's ability to query a resource using another filter. For an example
>>> what if the client wants to query all users with "userType+EQ+student" in a
>>> domain of "". Since one filter is already used, this kind of queries
>>> will not be fitted in. But in the Gayan's method this can be done with the
>>> following query request.
>>>
>>> /scim/v2/Users?filter=userType+EQ+student=
>>>
>>>
>>> [1] - https://tools.ietf.org/html/rfc7644#section-3.4.2
>>>
>>> *Vindula Jayawardana*
>>> Computer Science and Engineering Dept.
>>> University of Moratuwa
>>> mobile : +713462554
>>> Email : vindul...@gmail.com
>>>
>>> 
>>> 
>>> 
>>> 
>>>
>>> *“Respect is how to treat everyone, not just those you want to impress.
>>> "*
>>>
>>>
>>> *-Richard Branson-*
>>>
>>>
>>>
>>> On 3 March 2017 at 18:41, Omindu Rathnaweera  wrote:
>>>
 Hi Gayan,

 Does the protocol permits introducing custom parameters as domain? If
 so  +1 for using a param. Else, we can include the domain name as a part of
 the username (IINM we support this in C4 as well), so searching only in a
 particular domain will look like below.

 /scim/v2/Users?filter=userName+EQ+FOODOMAIN/*

 Also, should we look into searching within multiple domains ? Currently
 we can only search either in a single domain or in all domains. However,
 the identity store does not have this support yet.

 Regards,
 Omindu.

 On Thu, Mar 2, 2017 at 11:41 PM, Gayan Gunawardana 
 wrote:

> Hi All,
>
> How are we going to support SCIM list all users and list all groups
> operations when we have multiple user store domains. In C4 we could 
> iterate
> through all user stores and fetch results but in C5 we highly discourage
> such a functionality due to performance impact.
>
> Basically client need to provide user store domain, when it requires
> data from secondary user store domains.
>
> My suggestion is to support custom parameter like "domain" so requests
> will be like below.
>
> /scim/v2/Users?domain=
>
> /scim/v2/Users?startIndex=1=2=
>
>
> /scim/v2/Users?filter=userName+EQ+vindula=
>
>
> @Ishara, Johann, Ayoma appreciate your input.
>
>
> Thanks,
>
> Gayan
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Omindu Rathnaweera
 Software Engineer, WSO2 Inc.
 Mobile: +94 771 197 211 <+94%2077%20119%207211>

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


>>>

[Architecture] WSO2 API Manager 2.1.0 - Puppet Modules Released !

[Samitha Chathuranga]

The WSO2 API Manager team is pleased to announce the release of *Puppet
Modules for WSO2 API Manager 2.1.**0.*

*Puppet Modules *

The release contains the following 3 puppet modules.

   - WSO2 API Manager 2.1.0 Puppet Module - wso2am_runtime
   - WSO2 API Manager Analytics Server 2.1.0 Puppet Module -
   wso2am_analytics
   - Pre-packaged WSO2 Identity Server 5.3.0 Puppet Module -
   wso2is_prepacked

These puppet modules facilitate the configuration and installation of 7
basic deployment patterns of WSO2 APIM 2.1.0.

*Patterns Supported*

Following are the WSO2 API Manager 2.1.0 deployment patterns included.

   1. Pattern 1 - Single node deployment without distribution.
   2. Pattern 2 - Single node deployment without distribution with
   analytics.
   3. Pattern 3 - Fully distributed with Gateway worker/manager separation.
   4. Pattern 4 - Fully distributed with Gateway in a demilitarized zone
   with worker/manager separation.
   5. Pattern 5 - Distributed with Gateway worker/manager separation.
   Gateway worker and Key Manager in the same node.
   6. Pattern 6 - Distributed with Gateway worker/manager separation. Store
   in the same node as the Publisher.
   7. Pattern 7 - Single node deployment without distribution and with
   prepackaged WSO2 Identity Server as Key Manager.

   ( Pattern 0 is also provided and it is a Single node deployment
without distribution and it is configured to use with embedded H2 databases
)

For more on the above patterns, refer
https://docs.wso2.com/display/AM210/Deployment+Patterns

The other two puppet modules, wso2am_analytics and wso2is_prepacked provide
single pattern in each, which are required for the setup of aforementioned
WSO2 API Manager deployment patterns.

*Release artifacts*

https://github.com/wso2/puppet-apim/releases/tag/v2.1.0

*Documentation*

https://github.com/wso2/puppet-apim/wiki


Thank you

-- The WSO2 API Manager Team --


-- 
Samitha Chathuranga
Software Engineer, WSO2 Inc.
lean.enterprise.middleware
Mobile: +94715123761

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