Re: [Architecture] Tool to configure changes while starting an API-M profile

[Sarubi Thillainathan]

Hi Chamin,

We are not going to maintain a separate repository. We will include it into
the startup-scripts folder under product apim.

Thanks,
Sarubi

On Fri, Jun 1, 2018 at 5:40 PM, Chamin Dias  wrote:

> Hi,
>
> How are we going to maintain the code for this? Are we going to maintain
> this like the import-export tool
> 
> or are we going to maintain it separately (another repo maybe)?
>
> Thanks.
>
> On Fri, Jun 1, 2018 at 11:38 AM, Sarubi Thillainathan 
> wrote:
>
>> Adding architecture
>>
>> On Thu, May 31, 2018 at 10:00 AM, Sarubi Thillainathan 
>> wrote:
>>
>>> Hi Naduni,
>>>
>>> Currently, I'm handling port offsets as passing an environment variable
>>> when starting the server only if the user wants to change the port.
>>>
>>>
>>> Thanks
>>>
>>> On Wed, May 30, 2018 at 12:26 PM, Dinusha Dissanayake >> > wrote:
>>>


 On Wed, May 30, 2018 at 12:13 PM, Naduni Pamudika 
 wrote:

> Hi Sarubi,
>
> How are you going to handle port offsets for the profiles? I think
> rather than reading the offset from the carbon.xml file, it would be easy
> to give it as a parameter when running the script. We can make this
> parameter optional. Otherwise the user has to update carbon.xml file 
> before
> running the script and I do not see any reason for doing it as we are
> automating the process here.
>
 Port offset can be passed as a environment variable  like we do *sh
 wso2server.sh -DportOffset={offset}*. I am not sure if it is the best
 way to do this.

> Thanks,
> Naduni
>
> On Wed, May 30, 2018 at 11:45 AM, Dinusha Dissanayake <
> dinus...@wso2.com> wrote:
>
>> Hi Krishan/All,
>>
>> On Wed, May 30, 2018 at 11:35 AM, Krishan Wijesena > > wrote:
>>
>>>
>>>
>>> On Wed, May 30, 2018 at 10:51 AM, Sarubi Thillainathan <
>>> sar...@wso2.com> wrote:
>>>
 Hi Fazlan,

 Yes, it's a shell script. As per the discussion with Nuwan, we have
 planned that user have to manually run the script file according to 
 his/her
 profile preference before starting the server.

>>>how about starting the server using the same script. If some one
>>> want to run KM profile, user just want to execute the script with 
>>> prefered
>>> configurations for KM.
>>>
>> AFAIR, this is going to remove unnecessary web apps and do the
>> necessary configuration. If there are using tools like "chef" or "yajsw"
>> for there further configurations , then starting the server using the 
>> same
>> script might not be ideal.
>>
>> Thanks,
>> DinushaD.
>>
>>>

 On Wed, May 30, 2018 at 10:39 AM, Fazlan Nazeem 
 wrote:

> Hi Sarubi,
>
> Is this going to be a shell script?
>
> If so how are you planning to execute this? Does the user have to
> manually run the script before starting the server with the profile 
> or will
> the script execution be automatically executed when we start the 
> server
> with the profile?
>
> On Wed, May 30, 2018 at 10:34 AM, Sarubi Thillainathan <
> sar...@wso2.com> wrote:
>
>> Hi all,
>> I am working on a project to optimize the API-M profiles by
>> automating the configuration changes while starting an API-M profile.
>> According to the user input, perform corresponding profile set up 
>> for the
>> wso2am-2.5.0-SNAPSHOT on both Unix and Windows environments.
>>
>> Please find the milestone plan in [1] for the project $Subject.
>>
>> Comments or Suggestions are highly appreciated.
>>
>> [1] https://docs.google.com/spreadsheets/d/1C7UyD1e3JvPM17ZpivwD
>> jboL8GX2CD5ZF1B3QTBhFaU/edit?usp=sharing
>>
>> Thanks,
>> --
>> *Sarubi Thillainathan *
>> *Software Engineer - WSO2 Inc.*
>>
>> *Mobile : +94 (0) 76 68 49 101*
>> --
>> You received this message because you are subscribed to the
>> Google Groups "WSO2 Engineering Group" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to engineering-group+unsubscr...@wso2.com.
>> For more options, visit https://groups.google.com/a/ws
>> o2.com/d/optout.
>>
>
>
>
> --
> Thanks & Regards,
>
> *Fazlan Nazeem*
> Senior Software Engineer
> WSO2 Inc
> Mobile : +94772338839
> fazl...@wso2.com
>



 --
 *Sarubi Thillainathan *
 *Software Engineer - WSO2 Inc.*

 *Mobile : +94 (0) 76 68 49 101*

 

Re: [Architecture] Tool to configure changes while starting an API-M profile

[Sarubi Thillainathan]

Hi Chamila,

According to the offline discussion with Nuwan,
Here what we are doing is, automate configuration changes to optimize API-M
profiles. Up to now, it has been manually done by users [1] when they
wanted to run a selected profile.

We provide two options to accomplish this,
1. The user can do the optimization separately before the server starts up
by run the profileSetup.sh along with a particular profile flag. (ex:
profileSetup.sh -Dprofile=api-store ) Once it has done, can use this APIM
package as the root image for CM tools.

2. The user can start the wso2server.sh with a particular profile along
with --optimize flag.
(i.e) wso2server.sh --optimize -Dprofile=api-store.
if and only -optimize flag found we do the optimization for that particular
profile then start the server automatically, otherwise not.

Please find inline comments for further details:


On Tue, Jun 5, 2018 at 4:11 AM, Chamila De Alwis  wrote:

> Hi Sarubi,
>
> I have a couple of questions regarding the fit between the changes that
> this script does and the config automation tools.
>
> Is this a tool focused on evaluation part of the product or the deployment
> part? IMO both would require a re-evaluation of the approach.
>

This is focused on deployment part of product.

>
> IIUC, this script would alter the startup pack, with file additions and
> removals done to config files, deployable artifacts, and other library
> files. This could be a problematic case for continuous config automation
> story.
>
> Consider a scenario where Puppet (or any other tool) configures a set of
> instances, using the APIM pack as the root. The tool might be configured to
> continuously run (say, with a 30-minute interval). Is there a chance for
> the server to be reconfigured every time the tool is run, because the tool
> detects the changes that this script does at the startup, as changes that
> should be rolled back?
>

According to the scenario that you have mentioned, Puppet (or any other
tool) can configures a set of instances, using optimized APIM pack as the
root.


> In that case, it might be better to have this tool as a separate script
> rather than one which starts up the server as well.
>

Yes, now we maintain a seperate script which will get executed based on the
user specification for server start-up.

>
> Another point against such a tool bound to server startup would be the
> mixing of concerns. AFAIU, what this script does falls under what the
> config automation tools do. IMO WSO2 server startup scripts should only
> work on the bootstrapping of the server runtime, rather than the config
> automation part. Also, we would essentially be repeating what the config
> automation tools should do, but in Bash which sometimes is a lot harder.
> Obtaining config values, managing them meaningfully, and applying them to
> files is essentially what a config automation tool does. We may be
> re-inventing the wheel here. For an example, should this tool be concerned
> about the port offset at all since even dev deployments will be done using
> separate VMs/Containers? Or should it be worried about different values for
> the config options in different environments?
>
> Also, this script don't concerned about the port offset things since it
designed only to configure the changes for corresponding profile specified.


> Additionally, users who manage config automation usually adhere to one set
> of scripts. Puppet users almost always go for Puppet, Chef users for Chef
> etc. What we would be delivering might step on what they already have, or
> are comfortable working with, and in turn, the adaption rate might take a
> hit.
>
> User can go with first option, run the profile setup script seperatly
before server start up and get optimized API-M pack as the base image


> IMO you might benefit from reviewing your approach with the Installation
> Experience effort, as the responsibilities of this tool fall close to, if
> not overlap with, what the Installation Experience scripts deliver/would
> deliver with different providers.
>
> WDYT?
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Associate Technical Lead | WSO2
> +94 77 220 7163
> Blog: https://medium.com/@chamilad
>
>
Commnets or suggestions are highly appreciated.

[1]https://docs.wso2.com/display/AM220/Product+Profiles


-- 
*Sarubi Thillainathan *
*Software Engineer - WSO2 Inc.*

*Mobile : +94 (0) 76 68 49 101*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Moving oidc scope-claim mapping from registry to db

[Shazni Nazeer]

I understand the reasons for moving away from registry and it makes sense.
No question about that. And I'm +1 for doing it.

My concern was that architecturally terming it as an anti-pattern. In ESB
there are many production instances running with artifacts like endpoints,
schema, XSLT etc stored and fetched from registry; all at runtime, with no
much issue. And registry had a caching layer too. I see this as an
abstraction, just like data is exposed as a web service API in data
services server.

In this case, I agree on all the good reasons for doing it.

On Wed, Jun 6, 2018 at 9:59 PM, Sagara Gunathunga  wrote:

>
>
> On Wed, Jun 6, 2018 at 1:05 PM, Shazni Nazeer  wrote:
>
>> Currently we persist oidc related scopes and claims in the registry. With
>>> this approach we need to access the registry in run time, which is an
>>> anti-pattern. So going forward we have decided to persist oidc scopes and
>>> claims in the db and remove from the registry.
>>
>>
>> I'm sure there are good reasons to move the claim mappings from the
>> registry to plain DB. But isn't this essentially the same as ultimately
>> registry stores values in the underlying DB. I'm sure the change may make
>> the implementation straightforward to use the DB query instead of the
>> registry API and also makes way to move away from registry. But why using
>> registry is an anti-pattern?
>>
>
> 1. Registry is not designed to cater runtime traffic, it was originally
> designed to cater non-runtime (design time) traffic, so by design there is
> a scalability issue when we use registry in run-time use cases. Few years
> back we have experienced this when trying to persist AS and ESB runtime
> metafiles in the registry.
>
> 2. We are in a process  of moving out registry dependencies from all
> products except G-Reg because most of the cases it's unnecessary , API-M 3
> did this up to some extend. In this case we have noticed a scalability
> issue in userinfo calls and as a part of the fix we are trying to remove
> one registry dependency from IS.
>
> Thanks !
>
>>
>> On Wed, Jun 6, 2018 at 11:48 AM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> Currently we persist oidc related scopes and claims in the registry.
>>> With this approach we need to access the registry in run time, which is an
>>> anti-pattern. So going forward we have decided to persist oidc scopes and
>>> claims in the db and remove from the registry.
>>>
>>> *With the new implementation:*
>>> 1.  In the management console 'Resident Identity Provider > Inbound
>>> Authentication Configuration > OAuth2/OpenidConnect configuration'  will be
>>> divided in to two sections.
>>>a. First section will include the existing EP URLs
>>>b. Second section will include scope claim table which have the
>>> ability to add and delete scope claim mapping.
>>> 2. In the first server start up the scopes and claims defined
>>> in oidc-scope-config.xml will be stored in the db and a caching layer.
>>> 3. So when the UI is loading the scopes and claims that are stored in
>>> the table will be populated to the UI as well.
>>>
>>> I will update the thread with the screen shots of the new UI and the
>>> design of the new table soon. Highly appreciate any suggestions or
>>> feedbacks on this.
>>>
>>> Thanks,
>>>
>>> --
>>>
>>> Hasanthi Dissanayake
>>>
>>> Senior Software Engineer | WSO2
>>>
>>> E: hasan...@wso2.com
>>> M :0718407133| http://wso2.com 
>>>
>>
>>
>>
>> --
>> Shazni Nazeer
>>
>> Mob : +94 37331
>> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>>
>> Blogs :
>>
>> https://medium.com/@mshazninazeer
>> http://shazninazeer.blogspot.com
>>
>> 
>>
>
>
>
> --
> Sagara Gunathunga
>
> Director; WSO2, Inc.;  http://wso2.com
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
> Mobile : +9471 <+94%2071%20565%209887>2149951
>
>


-- 
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] Micro gateway profile for WSO2 EI - 6.3.0

[Madhawa Gunasekara]

Hi All,

We need to come up with a name for this profile.

What's the name that we should put into this profile?

lightweight ei or micro ei?

Thanks,
Madhawa

On Wed, May 16, 2018 at 2:19 AM, Chamila De Alwis  wrote:

> Are we looking at optimizing memory usage also? At the moment, our
>> recommendation is to use 1GB memory allocation at minimum. If we can reduce
>> this to a reasonable value, that would also be a good differentiation.
>>
>
> This would be a really good goal to achieve. Less memory to request per
> container will be drastic differentiation from the existing EI. Most users,
> when mentioned "container-friendly" would expect memory usages to be in the
> MBs than in GBs.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Associate Technical Lead | WSO2
> +94 77 220 7163
> Blog: https://medium.com/@chamilad
>
>
>
> On Tue, May 15, 2018 at 4:10 AM, Chanaka Fernando 
> wrote:
>
>>
>>
>> On Tue, May 15, 2018 at 3:00 PM Isuru Udana  wrote:
>>
>>> Hi Chanaka,
>>>
>>> On Tue, May 15, 2018 at 2:55 PM Chanaka Fernando 
>>> wrote:
>>>
 Hi Madhawa,

 Could you elaborate more on the requirements for a micro ESB profile
 and what benefits we are trying to offer to the users with that? If we are
 talking about building a profile which is 80% of the size of the existing
 integration profile for running on containers, I don't see much value out
 of this effort.

>>> Our main focus is, reducing the startup time drastically.
>>>
>> That's a good point. If we can cut the startup time significantly, that
>> would be really useful when running in containers. Are we looking at
>> optimizing memory usage also? At the moment, our recommendation is to use
>> 1GB memory allocation at minimum. If we can reduce this to a reasonable
>> value, that would also be a good differentiation.
>>
>>>
 Thanks,
 Chanaka

 On Tue, May 8, 2018 at 1:29 AM Chamila De Alwis 
 wrote:

> Hi Madhawa,
>
> Aren't any DB operations involved in this profile?  Is the aim of
> removing Registry to strip down functionality?
>
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Associate Technical Lead | WSO2
> +94 77 220 7163
> Blog: https://medium.com/@chamilad
>
>
>
> On Thu, May 3, 2018 at 11:30 PM, Madhawa Gunasekara  > wrote:
>
>> Hi Isuru,
>>
>> Sure I will check on that.
>>
>> Thanks,
>> Madhawa
>>
>> On Fri, May 4, 2018 at 8:42 AM, Isuru Udana  wrote:
>>
>>> Hi Madhawa,
>>>
>>> Subject is not correct. This is not about a micro gateway. This is
>>> just a new ESB profile which is lightweight and a container friendly 
>>> one.
>>>
>>> Can you please check why we need registry for tasks. I believe it is
>>> for coordination support. We might not need coordination support for 
>>> this
>>> profile.
>>>
>>> Thanks.
>>>
>>> On Thu, May 3, 2018 at 3:41 PM Nuwan Dias  wrote:
>>>
 Hi,

 Why is this being called Microgateway? This will cause huge
 confusion with the WSO2 API Manager's Gateway. Is this really a Gateway
 profile or a stripped down version of the ESB?

 Thanks,
 NuwanD.

 On Thu, May 3, 2018 at 2:56 PM, Madhawa Gunasekara <
 madha...@wso2.com> wrote:

> Hi,
>
> I'm starting working on light weight ESB profile to work on
> containers. so basically we are trying to remove all the ui 
> components and
> the registry for that particular profile. but Tasks are depending on 
> the
> Registry. Therefore We need to find a way to provide tasks 
> functionality
> for this profile.
>
> @Integration team: Any thoughts and suggestions regarding this
> issue
>
> Thanks,
> Madhawa
>
> --
> *Madhawa Gunasekara*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 719411002 <+94+719411002>
> blog: *http://madhawa-gunasekara.blogspot.com
> *
> linkedin: *http://lk.linkedin.com/in/mgunasekara
> *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Nuwan Dias

 Software Architect - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729

>>>
>>>
>>> --
>>> *Isuru Udana*
>>> Senior Technical Lead
>>> WSO2 Inc.; http://wso2.com
>>> email: 

Re: [Architecture] Moving oidc scope-claim mapping from registry to db

[Sagara Gunathunga]

On Wed, Jun 6, 2018 at 1:05 PM, Shazni Nazeer  wrote:

> Currently we persist oidc related scopes and claims in the registry. With
>> this approach we need to access the registry in run time, which is an
>> anti-pattern. So going forward we have decided to persist oidc scopes and
>> claims in the db and remove from the registry.
>
>
> I'm sure there are good reasons to move the claim mappings from the
> registry to plain DB. But isn't this essentially the same as ultimately
> registry stores values in the underlying DB. I'm sure the change may make
> the implementation straightforward to use the DB query instead of the
> registry API and also makes way to move away from registry. But why using
> registry is an anti-pattern?
>

1. Registry is not designed to cater runtime traffic, it was originally
designed to cater non-runtime (design time) traffic, so by design there is
a scalability issue when we use registry in run-time use cases. Few years
back we have experienced this when trying to persist AS and ESB runtime
metafiles in the registry.

2. We are in a process  of moving out registry dependencies from all
products except G-Reg because most of the cases it's unnecessary , API-M 3
did this up to some extend. In this case we have noticed a scalability
issue in userinfo calls and as a part of the fix we are trying to remove
one registry dependency from IS.

Thanks !

>
> On Wed, Jun 6, 2018 at 11:48 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi All,
>>
>> Currently we persist oidc related scopes and claims in the registry. With
>> this approach we need to access the registry in run time, which is an
>> anti-pattern. So going forward we have decided to persist oidc scopes and
>> claims in the db and remove from the registry.
>>
>> *With the new implementation:*
>> 1.  In the management console 'Resident Identity Provider > Inbound
>> Authentication Configuration > OAuth2/OpenidConnect configuration'  will be
>> divided in to two sections.
>>a. First section will include the existing EP URLs
>>b. Second section will include scope claim table which have the
>> ability to add and delete scope claim mapping.
>> 2. In the first server start up the scopes and claims defined
>> in oidc-scope-config.xml will be stored in the db and a caching layer.
>> 3. So when the UI is loading the scopes and claims that are stored in the
>> table will be populated to the UI as well.
>>
>> I will update the thread with the screen shots of the new UI and the
>> design of the new table soon. Highly appreciate any suggestions or
>> feedbacks on this.
>>
>> Thanks,
>>
>> --
>>
>> Hasanthi Dissanayake
>>
>> Senior Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>
>
>
> --
> Shazni Nazeer
>
> Mob : +94 37331
> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>
> Blogs :
>
> https://medium.com/@mshazninazeer
> http://shazninazeer.blogspot.com
>
> 
>



-- 
Sagara Gunathunga

Director; WSO2, Inc.;  http://wso2.com
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com
Mobile : +9471 <+94%2071%20565%209887>2149951
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Moving oidc scope-claim mapping from registry to db

[Chamila De Alwis]

Though the underlying concept may stay the same, IMO this introduces a
considerable end-user experience for the OIDC scope-claim scenario. Having
to navigate to the registry during the OIDC configuration does not feel
natural.

So even if the underlying implementation could/would still use the
registry/registry like pattern, I'm +1 for the UX change this brings in.
All the OIDC related changes will be done in the SP -> Inbound Auth -> OIDC
section.

Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Associate Technical Lead | WSO2
+94 77 220 7163
Blog: https://medium.com/@chamilad




On Wed, Jun 6, 2018 at 12:35 AM Shazni Nazeer  wrote:

> Currently we persist oidc related scopes and claims in the registry. With
>> this approach we need to access the registry in run time, which is an
>> anti-pattern. So going forward we have decided to persist oidc scopes and
>> claims in the db and remove from the registry.
>
>
> I'm sure there are good reasons to move the claim mappings from the
> registry to plain DB. But isn't this essentially the same as ultimately
> registry stores values in the underlying DB. I'm sure the change may make
> the implementation straightforward to use the DB query instead of the
> registry API and also makes way to move away from registry. But why using
> registry is an anti-pattern?
>
> On Wed, Jun 6, 2018 at 11:48 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi All,
>>
>> Currently we persist oidc related scopes and claims in the registry. With
>> this approach we need to access the registry in run time, which is an
>> anti-pattern. So going forward we have decided to persist oidc scopes and
>> claims in the db and remove from the registry.
>>
>> *With the new implementation:*
>> 1.  In the management console 'Resident Identity Provider > Inbound
>> Authentication Configuration > OAuth2/OpenidConnect configuration'  will be
>> divided in to two sections.
>>a. First section will include the existing EP URLs
>>b. Second section will include scope claim table which have the
>> ability to add and delete scope claim mapping.
>> 2. In the first server start up the scopes and claims defined
>> in oidc-scope-config.xml will be stored in the db and a caching layer.
>> 3. So when the UI is loading the scopes and claims that are stored in the
>> table will be populated to the UI as well.
>>
>> I will update the thread with the screen shots of the new UI and the
>> design of the new table soon. Highly appreciate any suggestions or
>> feedbacks on this.
>>
>> Thanks,
>>
>> --
>>
>> Hasanthi Dissanayake
>>
>> Senior Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>
>
>
> --
> 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
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Moving oidc scope-claim mapping from registry to db

[Shazni Nazeer]

>
> Currently we persist oidc related scopes and claims in the registry. With
> this approach we need to access the registry in run time, which is an
> anti-pattern. So going forward we have decided to persist oidc scopes and
> claims in the db and remove from the registry.


I'm sure there are good reasons to move the claim mappings from the
registry to plain DB. But isn't this essentially the same as ultimately
registry stores values in the underlying DB. I'm sure the change may make
the implementation straightforward to use the DB query instead of the
registry API and also makes way to move away from registry. But why using
registry is an anti-pattern?

On Wed, Jun 6, 2018 at 11:48 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi All,
>
> Currently we persist oidc related scopes and claims in the registry. With
> this approach we need to access the registry in run time, which is an
> anti-pattern. So going forward we have decided to persist oidc scopes and
> claims in the db and remove from the registry.
>
> *With the new implementation:*
> 1.  In the management console 'Resident Identity Provider > Inbound
> Authentication Configuration > OAuth2/OpenidConnect configuration'  will be
> divided in to two sections.
>a. First section will include the existing EP URLs
>b. Second section will include scope claim table which have the ability
> to add and delete scope claim mapping.
> 2. In the first server start up the scopes and claims defined
> in oidc-scope-config.xml will be stored in the db and a caching layer.
> 3. So when the UI is loading the scopes and claims that are stored in the
> table will be populated to the UI as well.
>
> I will update the thread with the screen shots of the new UI and the
> design of the new table soon. Highly appreciate any suggestions or
> feedbacks on this.
>
> Thanks,
>
> --
>
> Hasanthi Dissanayake
>
> Senior Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>



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

[Architecture] Moving oidc scope-claim mapping from registry to db

[Hasanthi Purnima Dissanayake]

Hi All,

Currently we persist oidc related scopes and claims in the registry. With
this approach we need to access the registry in run time, which is an
anti-pattern. So going forward we have decided to persist oidc scopes and
claims in the db and remove from the registry.

*With the new implementation:*
1.  In the management console 'Resident Identity Provider > Inbound
Authentication Configuration > OAuth2/OpenidConnect configuration'  will be
divided in to two sections.
   a. First section will include the existing EP URLs
   b. Second section will include scope claim table which have the ability
to add and delete scope claim mapping.
2. In the first server start up the scopes and claims defined
in oidc-scope-config.xml will be stored in the db and a caching layer.
3. So when the UI is loading the scopes and claims that are stored in the
table will be populated to the UI as well.

I will update the thread with the screen shots of the new UI and the design
of the new table soon. Highly appreciate any suggestions or feedbacks on
this.

Thanks,

-- 

Hasanthi Dissanayake

Senior Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture