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 <sha...@wso2.com> 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 <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> > _______________________________________________ > 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
