[Architecture] WSO2 Identity Server 5.5.0-Alpha3 Released!

[Sathya Bandara]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.5.0 Alpha3!
Download

You can download WSO2 Identity Server 5.5.0 Alpha3 distributions from
following locations.


Identity Server: https://github.com/wso2/product-is/releases/download/
v5.5.0-alpha3//wso2is-5.5.0-alpha3


IS Analytics: https://github.com/wso2/analytics-is/releases/tag/v5.
5.0-alpha3/wso2is-analytics-5.5.0-alpha3

How to run

1. Extract the downloaded zip file.

2. Go to the bin directory in the extracted folder.

3. Run the wso2server.sh file if you are on a Linux/Mac OS or run the
wso2server.bat file if you are on a Windows OS.



What's new in WSO2 Identity Server 5.5.0 Alpha3

Following includes major features/improvements provided in WSO2 IS
5.5.0-Alpha3.


   -

   Tenancy support for PII controllers - Capability to configure PII
   controllers per tenant basis.
   -

   Consent Management in OIDC - Integrating User Consent Management into
   OpenID connect Authorization Code and Implicit flow.


A list of new features and bug fixes shipped with this release can be found
here 

Online documentation is available at https://docs.wso2.com/display/
IS550/WSO2+Identity+Server+Documentation.


Known Issues

All the open issues pertaining to WSO2 Identity Server are reported at the
following location:

   -

   IS Runtime 
   -

   IS Analytics 



How You Can Contribute

Mailing Lists

Join our mailing list and correspond with the developers directly.

Developer list: d...@wso2.org | Subscribe | Mail Archive


User forum: StackOverflow


Reporting Issues

We encourage you to report issues, improvements, documentation faults, and
feature requests regarding WSO2 Identity Server through WSO2 Identity
Server GIT Issues .

For more information about WSO2 Identity Server, please see
https://wso2.com/identity-and-access-management or visit the WSO2 Oxygen
Tank  developer portal for additional resources.


~ The WSO2 Identity and Access Management Team ~


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release WSO2 IoT Server 3.2.0 RC2

[Milan Perera]

Hi all,

I have tested the data archival feature in MySQL 5.5, 5.6, and 5.7 and it
does not work as expected.

[-] Broken - Do not release

Regards,


On Tue, Feb 27, 2018 at 4:01 PM, Shavindri Dissanayake 
wrote:

> Hi All,
>
> Tested the following scenarios,
>
>1. Enrolled an iOS device on the server.
>2. Tested operations such as device lock.
>3. Enforced policies and revoked.
>4. Unenrolled the device.
>5. Enrolled an Android device.
>6. Tested the ring and device lock operations.
>7. Applied a policy and unpublished the policy from the device.
>8. Enrolled the virtual fire alarm and tried it out.
>9. Created an execution plan to run at a particular time, and enabled
>and disabled the camera on an Android device.
>
> [+] Stable - Go ahead and release
>
>
> Thanks & Regards
> Shavindri Dissanayake
> Senior Technical Writer
>
> WSO2 Inc.
> lean.enterprise.middleware
>
> On Tue, Feb 27, 2018 at 3:53 PM, Inosh Perera  wrote:
>
>> Hi All,
>>
>> Tested the following scenarios,
>>
>>1. Enrolled an iOS device on the server.
>>2. Tested operations such as device lock.
>>3. Enforced policies and revoked.
>>4. Unenrolled the device.
>>
>> [+] Stable - Go ahead and release
>>
>>
>> Regards,
>> Inosh
>>
>> On Tue, Feb 27, 2018 at 1:47 PM, Kamidu Punchihewa 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have tested following functionalities on a single node deplyment:
>>>
>>>- Enrolled an android device and perform operations in BYOD mode.
>>>- Enrolled an iOS device and perform operations.
>>>- Check the notifications and notification removal and mark as read
>>>functionalities.
>>>- Create and publish iOS and Android restriction policies.
>>>
>>> [+1] Stable - Go ahead and release
>>>
>>> Thanks and Best Regards,
>>>
>>>
>>>
>>> On Tue, Feb 27, 2018 at 1:24 PM, Madhawa Perera 
>>> wrote:
>>>
 Hi all,

 I have tested following functionalities:

 1. Android device enrolment and dis-enrollment
 2. Android device operation and policy as admin user:
 - Device Lock
 - Change Lock Code
 - Ring
 - Location
 - Camera restriction policy
 3. iOS device enrollment and dis-enrollment
 4. iOS device operation and policy as admin user:
 - Ring
 - Notification
 - Camera restriction policy

 Found no issues.

 +1 Stable - go ahead and release.

 Thank you
 Best Regards,
 Madhawa

 On Tue, Feb 27, 2018 at 6:37 AM, Charitha Goonetilleke <
 charit...@wso2.com> wrote:

> Hi All,
>
> Successfully tested the following :
>
>1. Add API based device type with MQTT transport.
>2. Enroll and communicate with the agent.
>3. Renewed token using refresh token grant type.
>4. Send operation to agent and receive operation response.
>5. Publish operation response to analytics
>
> [+] Stable - Go ahead and release
>
> Thanks & regards,
> /charithag
>
> On Tue, Feb 27, 2018 at 10:18 AM, Nuwan Jayawardene 
> wrote:
>
>> Successfully tested the following :
>>
>>
>>1. Android BYOD Device enrollment
>>2. Invoked following operations: Ring, Device Lock, Location,
>>Mute, Change Lock code, Enterprise wipe, Wipe data
>>3. Passcode policy for BYOD
>>4. Restriction policy for BYOD
>>
>> I am +1 for this release
>>
>>
>> Thanks and regards
>>
>>
>> On Tue, Feb 27, 2018 at 7:08 AM, Ruwan Yatawara 
>> wrote:
>>
>>> Successfully tested the following :
>>>
>>> 1. Android Device Enrollment
>>> 2  Invoking Ring, Message, Location Operation
>>> 3. Configuring Geo Alerts
>>> 3. Adding Stationary, Exit and Entry Alerts
>>> 4. Adding a new Device Type
>>>
>>> I am +1 to release.
>>>
>>>
>>> Thanks and Regards,
>>>
>>> Ruwan Yatawara
>>>
>>> Technical Lead,
>>> WSO2 Inc.
>>>
>>> email : ruw...@wso2.com
>>> mobile : +94 77 9110413
>>> http://ruwansrants.blogspot.com/
>>> https://500px.com/ruwan_ace
>>> https://medium.com/@ruwanyatawara
>>>
>>>
>>> On Mon, Feb 26, 2018 at 2:17 AM, Rasika Perera 
>>> wrote:
>>>
 Hi Devs,

 We are pleased to announce the release candidate of WSO2 IoT Server
  3.2.0.

 This is the second release candidate (RC) of the WSO2 IoT Server 3.2.0
 release.

 This release carries 275+ issue fixes [1-12] over the last GA (3.1.0)
 release.

 Reported Issues:

- https://github.com/wso2/product-iots/issues

 Source and distribution packages:

- 

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

[Randilu Soysa]

*Hi everyone,I have completed the process of introducing new commands to
the import-export CLI tool successfully.  Find the finalized set of
commands below with the sample responses, thank you for all the insights
and suggestions you’ve provided! Exports an Application from a desired
environmentCommandsexport-app Flags Required -n, --name string Name of the
Application to be exported -o, --owner string Owner of the Application to
be exported -e, --environment string Environment to which the Application
should be exported Optional -u, --username string Username -p, --password
string Password -h, --help Help for export-app -k, --insecure Allow
connections to SSL endpoints without certs --verbose Enable verbose mode
apimcli export-app (--name  --owner
 --environment
) [flags] Examples:
apimcli export-app -n SampleApp -o admin -e dev apimcli export-app -n
SampleApp -o admin -e prod Sample Response: Succesfully exported
Application! Find the exported Application at
/home/user/.wso2apimcli/exported/apps/dev/admin_sampleApp.zip
Imports
an Application to a desired environmentCommandsimport-app Flags Required
-f, --file string Name of the Application to be imported -e, --environment
string Environment from the which the Application should be imported
(default "default") Optional -s, --skipSubscriptions Skips subscriptions of
the Application -o, --owner string Name of the target Owner of the
Application as desired by the Importer -r, --preserveOwner Preserves app
owner from the original Environment -u, --username string Username -p,
--password string Password -h, --help Help for import-app -k, --insecure
Allow connections to SSL endpoints without certs --verbose Enable verbose
mode apimcli import-app (--file  --environment
) [flags] Examples:
apimcli import-app -f qa/sampleApp.zip -e dev apimcli Import App -f
staging/sampleApp.zip -e prod -o testUser -u admin -p admin apimcli
import-app -f qa/sampleApp.zip --preserveOwner --skipSubscriptions -e
staging Sample Response: ZipFilePath:
/home/user/.wso2apimcli/exported/apps/staging/admin_sampleApp.zip
Succesfully imported Application!
Display
a list of Applications in an environment specific to an ownerCommandslist
apps Flags Required -e, --environment Environment to be searched -o,
--owner string Owner of the Application Optional -u, --username Username
-p, --password Password -h, --help Help for list apps Examples: apimcli
list apps -e dev -o admin apimcli list apps -e staging -o sampleUser -u
admin -p 123456 Sample Response: Environment: dev No. of Applications: 3
+--+---+---+--+--+
| ID | NAME | OWNER | STATUS | GROUP-ID |
+--+---+---+--+--+
| 0e09806c-65bb-4114-b483-3f7521e51a70 | adminApp1 | admin | APPROVED | | |
d2b2a966-97e6-40da-9f73-7202d6c2bf9b | sampleApp | admin | APPROVED | | |
2817069d-ce62-410c-9f10-9f3910912bee | sharedApp | admin | APPROVED |
testGrp |
+--+---+---+--+--+
*


On Thu, Jan 25, 2018 at 5:41 PM, Randilu Soysa  wrote:

> Hi everyone,
>
> I’m working on a project to introduce commands to provide application
> import export support for the import-export-cli for APIM 2.x. I am planning
> to introduce commands in order to list available applications of a specific
> user, export an application from a desired environment and import an
> application to a desired environment.
>
>
> The commands are as follows,
>
>
> Exports an Application from a desired environment
>
> Commands
>
> export-app
>
> Flags
>   Required
> -n, --name string  Name of the Application to be exported
> -i, --uuid string  UUID of the Application to be exported
> -e, --environment string   Environment from which the Application 
> should be exported
>   Optional
> -p, --password string  Password
> -u, --username string  Username
>
> -k, --insecure Allow connections to SSL endpoints without 
> certs
> --verbose  Enable verbose mode
>
> apimcli export-app (--name  --uuid 
>  --environment 
> ) [flags]
>
> Examples:
>
> apimcli export-app -n SampleApp 9f6affe2-4c97-4817-bded-717f8b01eee8 
> -e dev
> apimcli export-app -n SampleApp 7bc2b94e-c6d2-4d4f-beb1-cdccb08cd87f 
> -e prod
>
>
>
> Imports
> an Application to a desired environment
>
> Commands
>
> import-app
>
> Flags
> Required
>   -f, --file string  Name of the Application to be imported
>   -e, --environment 

Re: [Architecture] [BMB] Full In-memory operating mode for message broker

[Shazni Nazeer]

yeah that makes sense. No memory system is reliable ☺. But certainly good
to have for some scenarios like the throttling events mentioned above.

On Tue, Feb 27, 2018 at 11:24 PM, Asanka Abeyweera 
wrote:

> HA is not supported in in-memory mode. This is a non-reliable broker mode
> (unless your memory/system is reliable ;)). If you need to have HA for your
> use case you should not use in-memory mode.
>
> On Wed, Feb 28, 2018 at 10:19 AM, Shazni Nazeer  wrote:
>
>> Hi Asanka,
>>
>> How would the in-memory storage be handled between high availability
>> scenario where we have two MB nodes used? Do we have any distributed
>> caching of some sort?
>>
>> On Tue, Feb 27, 2018 at 12:30 AM, Asanka Abeyweera 
>> wrote:
>>
>>> We are planning to complete the feature in this week's milestone.
>>> Configuration wise, you will have to set the in-memory mode to "true" in
>>> the config. We will explain this in the doc.
>>>
>>> On a separate note, When you use non durable queues (for example with
>>> non durable topic subscribers) with BMB it will operate in memory (without
>>> persisting to database) irrespective of the configured mode.
>>>
>>>
>>> On Tue, Feb 27, 2018 at 11:40 AM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 +1 This will be perfect implementation for throttling events like
 messages( due to high efficiency, small message size, no durable
 requirements etc).
 Do you have any time line estimation for this feature? I believe from
 user point of view there will be no any changes other than remove database
 configuration.

 Thanks,
 sanjeewa.

 On Fri, Feb 23, 2018 at 4:31 PM, Hasitha Hiranya 
 wrote:

> Hi Asanka,
>
> I think we should not restrict.
> What we are doing is, configuring MB to work with an "in-memory
> store".
> It should be a configuration at broker side (applied to all
> queues/topics).
> When coding, better keep all logics same attached to an in-memory impl
> of the  store.
>
> Thoughts?
>
> Thanks
>
> On Fri, Feb 23, 2018 at 3:32 PM, Pamod Sylvester 
> wrote:
>
>> Hi Asanka,
>>
>> If we're considering to handle durable subscriptions in-memory it
>> would be good if we can inform the client on it.
>>
>> IMHO Semantically it also could mislead the applications. Otherwise
>> isn't it an option for us to restrict connection creation as durable ? 
>> (if
>> the broker is started in, "in-memory" mode)
>>
>> Thanks,
>> Pamod
>>
>> On Fri, Feb 23, 2018 at 2:14 PM, Asanka Abeyweera 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am working on the $subject. In the previous versions of message
>>> broker, we configured H2 database in the in-memory mode to run the 
>>> broker
>>> in in-memory mode. But we are thinking of having a mode where we would 
>>> skip
>>> the database layer completely when in-memory mode is enabled in the 
>>> broker.
>>> This means we will be doing all of the following tasks in memory.
>>>
>>>- Persistent message storing
>>>- Durable queue information storing
>>>- Durable exchange information storing
>>>- Durable binding information storing
>>>
>>> Alternatively, we could reject all durable calls when we put the
>>> broker in in-memory mode. But If we do that we will be limiting some of 
>>> the
>>> existing applications from using the message broker in in-memory mode.
>>> Therefore I think It is better not to that.
>>>
>>> WDYT?
>>> --
>>> Asanka Abeyweera
>>> Associate Technical Lead
>>> WSO2 Inc.
>>>
>>> Phone: +94 712228648 <071%20222%208648>
>>> Blog: a5anka.github.io
>>>
>>> 
>>>
>>
>>
>>
>> --
>> *Pamod Sylvester *
>>
>> *WSO2 Inc.; http://wso2.com *
>> cell: +94 77 7779495 <077%20777%209495>
>>
>
>
>
> --
> *Hasitha Abeykoon*
> Associate Technical Lead; WSO2, Inc.; http://wso2.com
> *cell:* *+94 719363063*
> *blog: **abeykoon.blogspot.com* 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --

 *Sanjeewa Malalgoda*
 WSO2 Inc.
 Mobile : +94713068779 <+94%2071%20306%208779>

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



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

Re: [Architecture] [BMB] Full In-memory operating mode for message broker

[Asanka Abeyweera]

HA is not supported in in-memory mode. This is a non-reliable broker mode
(unless your memory/system is reliable ;)). If you need to have HA for your
use case you should not use in-memory mode.

On Wed, Feb 28, 2018 at 10:19 AM, Shazni Nazeer  wrote:

> Hi Asanka,
>
> How would the in-memory storage be handled between high availability
> scenario where we have two MB nodes used? Do we have any distributed
> caching of some sort?
>
> On Tue, Feb 27, 2018 at 12:30 AM, Asanka Abeyweera 
> wrote:
>
>> We are planning to complete the feature in this week's milestone.
>> Configuration wise, you will have to set the in-memory mode to "true" in
>> the config. We will explain this in the doc.
>>
>> On a separate note, When you use non durable queues (for example with non
>> durable topic subscribers) with BMB it will operate in memory (without
>> persisting to database) irrespective of the configured mode.
>>
>>
>> On Tue, Feb 27, 2018 at 11:40 AM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> +1 This will be perfect implementation for throttling events like
>>> messages( due to high efficiency, small message size, no durable
>>> requirements etc).
>>> Do you have any time line estimation for this feature? I believe from
>>> user point of view there will be no any changes other than remove database
>>> configuration.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Fri, Feb 23, 2018 at 4:31 PM, Hasitha Hiranya 
>>> wrote:
>>>
 Hi Asanka,

 I think we should not restrict.
 What we are doing is, configuring MB to work with an "in-memory store".
 It should be a configuration at broker side (applied to all
 queues/topics).
 When coding, better keep all logics same attached to an in-memory impl
 of the  store.

 Thoughts?

 Thanks

 On Fri, Feb 23, 2018 at 3:32 PM, Pamod Sylvester 
 wrote:

> Hi Asanka,
>
> If we're considering to handle durable subscriptions in-memory it
> would be good if we can inform the client on it.
>
> IMHO Semantically it also could mislead the applications. Otherwise
> isn't it an option for us to restrict connection creation as durable ? (if
> the broker is started in, "in-memory" mode)
>
> Thanks,
> Pamod
>
> On Fri, Feb 23, 2018 at 2:14 PM, Asanka Abeyweera 
> wrote:
>
>> Hi all,
>>
>> I am working on the $subject. In the previous versions of message
>> broker, we configured H2 database in the in-memory mode to run the broker
>> in in-memory mode. But we are thinking of having a mode where we would 
>> skip
>> the database layer completely when in-memory mode is enabled in the 
>> broker.
>> This means we will be doing all of the following tasks in memory.
>>
>>- Persistent message storing
>>- Durable queue information storing
>>- Durable exchange information storing
>>- Durable binding information storing
>>
>> Alternatively, we could reject all durable calls when we put the
>> broker in in-memory mode. But If we do that we will be limiting some of 
>> the
>> existing applications from using the message broker in in-memory mode.
>> Therefore I think It is better not to that.
>>
>> WDYT?
>> --
>> Asanka Abeyweera
>> Associate Technical Lead
>> WSO2 Inc.
>>
>> Phone: +94 712228648 <071%20222%208648>
>> Blog: a5anka.github.io
>>
>> 
>>
>
>
>
> --
> *Pamod Sylvester *
>
> *WSO2 Inc.; http://wso2.com *
> cell: +94 77 7779495 <077%20777%209495>
>



 --
 *Hasitha Abeykoon*
 Associate Technical Lead; WSO2, Inc.; http://wso2.com
 *cell:* *+94 719363063*
 *blog: **abeykoon.blogspot.com* 


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


>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779 <+94%2071%20306%208779>
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Asanka Abeyweera
>> Associate Technical Lead
>> WSO2 Inc.
>>
>> Phone: +94 712228648 <+94%2071%20222%208648>
>> Blog: a5anka.github.io
>>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Shazni Nazeer
>
> Mob : 

Re: [Architecture] [BMB] Full In-memory operating mode for message broker

[Shazni Nazeer]

Hi Asanka,

How would the in-memory storage be handled between high availability
scenario where we have two MB nodes used? Do we have any distributed
caching of some sort?

On Tue, Feb 27, 2018 at 12:30 AM, Asanka Abeyweera 
wrote:

> We are planning to complete the feature in this week's milestone.
> Configuration wise, you will have to set the in-memory mode to "true" in
> the config. We will explain this in the doc.
>
> On a separate note, When you use non durable queues (for example with non
> durable topic subscribers) with BMB it will operate in memory (without
> persisting to database) irrespective of the configured mode.
>
>
> On Tue, Feb 27, 2018 at 11:40 AM, Sanjeewa Malalgoda 
> wrote:
>
>> +1 This will be perfect implementation for throttling events like
>> messages( due to high efficiency, small message size, no durable
>> requirements etc).
>> Do you have any time line estimation for this feature? I believe from
>> user point of view there will be no any changes other than remove database
>> configuration.
>>
>> Thanks,
>> sanjeewa.
>>
>> On Fri, Feb 23, 2018 at 4:31 PM, Hasitha Hiranya 
>> wrote:
>>
>>> Hi Asanka,
>>>
>>> I think we should not restrict.
>>> What we are doing is, configuring MB to work with an "in-memory store".
>>> It should be a configuration at broker side (applied to all
>>> queues/topics).
>>> When coding, better keep all logics same attached to an in-memory impl
>>> of the  store.
>>>
>>> Thoughts?
>>>
>>> Thanks
>>>
>>> On Fri, Feb 23, 2018 at 3:32 PM, Pamod Sylvester  wrote:
>>>
 Hi Asanka,

 If we're considering to handle durable subscriptions in-memory it would
 be good if we can inform the client on it.

 IMHO Semantically it also could mislead the applications. Otherwise
 isn't it an option for us to restrict connection creation as durable ? (if
 the broker is started in, "in-memory" mode)

 Thanks,
 Pamod

 On Fri, Feb 23, 2018 at 2:14 PM, Asanka Abeyweera 
 wrote:

> Hi all,
>
> I am working on the $subject. In the previous versions of message
> broker, we configured H2 database in the in-memory mode to run the broker
> in in-memory mode. But we are thinking of having a mode where we would 
> skip
> the database layer completely when in-memory mode is enabled in the 
> broker.
> This means we will be doing all of the following tasks in memory.
>
>- Persistent message storing
>- Durable queue information storing
>- Durable exchange information storing
>- Durable binding information storing
>
> Alternatively, we could reject all durable calls when we put the
> broker in in-memory mode. But If we do that we will be limiting some of 
> the
> existing applications from using the message broker in in-memory mode.
> Therefore I think It is better not to that.
>
> WDYT?
> --
> Asanka Abeyweera
> Associate Technical Lead
> WSO2 Inc.
>
> Phone: +94 712228648 <071%20222%208648>
> Blog: a5anka.github.io
>
> 
>



 --
 *Pamod Sylvester *

 *WSO2 Inc.; http://wso2.com *
 cell: +94 77 7779495 <077%20777%209495>

>>>
>>>
>>>
>>> --
>>> *Hasitha Abeykoon*
>>> Associate Technical Lead; WSO2, Inc.; http://wso2.com
>>> *cell:* *+94 719363063*
>>> *blog: **abeykoon.blogspot.com* 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <+94%2071%20306%208779>
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Asanka Abeyweera
> Associate Technical Lead
> WSO2 Inc.
>
> Phone: +94 712228648 <+94%2071%20222%208648>
> Blog: a5anka.github.io
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Shazni Nazeer

Mob : +94 37331
LinkedIn : http://lk.linkedin.com/in/shazninazeer

Blogs :

https://medium.com/@mshazninazeer
http://shazninazeer.blogspot.com


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

Re: [Architecture] [IAM] eIDAS profile support for SAML

[Johann Nallathamby]

Hi Indunil,

On Tue, Feb 27, 2018 at 3:56 PM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
>
> eIDAS (electronic IDentification, Authentication and trust Services) is an
> EU regulation on electronic identification and trust services for
> electronic transactions in the internal market. The eIDAS interoperability
> framework including its national entities (eIDAS-Connector and
> eIDAS-Service) need to exchange messages including personal and technical
> attributes to support cross-border identification and authentication
> processes (Please refer [1] for more information). For the exchange of
> messages, the use of the SAML 2.0 specifications has been agreed and there
> are eIDAS compliant set of technical specifications in [2], which Member
> States of EU to use to develop their own eIDAS-compliant implementation.
>
>
> As per the "eIDAS SAML Message Format" specification, handling and
> inclusion of attributes into exchanged messages is defined as follows.
>
>- Attributes MUST be requested as  and 
> *
>MUST be included in the  element of the SAML
>AuthnRequest.*
>
> Ex:
>
>  xmlns:ds="http://www.w3.org/2000/09/xmldsig#;
> *xmlns:eidas="http://eidas.europa.eu/saml-extensions 
> "* ...>
>  
>  **
>*public*
>   **
> 
> Name="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
> isRequired="false" />
> 
> Name="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
> isRequired="true" />
>
>  
>  .
> 
>
>
>- Apart from the attributes, for indicating whether an authentication
>request is made by a private sector or public sector SP, the defined
>element * MUST be present* either in the 
>element of SAML metadata or in the  element of a
>.
>
>
> As per the SAML Core specification in [3], SAML Extensions is an optional
> element in SAML 2.0, allowing arbitrary information to be passed to the
> identity provider which are agreed on between the communicating parties. As
> mentioned above, eIDAS attributes should be included within SAML extension
> element.
>
>
> Currently in IS, *SAML Extensions processing *has not taken into the
> consideration. So that, in order to have eIDAS profile support for SAML,
> that should be considered. Please find the following proposed
> implementation.
>
>1. *Register a set of SAML Extension Processors* - extensible
>mechanism where we can include any extension processing
>2. *eIDAS Extension Processor *- specifically handled the eIDAS
>extension
>3. *Invoke the processors when building the SAML assertion*
>   - Consider that all the necessary attributes are configured as the
>   SP requested claims
>- In the eIDAS processor, filtering out the requested attributes based
>   on the "RequestedAttributes" elements in the authentication request
>
>
+1 for the approach. But make sure we don't have to configure FQCN in files
and make only one processor work at a given time. Processors should be
picked dynamically based on the request. I think like the other processors
we have, you can extend from AbtractIdentityHandler and do this via the
HandlerManager we have in identity.core.

One of the concerns I have is about "RequestedAttributes". We are assuming
that the required attributes are configured for the service providers. This
coordination is not possible between countries, unless they all agree on a
standard set of attributes always, and there are too many service providers
to do this. I think we need to fix this and have a way to dynamically
request attributes without depending on the service provider configuration.
OIDC also suffers from this same limitation. I think we need to fix this
problem with this effort.

Regards,
Johann.

>
>-
>
>
> Really appreciate your suggestions and comments.
>
>
> [1] https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/How+
> does+it+work+-+eIDAS+solution
> [2] https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/
> 2016/12/16/eIDAS+Technical+Specifications+v.+1.1
> [3] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
>
> Thanks and Regards
>
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Emailindu...@wso2.com
> Mobile   0772182255
>



-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
*
Medium: *https://medium.com/@johann_nallathamby
*
Twitter: *@dj_nallaa*
___
Architecture mailing list
Architecture@wso2.org

Re: [Architecture] Configure token expiry time based on the Service provider (APIM application)

[Lahiru Sandaruwan]

Thanks Harsha. It seems it is available form IS 5.4.0.


On Tue, Feb 27, 2018 at 11:58 AM, Harsha Thirimanna 
wrote:

>
>
> On Tue, Feb 27, 2018 at 11:07 PM, Lahiru Sandaruwan 
> wrote:
>
>> Hi Harsha,
>>
>> Did we add application level validity period requirement to Roadmap? Do
>> we plan to implement this in near future?
>>
>
> Per service provider wise expire time set to the bellow tokens are already
> there in the product.
>
> User Access Token
> Application Access Token
> Refresh Token
>
> https://docs.wso2.com/display/IS540/Configuring+Inbound+
> Authentication+for+a+Service+Provider
> ​
>
>>
>> Thanks.
>>
>> On Tue, Apr 25, 2017 at 12:48 AM, Sanjeewa Malalgoda 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 8:46 AM, Harsha Thirimanna 
>>> wrote:
>>>


 On 21 Apr 2017 3:35 p.m., "Asela Pathberiya"  wrote:

 Hi IS/APIM team,

 Is $subject in our roadmap ?

 We will add this to the roadmap.

 This seems to be a required features.  Different applications may need
 the different user token expiry time based on their security level.




 Yes, it seems the application should have this capability to do.
 But what is the real use case to have this per user ?

>>> It depends lets think user know he is going to use this for shorter
>>> period(from mobile app) then he can request with smaller time (lets say 5
>>> mins). Then from token issuer logic we can check application level max
>>> value and issue token with requested validity period if requested time is
>>> below what they allow in application level. So this is not really user
>>> level thing but optional parameter we send on demand when we generate
>>> tokens. If token generation request allows to send optional parameters like
>>> DCR we will be able to send requested_validity(if not sent default
>>> application level validity time will apply).
>>>
>>> Thanks,
>>> sanjeewa.
>>>

 Just heard that; IOT server may has already requirement with that;  It
 is needed to define a token expiry level based on their device type.  Say;
  some device's token may be embedded & these token may have longer expiry
 time (never expired).  Also;  some devices type need a  less expiry time
 based on their security policies.   It is not sure how we are handled this
 with APIM feature without $subject.   But;  this can be easily handled, if
 we can have such feature inbuilt.

 Thanks,
 Asela


 --
 Thanks & Regards,
 Asela

 ATL
 Mobile : +94 777 625 933 <+94%2077%20762%205933>
  +358 449 228 979

 http://soasecurity.org/
 http://xacmlinfo.org/

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



>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779 <071%20306%208779>
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> --
>>
>> Lahiru Sandaruwan
>> WSO2 Inc., http://wso2.com
>>
>> lean.enterprise.middleware
>>
>> m: +1 901 530 2379 <(901)%20530-2379>
>> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
>> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>


-- 
--

Lahiru Sandaruwan
WSO2 Inc., http://wso2.com

lean.enterprise.middleware

m: +1 901 530 2379
e: lahi...@wso2.com b: https://medium.com/@lahirugmg
in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Configure token expiry time based on the Service provider (APIM application)

[Harsha Thirimanna]

On Tue, Feb 27, 2018 at 11:07 PM, Lahiru Sandaruwan 
wrote:

> Hi Harsha,
>
> Did we add application level validity period requirement to Roadmap? Do we
> plan to implement this in near future?
>

Per service provider wise expire time set to the bellow tokens are already
there in the product.

User Access Token
Application Access Token
Refresh Token

https://docs.wso2.com/display/IS540/Configuring+Inbound+Authentication+for+a+Service+Provider
​

>
> Thanks.
>
> On Tue, Apr 25, 2017 at 12:48 AM, Sanjeewa Malalgoda 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 8:46 AM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>>
>>> On 21 Apr 2017 3:35 p.m., "Asela Pathberiya"  wrote:
>>>
>>> Hi IS/APIM team,
>>>
>>> Is $subject in our roadmap ?
>>>
>>> We will add this to the roadmap.
>>>
>>> This seems to be a required features.  Different applications may need
>>> the different user token expiry time based on their security level.
>>>
>>>
>>>
>>>
>>> Yes, it seems the application should have this capability to do.
>>> But what is the real use case to have this per user ?
>>>
>> It depends lets think user know he is going to use this for shorter
>> period(from mobile app) then he can request with smaller time (lets say 5
>> mins). Then from token issuer logic we can check application level max
>> value and issue token with requested validity period if requested time is
>> below what they allow in application level. So this is not really user
>> level thing but optional parameter we send on demand when we generate
>> tokens. If token generation request allows to send optional parameters like
>> DCR we will be able to send requested_validity(if not sent default
>> application level validity time will apply).
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>> Just heard that; IOT server may has already requirement with that;  It
>>> is needed to define a token expiry level based on their device type.  Say;
>>>  some device's token may be embedded & these token may have longer expiry
>>> time (never expired).  Also;  some devices type need a  less expiry time
>>> based on their security policies.   It is not sure how we are handled this
>>> with APIM feature without $subject.   But;  this can be easily handled, if
>>> we can have such feature inbuilt.
>>>
>>> Thanks,
>>> Asela
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>>  +358 449 228 979
>>>
>>> http://soasecurity.org/
>>> http://xacmlinfo.org/
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <071%20306%208779>
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> --
>
> Lahiru Sandaruwan
> WSO2 Inc., http://wso2.com
>
> lean.enterprise.middleware
>
> m: +1 901 530 2379 <(901)%20530-2379>
> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Configure token expiry time based on the Service provider (APIM application)

[Lahiru Sandaruwan]

Hi Harsha,

Did we add application level validity period requirement to Roadmap? Do we
plan to implement this in near future?

Thanks.

On Tue, Apr 25, 2017 at 12:48 AM, Sanjeewa Malalgoda 
wrote:

>
>
> On Tue, Apr 25, 2017 at 8:46 AM, Harsha Thirimanna 
> wrote:
>
>>
>>
>> On 21 Apr 2017 3:35 p.m., "Asela Pathberiya"  wrote:
>>
>> Hi IS/APIM team,
>>
>> Is $subject in our roadmap ?
>>
>> We will add this to the roadmap.
>>
>> This seems to be a required features.  Different applications may need
>> the different user token expiry time based on their security level.
>>
>>
>>
>>
>> Yes, it seems the application should have this capability to do.
>> But what is the real use case to have this per user ?
>>
> It depends lets think user know he is going to use this for shorter
> period(from mobile app) then he can request with smaller time (lets say 5
> mins). Then from token issuer logic we can check application level max
> value and issue token with requested validity period if requested time is
> below what they allow in application level. So this is not really user
> level thing but optional parameter we send on demand when we generate
> tokens. If token generation request allows to send optional parameters like
> DCR we will be able to send requested_validity(if not sent default
> application level validity time will apply).
>
> Thanks,
> sanjeewa.
>
>>
>> Just heard that; IOT server may has already requirement with that;  It is
>> needed to define a token expiry level based on their device type.  Say;
>>  some device's token may be embedded & these token may have longer expiry
>> time (never expired).  Also;  some devices type need a  less expiry time
>> based on their security policies.   It is not sure how we are handled this
>> with APIM feature without $subject.   But;  this can be easily handled, if
>> we can have such feature inbuilt.
>>
>> Thanks,
>> Asela
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <071%20306%208779>
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
--

Lahiru Sandaruwan
WSO2 Inc., http://wso2.com

lean.enterprise.middleware

m: +1 901 530 2379
e: lahi...@wso2.com b: https://medium.com/@lahirugmg
in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IAM] eIDAS profile support for SAML

[Indunil Upeksha Rathnayake]

Hi,

eIDAS (electronic IDentification, Authentication and trust Services) is an
EU regulation on electronic identification and trust services for
electronic transactions in the internal market. The eIDAS interoperability
framework including its national entities (eIDAS-Connector and
eIDAS-Service) need to exchange messages including personal and technical
attributes to support cross-border identification and authentication
processes (Please refer [1] for more information). For the exchange of
messages, the use of the SAML 2.0 specifications has been agreed and there
are eIDAS compliant set of technical specifications in [2], which Member
States of EU to use to develop their own eIDAS-compliant implementation.


As per the "eIDAS SAML Message Format" specification, handling and
inclusion of attributes into exchanged messages is defined as follows.

   - Attributes MUST be requested as  and
*
   MUST be included in the  element of the SAML
   AuthnRequest.*

Ex:

http://www.w3.org/2000/09/xmldsig#;
*xmlns:eidas="http://eidas.europa.eu/saml-extensions
"* ...>
 
 **
   *public*
**
   http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="false" />
   http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
   
 
 .



   - Apart from the attributes, for indicating whether an authentication
   request is made by a private sector or public sector SP, the defined
   element * MUST be present* either in the 
   element of SAML metadata or in the  element of a
   .


As per the SAML Core specification in [3], SAML Extensions is an optional
element in SAML 2.0, allowing arbitrary information to be passed to the
identity provider which are agreed on between the communicating parties. As
mentioned above, eIDAS attributes should be included within SAML extension
element.


Currently in IS, *SAML Extensions processing *has not taken into the
consideration. So that, in order to have eIDAS profile support for SAML,
that should be considered. Please find the following proposed
implementation.

   1. *Register a set of SAML Extension Processors* - extensible mechanism
   where we can include any extension processing
   2. *eIDAS Extension Processor *- specifically handled the eIDAS extension
   3. *Invoke the processors when building the SAML assertion*
  - Consider that all the necessary attributes are configured as the SP
  requested claims
   - In the eIDAS processor, filtering out the requested attributes based
  on the "RequestedAttributes" elements in the authentication request


Really appreciate your suggestions and comments.


[1]
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/How+does+it+work+-+eIDAS+solution
[2]
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/2016/12/16/eIDAS+Technical+Specifications+v.+1.1
[3] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Thanks and Regards

-- 
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Emailindu...@wso2.com
Mobile   0772182255
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release WSO2 IoT Server 3.2.0 RC2

[Shavindri Dissanayake]

Hi All,

Tested the following scenarios,

   1. Enrolled an iOS device on the server.
   2. Tested operations such as device lock.
   3. Enforced policies and revoked.
   4. Unenrolled the device.
   5. Enrolled an Android device.
   6. Tested the ring and device lock operations.
   7. Applied a policy and unpublished the policy from the device.
   8. Enrolled the virtual fire alarm and tried it out.
   9. Created an execution plan to run at a particular time, and enabled
   and disabled the camera on an Android device.

[+] Stable - Go ahead and release


Thanks & Regards
Shavindri Dissanayake
Senior Technical Writer

WSO2 Inc.
lean.enterprise.middleware

On Tue, Feb 27, 2018 at 3:53 PM, Inosh Perera  wrote:

> Hi All,
>
> Tested the following scenarios,
>
>1. Enrolled an iOS device on the server.
>2. Tested operations such as device lock.
>3. Enforced policies and revoked.
>4. Unenrolled the device.
>
> [+] Stable - Go ahead and release
>
>
> Regards,
> Inosh
>
> On Tue, Feb 27, 2018 at 1:47 PM, Kamidu Punchihewa 
> wrote:
>
>> Hi all,
>>
>> I have tested following functionalities on a single node deplyment:
>>
>>- Enrolled an android device and perform operations in BYOD mode.
>>- Enrolled an iOS device and perform operations.
>>- Check the notifications and notification removal and mark as read
>>functionalities.
>>- Create and publish iOS and Android restriction policies.
>>
>> [+1] Stable - Go ahead and release
>>
>> Thanks and Best Regards,
>>
>>
>>
>> On Tue, Feb 27, 2018 at 1:24 PM, Madhawa Perera 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have tested following functionalities:
>>>
>>> 1. Android device enrolment and dis-enrollment
>>> 2. Android device operation and policy as admin user:
>>> - Device Lock
>>> - Change Lock Code
>>> - Ring
>>> - Location
>>> - Camera restriction policy
>>> 3. iOS device enrollment and dis-enrollment
>>> 4. iOS device operation and policy as admin user:
>>> - Ring
>>> - Notification
>>> - Camera restriction policy
>>>
>>> Found no issues.
>>>
>>> +1 Stable - go ahead and release.
>>>
>>> Thank you
>>> Best Regards,
>>> Madhawa
>>>
>>> On Tue, Feb 27, 2018 at 6:37 AM, Charitha Goonetilleke <
>>> charit...@wso2.com> wrote:
>>>
 Hi All,

 Successfully tested the following :

1. Add API based device type with MQTT transport.
2. Enroll and communicate with the agent.
3. Renewed token using refresh token grant type.
4. Send operation to agent and receive operation response.
5. Publish operation response to analytics

 [+] Stable - Go ahead and release

 Thanks & regards,
 /charithag

 On Tue, Feb 27, 2018 at 10:18 AM, Nuwan Jayawardene 
 wrote:

> Successfully tested the following :
>
>
>1. Android BYOD Device enrollment
>2. Invoked following operations: Ring, Device Lock, Location,
>Mute, Change Lock code, Enterprise wipe, Wipe data
>3. Passcode policy for BYOD
>4. Restriction policy for BYOD
>
> I am +1 for this release
>
>
> Thanks and regards
>
>
> On Tue, Feb 27, 2018 at 7:08 AM, Ruwan Yatawara 
> wrote:
>
>> Successfully tested the following :
>>
>> 1. Android Device Enrollment
>> 2  Invoking Ring, Message, Location Operation
>> 3. Configuring Geo Alerts
>> 3. Adding Stationary, Exit and Entry Alerts
>> 4. Adding a new Device Type
>>
>> I am +1 to release.
>>
>>
>> Thanks and Regards,
>>
>> Ruwan Yatawara
>>
>> Technical Lead,
>> WSO2 Inc.
>>
>> email : ruw...@wso2.com
>> mobile : +94 77 9110413
>> http://ruwansrants.blogspot.com/
>> https://500px.com/ruwan_ace
>> https://medium.com/@ruwanyatawara
>>
>>
>> On Mon, Feb 26, 2018 at 2:17 AM, Rasika Perera 
>> wrote:
>>
>>> Hi Devs,
>>>
>>> We are pleased to announce the release candidate of WSO2 IoT Server
>>>  3.2.0.
>>>
>>> This is the second release candidate (RC) of the WSO2 IoT Server 3.2.0
>>> release.
>>>
>>> This release carries 275+ issue fixes [1-12] over the last GA (3.1.0)
>>> release.
>>>
>>> Reported Issues:
>>>
>>>- https://github.com/wso2/product-iots/issues
>>>
>>> Source and distribution packages:
>>>
>>>- https://github.com/wso2/product-iots/releases/tag/v3.2.0-RC2
>>>
>>> Tag to be voted upon:
>>>
>>>- https://github.com/wso2/product-iots/releases/tag/v3.2.0-RC2
>>>
>>> Please download, test, and vote. The README file under the
>>> distribution contains guide and instructions on how to try it out 
>>> locally.
>>>
>>> [+] Stable - Go ahead and release
>>> [-] Broken - Do not release (explain why)
>>>
>>> [1] 

Re: [Architecture] [Dev] [VOTE] Release WSO2 IoT Server 3.2.0 RC2

[Inosh Perera]

Hi All,

Tested the following scenarios,

   1. Enrolled an iOS device on the server.
   2. Tested operations such as device lock.
   3. Enforced policies and revoked.
   4. Unenrolled the device.

[+] Stable - Go ahead and release


Regards,
Inosh

On Tue, Feb 27, 2018 at 1:47 PM, Kamidu Punchihewa 
wrote:

> Hi all,
>
> I have tested following functionalities on a single node deplyment:
>
>- Enrolled an android device and perform operations in BYOD mode.
>- Enrolled an iOS device and perform operations.
>- Check the notifications and notification removal and mark as read
>functionalities.
>- Create and publish iOS and Android restriction policies.
>
> [+1] Stable - Go ahead and release
>
> Thanks and Best Regards,
>
>
>
> On Tue, Feb 27, 2018 at 1:24 PM, Madhawa Perera  wrote:
>
>> Hi all,
>>
>> I have tested following functionalities:
>>
>> 1. Android device enrolment and dis-enrollment
>> 2. Android device operation and policy as admin user:
>> - Device Lock
>> - Change Lock Code
>> - Ring
>> - Location
>> - Camera restriction policy
>> 3. iOS device enrollment and dis-enrollment
>> 4. iOS device operation and policy as admin user:
>> - Ring
>> - Notification
>> - Camera restriction policy
>>
>> Found no issues.
>>
>> +1 Stable - go ahead and release.
>>
>> Thank you
>> Best Regards,
>> Madhawa
>>
>> On Tue, Feb 27, 2018 at 6:37 AM, Charitha Goonetilleke <
>> charit...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> Successfully tested the following :
>>>
>>>1. Add API based device type with MQTT transport.
>>>2. Enroll and communicate with the agent.
>>>3. Renewed token using refresh token grant type.
>>>4. Send operation to agent and receive operation response.
>>>5. Publish operation response to analytics
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> Thanks & regards,
>>> /charithag
>>>
>>> On Tue, Feb 27, 2018 at 10:18 AM, Nuwan Jayawardene 
>>> wrote:
>>>
 Successfully tested the following :


1. Android BYOD Device enrollment
2. Invoked following operations: Ring, Device Lock, Location, Mute,
Change Lock code, Enterprise wipe, Wipe data
3. Passcode policy for BYOD
4. Restriction policy for BYOD

 I am +1 for this release


 Thanks and regards


 On Tue, Feb 27, 2018 at 7:08 AM, Ruwan Yatawara 
 wrote:

> Successfully tested the following :
>
> 1. Android Device Enrollment
> 2  Invoking Ring, Message, Location Operation
> 3. Configuring Geo Alerts
> 3. Adding Stationary, Exit and Entry Alerts
> 4. Adding a new Device Type
>
> I am +1 to release.
>
>
> Thanks and Regards,
>
> Ruwan Yatawara
>
> Technical Lead,
> WSO2 Inc.
>
> email : ruw...@wso2.com
> mobile : +94 77 9110413
> http://ruwansrants.blogspot.com/
> https://500px.com/ruwan_ace
> https://medium.com/@ruwanyatawara
>
>
> On Mon, Feb 26, 2018 at 2:17 AM, Rasika Perera 
> wrote:
>
>> Hi Devs,
>>
>> We are pleased to announce the release candidate of WSO2 IoT Server 3
>> .2.0.
>>
>> This is the second release candidate (RC) of the WSO2 IoT Server 3.2.0
>> release.
>>
>> This release carries 275+ issue fixes [1-12] over the last GA (3.1.0)
>> release.
>>
>> Reported Issues:
>>
>>- https://github.com/wso2/product-iots/issues
>>
>> Source and distribution packages:
>>
>>- https://github.com/wso2/product-iots/releases/tag/v3.2.0-RC2
>>
>> Tag to be voted upon:
>>
>>- https://github.com/wso2/product-iots/releases/tag/v3.2.0-RC2
>>
>> Please download, test, and vote. The README file under the
>> distribution contains guide and instructions on how to try it out 
>> locally.
>>
>> [+] Stable - Go ahead and release
>> [-] Broken - Do not release (explain why)
>>
>> [1] https://github.com/wso2/product-iots/milestone/3?closed=1
>> [2] https://github.com/wso2/product-iots/milestone/4?closed=1
>> [3] https://github.com/wso2/product-iots/milestone/5?closed=1
>> [4] https://github.com/wso2/product-iots/milestone/6?closed=1
>> [5] https://github.com/wso2/product-iots/milestone/7?closed=1
>> [6] https://github.com/wso2/product-iots/milestone/11?closed=1
>> [7] https://github.com/wso2/product-iots/milestone/12?closed=1
>> [8] https://github.com/wso2/product-iots/milestone/13?closed=1
>> [9] https://github.com/wso2/product-iots/milestone/14?closed=1
>> [10] https://github.com/wso2/product-iots/milestone/18?closed=1
>> [11] https://github.com/wso2/product-iots/milestone/19?closed=1
>> [12] https://github.com/wso2/product-iots/milestone/20?closed=1
>>
>> Regards,
>> The WSO2 IoT Team.
>>
>> --
>> With 

Re: [Architecture] [Dev] [VOTE] Release WSO2 IoT Server 3.2.0 RC2

[Kamidu Punchihewa]

Hi all,

I have tested following functionalities on a single node deplyment:

   - Enrolled an android device and perform operations in BYOD mode.
   - Enrolled an iOS device and perform operations.
   - Check the notifications and notification removal and mark as read
   functionalities.
   - Create and publish iOS and Android restriction policies.

[+1] Stable - Go ahead and release

Thanks and Best Regards,



On Tue, Feb 27, 2018 at 1:24 PM, Madhawa Perera  wrote:

> Hi all,
>
> I have tested following functionalities:
>
> 1. Android device enrolment and dis-enrollment
> 2. Android device operation and policy as admin user:
> - Device Lock
> - Change Lock Code
> - Ring
> - Location
> - Camera restriction policy
> 3. iOS device enrollment and dis-enrollment
> 4. iOS device operation and policy as admin user:
> - Ring
> - Notification
> - Camera restriction policy
>
> Found no issues.
>
> +1 Stable - go ahead and release.
>
> Thank you
> Best Regards,
> Madhawa
>
> On Tue, Feb 27, 2018 at 6:37 AM, Charitha Goonetilleke  > wrote:
>
>> Hi All,
>>
>> Successfully tested the following :
>>
>>1. Add API based device type with MQTT transport.
>>2. Enroll and communicate with the agent.
>>3. Renewed token using refresh token grant type.
>>4. Send operation to agent and receive operation response.
>>5. Publish operation response to analytics
>>
>> [+] Stable - Go ahead and release
>>
>> Thanks & regards,
>> /charithag
>>
>> On Tue, Feb 27, 2018 at 10:18 AM, Nuwan Jayawardene 
>> wrote:
>>
>>> Successfully tested the following :
>>>
>>>
>>>1. Android BYOD Device enrollment
>>>2. Invoked following operations: Ring, Device Lock, Location, Mute,
>>>Change Lock code, Enterprise wipe, Wipe data
>>>3. Passcode policy for BYOD
>>>4. Restriction policy for BYOD
>>>
>>> I am +1 for this release
>>>
>>>
>>> Thanks and regards
>>>
>>>
>>> On Tue, Feb 27, 2018 at 7:08 AM, Ruwan Yatawara  wrote:
>>>
 Successfully tested the following :

 1. Android Device Enrollment
 2  Invoking Ring, Message, Location Operation
 3. Configuring Geo Alerts
 3. Adding Stationary, Exit and Entry Alerts
 4. Adding a new Device Type

 I am +1 to release.


 Thanks and Regards,

 Ruwan Yatawara

 Technical Lead,
 WSO2 Inc.

 email : ruw...@wso2.com
 mobile : +94 77 9110413
 http://ruwansrants.blogspot.com/
 https://500px.com/ruwan_ace
 https://medium.com/@ruwanyatawara


 On Mon, Feb 26, 2018 at 2:17 AM, Rasika Perera 
 wrote:

> Hi Devs,
>
> We are pleased to announce the release candidate of WSO2 IoT Server 3
> .2.0.
>
> This is the second release candidate (RC) of the WSO2 IoT Server 3.2.0
> release.
>
> This release carries 275+ issue fixes [1-12] over the last GA (3.1.0)
> release.
>
> Reported Issues:
>
>- https://github.com/wso2/product-iots/issues
>
> Source and distribution packages:
>
>- https://github.com/wso2/product-iots/releases/tag/v3.2.0-RC2
>
> Tag to be voted upon:
>
>- https://github.com/wso2/product-iots/releases/tag/v3.2.0-RC2
>
> Please download, test, and vote. The README file under the
> distribution contains guide and instructions on how to try it out locally.
>
> [+] Stable - Go ahead and release
> [-] Broken - Do not release (explain why)
>
> [1] https://github.com/wso2/product-iots/milestone/3?closed=1
> [2] https://github.com/wso2/product-iots/milestone/4?closed=1
> [3] https://github.com/wso2/product-iots/milestone/5?closed=1
> [4] https://github.com/wso2/product-iots/milestone/6?closed=1
> [5] https://github.com/wso2/product-iots/milestone/7?closed=1
> [6] https://github.com/wso2/product-iots/milestone/11?closed=1
> [7] https://github.com/wso2/product-iots/milestone/12?closed=1
> [8] https://github.com/wso2/product-iots/milestone/13?closed=1
> [9] https://github.com/wso2/product-iots/milestone/14?closed=1
> [10] https://github.com/wso2/product-iots/milestone/18?closed=1
> [11] https://github.com/wso2/product-iots/milestone/19?closed=1
> [12] https://github.com/wso2/product-iots/milestone/20?closed=1
>
> Regards,
> The WSO2 IoT Team.
>
> --
> With Regards,
>
> *Rasika Perera*
> Senior Software Engineer
> LinkedIn: http://lk.linkedin.com/in/rasika90
>
> 
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>


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


>>>
>>>
>>> --
>>> *Nuwan Jayawardene*
>>> *Software Engineering intern*
>>> *WSO2,