On Wed, Jun 6, 2018 at 1:05 PM, Shazni Nazeer <[email protected]> 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 < > [email protected]> 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: [email protected] >> M :0718407133| http://wso2.com <http://wso2.com/> >> > > > > -- > Shazni Nazeer > > Mob : +94 777737331 > LinkedIn : http://lk.linkedin.com/in/shazninazeer > > Blogs : > > https://medium.com/@mshazninazeer > http://shazninazeer.blogspot.com > > <http://wso2.com/signature> > -- 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
