We had same kind of implementation in C4 by using tomcat valve instead of filters. May not be same pattern what we expect here.[1]
[1] http://harshathirimanna.blogspot.com/2016/11/ authentication-authorization-common.html And as I remember we did that to C5 as well by Ruwan using C4 implementation to targeting SCIM. I am not sure the last status. If we have already discussed about this before to the discussion, please ignore this. On Mon, Aug 14, 2017 at 5:46 PM, Tanya Madurapperuma <ta...@wso2.com> wrote: > Hi all, > > We (Prabath, NuwanD, Suho, few IS team members, few analytics team > members) had an offline discussion regarding $ Subject. > > *Problem* > With the new rewrite of C5 based products, we have moved from SOAP based > backend product APIs to REST APIs. And there needs to be a mechanism to > secure these product APIs. It can be either OAuth tokens based approach or > basic auth. > > But the products like Analytics do not have in built OAuth support for > token generation, validation etc to achieve the above requirement. > > Also there needs to be an approach to secure product level artifacts such > as Dashboards, widgets etc as well. > > Regardless of the securing mechanism that we use, product users should be > able to try out and evaluate the default distribution of the product > without much effort of setting up an external IDP. > > *Suggested solution* > We will be implementing a custom IDP that has OAuth capabilities (password > grant type) and required SCIM api implementations (Initially from Analytics > dashboard pov we will need SCIM api for getting role list of users). > And this custom IDP will be shipped with the product. > > > > > > *Securing Product APIs* > Product APIs can be secured either with OAuth or basic auth interceptors > based on the request header. > > We will have to maintain a scope to role mapping list in the product side > and using a scope registration service we can register those at the custom > IDP as same as APIM C5 doing. > > *Securing Product Artifacts* > Artifacts such as dashboards, widgets are secured using a role based > approach. Each product will maintain its own list of resources (artifacts) > and respective roles in a database. This database will be updated upon a > new resource addition, modification etc. > > *Securing Product UI elements* > User facing application of the product will require to hide/show certain > UI elements based on the logged in user. This also we can achieve using the > scopes that we use to secure the product apis and roles that we use to > secure product artifacts. Scopes and roles will be stored in the browser. > > For example, if we want to show/hide "create dashboard" button depending > on the logged in user, we can show/hide, if the logged in user has the > create_dashboard scope which is required to call the product api for > creating a dashboard. > > For the product artifacts, say to decide on showing Foo Dashboard's edit > button, we can use roles for that resources. > > > Thanks, > Tanya > > -- > Tanya Madurapperuma > > Associate Technical Lead, > WSO2 Inc. : wso2.com > Mobile : +94718184439 <+94%2071%20818%204439> > Blog : http://tanyamadurapperuma.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
