[Architecture] WSO2 Stream Processor 4.1.0 Released !

[Chiran Fernando]

*WSO2 Stream Processor 4.1.0 Released!WSO2 Stream Processor team is pleased
to announce the release of version 4.1.0 of the WSO2 Stream Processor.WSO2
Stream Processor is an open source embodiment of the WSO2 Analytics
platform, of which the real-time, incremental & intelligent data processing
capabilities let digital businesses create actionable business insights and
data products.You can download this distribution from
https://wso2.com/analytics/install
Online documentation is available at
https://docs.wso2.com/display/SP410/Stream+Processor+Documentation
.How to
Run1. Extract the downloaded zip. 2. Navigate to the /bin
directory ( is the extracted directory).3. Issue one of the
following commands to start the WSO2 Stream Processor Studio. - For
Windows: editor.bat- For Linux: ./editor.shBy default, the OSGi console
starts with the server.New Features in this Release 1. WSO2 Stream
Processor version 4.1.0 is part of WSO2’s Spring 2018 Release

which includes new features and updates across all products, solutions, and
services, that together empower organizations to rapidly comply with GDPR.
Following includes major GDPR related features provided in WSO2 SP 4.1.0. -
Privacy Tool Kit - Removing personally identifiable information and
references to deleted user identities as and when required.- Privacy policy
reference to describe how WSO2 SP 4.1.0 captures your personal information,
the purposes of collecting that information, and details about the
retention of your personal information.- Cookie Policy reference to
describe how WSO2 SP 4.1.0 uses cookies so that it can provide the best
user experience for you, and identify you for security purposes. 1.
Siddhi-store-cassandra extension to persist events to a Cassandra instance
of the users choice.2. Stream Processor Design View to visualize the event
flow in WSO2 SP.This release includes functional improvements, and fixes to
the product. You can find the complete list of improvements and bug fixes
available with the release under 4.1.0-fixes
.Known IssuesAll
the open issues pertaining to WSO2 Stream Processor are reported at the
following location:Stream Processor Issues
How You Can ContributeMailing
ListsJoin our mailing list and correspond with the developers
directly.Developer list : d...@wso2.org  | Subscribe | Mail
Archive User forum : StackOverflow
Reporting IssuesWe
encourage you to report issues, documentation faults and feature requests
regarding WSO2 Stream Processor or in the Carbon base framework through the
public WSO2 Stream Processor JIRA.SupportWe are committed to ensure your
enterprise middleware deployment is completely supported from evaluation to
production. Our unique approach ensures that all support leverages our open
development methodology and is provided by the very same engineers who
build the technology. For more details and to take advantage of this unique
opportunity, visit http://wso2.com/support/ For
more information about WSO2 Stream Processor, please see
https://wso2.com/analytics  or visit the WSO2
Oxygen Tank developer portal for additional resources.Thank you for your
interest in WSO2 Stream Processor.-The WSO2 Stream Processor Team-*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0 Released!

[Sathya Bandara]

WSO2 Identity Server 5.5.0 Released!

The WSO2 Identity Server team is pleased to announce the release of WSO2
Identity Server version 5.5.0.

WSO2 Identity Server is an open source identity and access management
server. It supports a wide array of authentication protocols such as SAML
2.0 Web SSO, OAuth 2.0/1.0a, OpenID Connect, and WS-Federation Passive. It
supports role based authorization and fine grained authorization with XACML
2.0/3.0 while inbound/outbound provisioning is supported through SCIM and
SPML.

WSO2 Identity Server is developed on top of the revolutionary WSO2 Carbon
platform, an OSGi based framework that provides seamless modularity to your
SOA solution via componentization.


All the major features have been developed as pluggable Carbon components.

You can download this distribution from
https://wso2.com/identity-and-access-management/install

Online documentation is available at
http://docs.wso2.org/wiki/display/IS550/WSO2+Identity+Server+Documentation.
How to Run

1. Extract the downloaded zip

2. Go to the bin directory in the extracted folder

3. Run the wso2server.sh or wso2server.bat files as appropriate

4. If you need to start the OSGi console with the server, use the property
-DosgiConsole when starting the server.
New Features in this Release

WSO2 Identity Server version 5.5.0 is part of WSO2’s Spring 2018 Release

which includes new features and updates across all products, solutions, and
services, that together empower organizations to rapidly comply with GDPR
.

The following includes major GDPR related features provided in WSO2 IS 5.5.0


   -

   Privacy Tool Kit - Supports removing references to a deleted user's
   identity as and when required.
   -

   Personal Information Export Capability - End users can retrieve personal
   information stored in WSO2 Identity Server.
   -

   Request Object Support - Ability to send authentication request
   parameters in a self-contained JWT.
   -

   User Consent for Single-Sign-On - Provides users with choice and control
   over sharing their personal data.
   -

   User Consent for Self Sign Up - Capability to provide consent during
   user self registration.
   -

   Consent  Management API - Manage user consents for collecting and
   sharing user's personal information.
   -

   Consent Purposes Management - An interactive UI to manage consent
   purposes/PII categories.
   -

   Private Key JWT Client Authentication - Facilitating OAuth2 client
   authentication using a signed JWT.


This release includes functional improvements and fixes to the product. The
complete list of improvements and bug fixes available with the release can
be found at the following locations:


   -

   5.5.0-RC2 fixes
   

   -

   5.5.0-RC1 fixes
   

   -

   5.5.0-Beta fixes
   

   -

   5.5.0-Alpha3 fixes
   

   -

   5.5.0-Alpha2 fixes
   

   -

   5.5.0-Alpha fixes
   

   -

   5.5.0-M4 fixes
   

   -

   5.5.0-M3 fixes
   

   -

   5.5.0-M2 fixes
   

   -

   5.5.0-M1 fixes
   


Known Issues

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

IS Runtime 

IS Analytics 
How You Can ContributeMailing 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, documentation faults, and feature
requests regarding WSO2 Identity Server or in the Carbon base framework
through the public WSO2 Identity Server JIRA.
Support

We are committed to ensure your enterprise middleware deployment is
completely supported from evaluation to production through a WSO2
Subscription. Our unique approach ensures that all support leverages our
open development methodology and is provided by the very same engineers who
build the technology. For more 

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Nuwan Dias]

Thanks for explanations, the scenarios on when this is needed is now clear.

On Wed, Apr 11, 2018 at 12:30 PM, Johann Nallathamby 
wrote:

> Hi Nuwan,
>
> On Wed, Apr 11, 2018 at 5:43 PM, Nuwan Dias  wrote:
>
>> Provisioning users with a known/proper password would make it possible
>> for them to login/authenticate directly against IS without being
>> authenticated against the federated IDP right?
>>
>
> Yes. The requirement is to allow these users have a password in IS that
> will be governed by the password policies in IS, and allow them to login to
> applications using IS login.
>
>
>> Do we really want to allow that?
>>
>
> Yes, that is the requirement.
>
>
>> If internal admins want to manage their accounts internally, or if we
>> want users to login/authenticate to IS directly, why would they
>> authenticate against a federated IDP in the first place?
>>
>
> There are two use cases that need to have this capability.
>
> 1. Social sign-up - In some websites social signup (not login) is used as
> a means of making the signup process easier, by providing the mandatory
> user attributes, but at the end of it a password must be provisioned. After
> this signup process the user will mostly login using IS. But in some
> scenario social login will also continue to be there, so if the user uses
> social login, we will automatically link that to the already provisioned
> account.
>
> 2. Migrating users from a external IdP - The use case is where a company
> has done an acquisition or merger, or simply has the need to centralize the
> identity management, therefore wants to migrate all the identities from an
> external IdP to IS, and eventually once all identities are migrated may be
> disconnect the IdP even.
>
> Regards,
> Johann.
>
>
>> Why not create their user accounts in IS itself instead of federating?
>>
>
> This won't work for the social signup use case. Even for the external IdP
> migration use case, if it has to be done it has to be a manual bulk import
> process. This is sometimes difficult to do because,
> 1. We cannot get password from the external IdPs
> 2. Even to do it as a bulk admin initiated forced password reset, with the
> recent performance numbers we are seeing it is almost impossible to do it.
>
> Therefore the better option is to do it on the fly when each user wants to
> login to the application.
>
> Regards,
> Johann.
>
>
>> On Wed, Apr 11, 2018 at 9:51 AM, Menaka Jayawardena 
>> wrote:
>>
>>> Hi,
>>>
>>> In WSO2 Identity Server, users can be provisioned to the internal User
>>> store when the users are signing up with social accounts. But in this case,
>>> the users should always use the social login option to login to the
>>> application and the identity admins could not manage them as internal users.
>>>
>>> The main idea of this feature is to provision the users with password so
>>> that a proper user account will be created in the identity server so that
>>> they can use the user name and password to login and the identity admins
>>> can manage the users as internal users.
>>>
>>> As per the Flash PC[1], we need to consider following aspects when
>>> implementing this feature.
>>>
>>> *1. Configuring password provisioning in the IDP level.*
>>> A new option can be provided in the Just-In-Time Provision section to
>>> enable/ disable provisioing with password.
>>>
>>> *2. Prompting a page to get the user claims and password*
>>> When a user is using social sign up, in the sign up flow, new page will
>>> be shown with the claims. The claims that are retrieved from the social
>>> signup response will be automatically populated. Users need to fill any
>>> mandatory claims that are missing in the request as well as they need to
>>> provide a valid password.
>>>
>>>
>>> *3. How multiple social accounts can be associated*This applies when we
>>> support multiple social signup options (Facebook, Google, Twitter etc).
>>> When a user has already signed up with one social account, after some
>>> time, he/she again tries to signup using a different account.
>>> As different social accounts use differnt ids for users, there shoul be
>>> a mechanism to map the values to the existing user.
>>>
>>> As a solution for this we can allow users to add their other social
>>> account details in the user profile. So, when the user is trying to sign up
>>> using another account he/she will be logged into the existing account.
>>>
>>> *4. What are the user claims that we should retrieve from the social
>>> account and do we allow users to edit those claims.*
>>> As we show the claims that are retrieved from the signup request, have
>>> to decide whether we allow users to modify those details. As per the
>>> discussion [1] we only allow to edit the exact claims that can be edited in
>>> the user profile.
>>>
>>> I have written the use cases that will be involved in this use case and
>>> attached herewith.
>>> 

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Johann Nallathamby]

Hi Nuwan,

On Wed, Apr 11, 2018 at 5:43 PM, Nuwan Dias  wrote:

> Provisioning users with a known/proper password would make it possible for
> them to login/authenticate directly against IS without being authenticated
> against the federated IDP right?
>

Yes. The requirement is to allow these users have a password in IS that
will be governed by the password policies in IS, and allow them to login to
applications using IS login.


> Do we really want to allow that?
>

Yes, that is the requirement.


> If internal admins want to manage their accounts internally, or if we want
> users to login/authenticate to IS directly, why would they authenticate
> against a federated IDP in the first place?
>

There are two use cases that need to have this capability.

1. Social sign-up - In some websites social signup (not login) is used as a
means of making the signup process easier, by providing the mandatory user
attributes, but at the end of it a password must be provisioned. After this
signup process the user will mostly login using IS. But in some scenario
social login will also continue to be there, so if the user uses social
login, we will automatically link that to the already provisioned account.

2. Migrating users from a external IdP - The use case is where a company
has done an acquisition or merger, or simply has the need to centralize the
identity management, therefore wants to migrate all the identities from an
external IdP to IS, and eventually once all identities are migrated may be
disconnect the IdP even.

Regards,
Johann.


> Why not create their user accounts in IS itself instead of federating?
>

This won't work for the social signup use case. Even for the external IdP
migration use case, if it has to be done it has to be a manual bulk import
process. This is sometimes difficult to do because,
1. We cannot get password from the external IdPs
2. Even to do it as a bulk admin initiated forced password reset, with the
recent performance numbers we are seeing it is almost impossible to do it.

Therefore the better option is to do it on the fly when each user wants to
login to the application.

Regards,
Johann.


> On Wed, Apr 11, 2018 at 9:51 AM, Menaka Jayawardena 
> wrote:
>
>> Hi,
>>
>> In WSO2 Identity Server, users can be provisioned to the internal User
>> store when the users are signing up with social accounts. But in this case,
>> the users should always use the social login option to login to the
>> application and the identity admins could not manage them as internal users.
>>
>> The main idea of this feature is to provision the users with password so
>> that a proper user account will be created in the identity server so that
>> they can use the user name and password to login and the identity admins
>> can manage the users as internal users.
>>
>> As per the Flash PC[1], we need to consider following aspects when
>> implementing this feature.
>>
>> *1. Configuring password provisioning in the IDP level.*
>> A new option can be provided in the Just-In-Time Provision section to
>> enable/ disable provisioing with password.
>>
>> *2. Prompting a page to get the user claims and password*
>> When a user is using social sign up, in the sign up flow, new page will
>> be shown with the claims. The claims that are retrieved from the social
>> signup response will be automatically populated. Users need to fill any
>> mandatory claims that are missing in the request as well as they need to
>> provide a valid password.
>>
>>
>> *3. How multiple social accounts can be associated*This applies when we
>> support multiple social signup options (Facebook, Google, Twitter etc).
>> When a user has already signed up with one social account, after some
>> time, he/she again tries to signup using a different account.
>> As different social accounts use differnt ids for users, there shoul be a
>> mechanism to map the values to the existing user.
>>
>> As a solution for this we can allow users to add their other social
>> account details in the user profile. So, when the user is trying to sign up
>> using another account he/she will be logged into the existing account.
>>
>> *4. What are the user claims that we should retrieve from the social
>> account and do we allow users to edit those claims.*
>> As we show the claims that are retrieved from the signup request, have to
>> decide whether we allow users to modify those details. As per the
>> discussion [1] we only allow to edit the exact claims that can be edited in
>> the user profile.
>>
>> I have written the use cases that will be involved in this use case and
>> attached herewith.
>> https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_2F9Ezk_
>> WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing
>>
>> Any ideas suggestions are highly appreciated.
>>
>> [1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm
>> (IST) (Rapid Response Group)
>>
>> Thanks and Regards,
>> Menaka
>> --
>> *Menaka Jayawardena*
>> Software 

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Nuwan Dias]

Provisioning users with a known/proper password would make it possible for
them to login/authenticate directly against IS without being authenticated
against the federated IDP right? Do we really want to allow that? If
internal admins want to manage their accounts internally, or if we want
users to login/authenticate to IS directly, why would they authenticate
against a federated IDP in the first place? Why not create their user
accounts in IS itself instead of federating?

On Wed, Apr 11, 2018 at 9:51 AM, Menaka Jayawardena  wrote:

> Hi,
>
> In WSO2 Identity Server, users can be provisioned to the internal User
> store when the users are signing up with social accounts. But in this case,
> the users should always use the social login option to login to the
> application and the identity admins could not manage them as internal users.
>
> The main idea of this feature is to provision the users with password so
> that a proper user account will be created in the identity server so that
> they can use the user name and password to login and the identity admins
> can manage the users as internal users.
>
> As per the Flash PC[1], we need to consider following aspects when
> implementing this feature.
>
> *1. Configuring password provisioning in the IDP level.*
> A new option can be provided in the Just-In-Time Provision section to
> enable/ disable provisioing with password.
>
> *2. Prompting a page to get the user claims and password*
> When a user is using social sign up, in the sign up flow, new page will be
> shown with the claims. The claims that are retrieved from the social signup
> response will be automatically populated. Users need to fill any mandatory
> claims that are missing in the request as well as they need to provide a
> valid password.
>
>
> *3. How multiple social accounts can be associated*This applies when we
> support multiple social signup options (Facebook, Google, Twitter etc).
> When a user has already signed up with one social account, after some
> time, he/she again tries to signup using a different account.
> As different social accounts use differnt ids for users, there shoul be a
> mechanism to map the values to the existing user.
>
> As a solution for this we can allow users to add their other social
> account details in the user profile. So, when the user is trying to sign up
> using another account he/she will be logged into the existing account.
>
> *4. What are the user claims that we should retrieve from the social
> account and do we allow users to edit those claims.*
> As we show the claims that are retrieved from the signup request, have to
> decide whether we allow users to modify those details. As per the
> discussion [1] we only allow to edit the exact claims that can be edited in
> the user profile.
>
> I have written the use cases that will be involved in this use case and
> attached herewith.
> https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_
> 2F9Ezk_WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing
>
> Any ideas suggestions are highly appreciated.
>
> [1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm
> (IST) (Rapid Response Group)
>
> Thanks and Regards,
> Menaka
> --
> *Menaka Jayawardena*
> Software Engineer
> WSO2 Inc.
>
> Phone: +94 71 350 5470
> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
> Blog   : https://menakamadushanka.wordpress.com/
>
>


-- 
Nuwan Dias

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

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Menaka Jayawardena]

Adding Dimuthu

On Wed, Apr 11, 2018 at 3:21 PM, Menaka Jayawardena  wrote:

> Hi,
>
> In WSO2 Identity Server, users can be provisioned to the internal User
> store when the users are signing up with social accounts. But in this case,
> the users should always use the social login option to login to the
> application and the identity admins could not manage them as internal users.
>
> The main idea of this feature is to provision the users with password so
> that a proper user account will be created in the identity server so that
> they can use the user name and password to login and the identity admins
> can manage the users as internal users.
>
> As per the Flash PC[1], we need to consider following aspects when
> implementing this feature.
>
> *1. Configuring password provisioning in the IDP level.*
> A new option can be provided in the Just-In-Time Provision section to
> enable/ disable provisioing with password.
>
> *2. Prompting a page to get the user claims and password*
> When a user is using social sign up, in the sign up flow, new page will be
> shown with the claims. The claims that are retrieved from the social signup
> response will be automatically populated. Users need to fill any mandatory
> claims that are missing in the request as well as they need to provide a
> valid password.
>
>
> *3. How multiple social accounts can be associated*This applies when we
> support multiple social signup options (Facebook, Google, Twitter etc).
> When a user has already signed up with one social account, after some
> time, he/she again tries to signup using a different account.
> As different social accounts use differnt ids for users, there shoul be a
> mechanism to map the values to the existing user.
>
> As a solution for this we can allow users to add their other social
> account details in the user profile. So, when the user is trying to sign up
> using another account he/she will be logged into the existing account.
>
> *4. What are the user claims that we should retrieve from the social
> account and do we allow users to edit those claims.*
> As we show the claims that are retrieved from the signup request, have to
> decide whether we allow users to modify those details. As per the
> discussion [1] we only allow to edit the exact claims that can be edited in
> the user profile.
>
> I have written the use cases that will be involved in this use case and
> attached herewith.
> https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_
> 2F9Ezk_WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing
>
> Any ideas suggestions are highly appreciated.
>
> [1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm
> (IST) (Rapid Response Group)
>
> Thanks and Regards,
> Menaka
> --
> *Menaka Jayawardena*
> Software Engineer
> WSO2 Inc.
>
> Phone: +94 71 350 5470
> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
> Blog   : https://menakamadushanka.wordpress.com/
>
>


-- 
*Menaka Jayawardena*
Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [G-Reg] [RRT] Integrating Swagger Editor with Governance Registry

[Menaka Jayawardena]

[+ Sagara]

On Wed, Apr 11, 2018 at 3:29 PM, Chandana Napagoda 
wrote:

> Hi Prasanna,
>
> Modifying swagger content means you might have to alter associated Rest
> Service as well. In a Rest Service, there can be user-defined metadata and
> autogenerated metadata. How are you going to identify user added metadata?
>
> Also changing swagger content mean you might move/create the RestService
> in a different registry location(Ex: changing title or version). So you
> need to think about how to handle such use cases and what information need
> to be copied to the new artifact. I believe these pieces of information
> should be there in use case acceptance criteria to avoid future confusion.
>
> Regards,
> Chandana
>
> On 10 April 2018 at 16:04, Prasanna Dangalla  wrote:
>
>> Hi Chandana,
>>
>> On Tue, Apr 10, 2018 at 11:55 AM, Chandana Napagoda 
>> wrote:
>>
>>> Hi Menaka,
>>>
>>> When adding a swagger file, it will automatically create a rest service
>>> with metadata available in the swagger file. So when adding a swagger
>>> content through this swagger editor, are we creating rest service metadata
>>> as well?
>>>
>> AFAIU what Menaka is suggesting is to have a backwrod compatability to
>> update the rest service when we edit the swagger from the swagger editor.
>> We need to rethink whether we are editing the same registry artifact or
>> whether we create a new version of the exiting artifact and let the changes
>> reflect on it.
>>
>> Thanks
>> Prasanna
>>
>>>
>>> Regards,
>>> Chandana
>>>
>>>
>>> On 10 April 2018 at 14:28, Menaka Jayawardena  wrote:
>>>
 Hi Shazni,

 Thank you very much for the feedback.

 On Tue, Apr 10, 2018 at 10:13 AM, Shazni Nazeer 
 wrote:

> Agreed with Shiro.
>
> Regarding #2,  IMO editing a swagger should limit to whatever the
> version being edited. Say the edited swagger has to be a newer version,
> then I suppose in G-Reg publisher there's a copy artifact feature, after
> which the developer can modify the newer version.
>
> However regarding #1 I think in publisher there's an option to upload
> the swagger. When a developer created, it would be beneficial to create a
> new swagger by start editing if this could be added.
>
> On Wed, Apr 4, 2018 at 4:09 AM, Menaka Jayawardena 
> wrote:
>
>> Yes... The points 1 and 3 are the same.
>> Sorry for the mistake.
>>
>>
>>
>> On Wed, Apr 4, 2018 at 2:22 PM, Shiro Kulatilake 
>> wrote:
>>
>>> Hi Menaka,
>>>
>>> Comments inline.
>>>
>>> On Wed, Apr 4, 2018 at 2:02 PM, Menaka Jayawardena 
>>> wrote:
>>>
 Hi,

 Currently, in G-Reg publisher, users cannot edit the uploaded
 swagger files. Neither it can be downloaded. So, in order to edit an
 uploaded file, they need to either,

>>> This is when creating REST APIs.
>>>

1.  Edit the local copy, delete the resource in the G-Reg and
re-upload it.
2.  Copy the content of the file, make the changes, delete the
existing G-Reg resource and re-upload it.

 In user's perspective, this is a very cumbersome process to perform
 in-order to get a simple task done.

 As a solution for this, I'm working on integrating the swagger
 editor in G-Reg publisher, where users can edit the swagger files in 
 the
 G-Reg publisher it self.

 The functionality would be similar to the swagger editor in API-M
 Publisher and need some clarification on the following aspects as well.

 1. Do we provide the capability of create a swagger file with the
 editor?
 2. Saving the edited file with a different name.
 3. Do we need to incorporate the editor in the new file creation
 process. i.e, when the user is creating a new swagger file, do we 
 supposed
 to give them to create it with editor as well?

>>>
>>> Whats the difference between 1 and 3 ? Creating a new swagger file
>>> will amount to a new file creation right ?
>>> If we do 2 then we will have to incorporate versioning capabilities
>>> here as well.
>>>
>>> I think in phase 1 we should just do the basic functionality you
>>> have mentioned in the document - just the same that is there in API
>>> Manager.
>>>
>>> Thank you,
>>> Shiro
>>>
>>>

 I have attached the user stories for the basic functionality.

 https://docs.google.com/document/d/1JHmsaWBaUFa_CXBVkDrwL_Bm
 GL1AhD7iw_T3-f6flsI/edit?usp=sharing

 Any ideas, suggestions are highly appreciated.

 Thanks and Regards,
 

Re: [Architecture] [G-Reg] [RRT] Integrating Swagger Editor with Governance Registry

[Chandana Napagoda]

Hi Prasanna,

Modifying swagger content means you might have to alter associated Rest
Service as well. In a Rest Service, there can be user-defined metadata and
autogenerated metadata. How are you going to identify user added metadata?

Also changing swagger content mean you might move/create the RestService in
a different registry location(Ex: changing title or version). So you need
to think about how to handle such use cases and what information need to be
copied to the new artifact. I believe these pieces of information should be
there in use case acceptance criteria to avoid future confusion.

Regards,
Chandana

On 10 April 2018 at 16:04, Prasanna Dangalla  wrote:

> Hi Chandana,
>
> On Tue, Apr 10, 2018 at 11:55 AM, Chandana Napagoda 
> wrote:
>
>> Hi Menaka,
>>
>> When adding a swagger file, it will automatically create a rest service
>> with metadata available in the swagger file. So when adding a swagger
>> content through this swagger editor, are we creating rest service metadata
>> as well?
>>
> AFAIU what Menaka is suggesting is to have a backwrod compatability to
> update the rest service when we edit the swagger from the swagger editor.
> We need to rethink whether we are editing the same registry artifact or
> whether we create a new version of the exiting artifact and let the changes
> reflect on it.
>
> Thanks
> Prasanna
>
>>
>> Regards,
>> Chandana
>>
>>
>> On 10 April 2018 at 14:28, Menaka Jayawardena  wrote:
>>
>>> Hi Shazni,
>>>
>>> Thank you very much for the feedback.
>>>
>>> On Tue, Apr 10, 2018 at 10:13 AM, Shazni Nazeer  wrote:
>>>
 Agreed with Shiro.

 Regarding #2,  IMO editing a swagger should limit to whatever the
 version being edited. Say the edited swagger has to be a newer version,
 then I suppose in G-Reg publisher there's a copy artifact feature, after
 which the developer can modify the newer version.

 However regarding #1 I think in publisher there's an option to upload
 the swagger. When a developer created, it would be beneficial to create a
 new swagger by start editing if this could be added.

 On Wed, Apr 4, 2018 at 4:09 AM, Menaka Jayawardena 
 wrote:

> Yes... The points 1 and 3 are the same.
> Sorry for the mistake.
>
>
>
> On Wed, Apr 4, 2018 at 2:22 PM, Shiro Kulatilake 
> wrote:
>
>> Hi Menaka,
>>
>> Comments inline.
>>
>> On Wed, Apr 4, 2018 at 2:02 PM, Menaka Jayawardena 
>> wrote:
>>
>>> Hi,
>>>
>>> Currently, in G-Reg publisher, users cannot edit the uploaded
>>> swagger files. Neither it can be downloaded. So, in order to edit an
>>> uploaded file, they need to either,
>>>
>> This is when creating REST APIs.
>>
>>>
>>>1.  Edit the local copy, delete the resource in the G-Reg and
>>>re-upload it.
>>>2.  Copy the content of the file, make the changes, delete the
>>>existing G-Reg resource and re-upload it.
>>>
>>> In user's perspective, this is a very cumbersome process to perform
>>> in-order to get a simple task done.
>>>
>>> As a solution for this, I'm working on integrating the swagger
>>> editor in G-Reg publisher, where users can edit the swagger files in the
>>> G-Reg publisher it self.
>>>
>>> The functionality would be similar to the swagger editor in API-M
>>> Publisher and need some clarification on the following aspects as well.
>>>
>>> 1. Do we provide the capability of create a swagger file with the
>>> editor?
>>> 2. Saving the edited file with a different name.
>>> 3. Do we need to incorporate the editor in the new file creation
>>> process. i.e, when the user is creating a new swagger file, do we 
>>> supposed
>>> to give them to create it with editor as well?
>>>
>>
>> Whats the difference between 1 and 3 ? Creating a new swagger file
>> will amount to a new file creation right ?
>> If we do 2 then we will have to incorporate versioning capabilities
>> here as well.
>>
>> I think in phase 1 we should just do the basic functionality you have
>> mentioned in the document - just the same that is there in API Manager.
>>
>> Thank you,
>> Shiro
>>
>>
>>>
>>> I have attached the user stories for the basic functionality.
>>>
>>> https://docs.google.com/document/d/1JHmsaWBaUFa_CXBVkDrwL_Bm
>>> GL1AhD7iw_T3-f6flsI/edit?usp=sharing
>>>
>>> Any ideas, suggestions are highly appreciated.
>>>
>>> Thanks and Regards,
>>> Menaka
>>>
>>> --
>>> *Menaka Jayawardena*
>>> Software Engineer
>>> WSO2 Inc.
>>>
>>> Phone: +94 71 350 5470
>>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>>> Blog   : https://menakamadushanka.wordpress.com/

[Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Menaka Jayawardena]

Hi,

In WSO2 Identity Server, users can be provisioned to the internal User
store when the users are signing up with social accounts. But in this case,
the users should always use the social login option to login to the
application and the identity admins could not manage them as internal users.

The main idea of this feature is to provision the users with password so
that a proper user account will be created in the identity server so that
they can use the user name and password to login and the identity admins
can manage the users as internal users.

As per the Flash PC[1], we need to consider following aspects when
implementing this feature.

*1. Configuring password provisioning in the IDP level.*
A new option can be provided in the Just-In-Time Provision section to
enable/ disable provisioing with password.

*2. Prompting a page to get the user claims and password*
When a user is using social sign up, in the sign up flow, new page will be
shown with the claims. The claims that are retrieved from the social signup
response will be automatically populated. Users need to fill any mandatory
claims that are missing in the request as well as they need to provide a
valid password.


*3. How multiple social accounts can be associated*This applies when we
support multiple social signup options (Facebook, Google, Twitter etc).
When a user has already signed up with one social account, after some time,
he/she again tries to signup using a different account.
As different social accounts use differnt ids for users, there shoul be a
mechanism to map the values to the existing user.

As a solution for this we can allow users to add their other social account
details in the user profile. So, when the user is trying to sign up using
another account he/she will be logged into the existing account.

*4. What are the user claims that we should retrieve from the social
account and do we allow users to edit those claims.*
As we show the claims that are retrieved from the signup request, have to
decide whether we allow users to modify those details. As per the
discussion [1] we only allow to edit the exact claims that can be edited in
the user profile.

I have written the use cases that will be involved in this use case and
attached herewith.
https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_2F9Ezk_WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing

Any ideas suggestions are highly appreciated.

[1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm (IST)
(Rapid Response Group)

Thanks and Regards,
Menaka
-- 
*Menaka Jayawardena*
Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture