Hi All, As we all know we are heavily using OAuth 2 in our product stack. And we have implemented many components in different places time to time as per requirements. But if we consider big story we may simplify it and provide complete implementation in a way it can use across all products. Here are some of the important components we have implemented so far.
- identity/oauth components (OAuth ui and BE components) [1] - API Manager, KeyManager interface, abstract and implementation classes, API key validation service[2]. - Device Manager - Dynamic Client Registration web application[3]. - Recently implemented resource registration and DCR components[4]. Here we can consider 2 ways of implementing Dynamic Client Registration[ https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-30], Resource Registration, Introspection[ https://tools.ietf.org/html/draft-richer-oauth-introspection-06]. Resource registration should be done with resource server and we can implement different resource registration APIs based on scenario(APIM case resource would be API etc). 01. As WSO2 we will provide DCR, RR, Introspection endpoint based on our implementation. In this case we will directly call to OAuth implementation and do operations. This is pretty much similar with current MDM DCR implementation. Advantage is we can implement APIs without other oauth server dependencies. And implementation would be simple. Disadvantage is if we need to plug other OAuth server to system then we need to implement APIs again or directly use their APIs from client side. Following diagram will explain this solution. 02. We can implement DCR, RR, Introspection APIs based on generic key manager interface and actual implementation can be depend on oauth server. In this case we will implement DCR, Introspection based on interface using factory pattern. Advantage is we can expose single end point without depending on underlying key Manager. Following diagram will explain 2nd solution. . As of now API Manager is having capability of extending key manager based on key manager interface. If we implemented DCR, RR, Introspection APIs based on our current OAuth implementation then we will loose capability of plugging external key managers. While working on recent API Manager improvement i found that we can easily implement above APIs based on Key Manager interface. As of now resource registration is also part of Key Manager interface. Sometimes we may be able to introduce resource manager API and point it to resource server. Only issue i found there was we are passing API object to create resource (in registerNewResource() method). If we consider different scenarios in platform resource will not always map to API. Sometimes it can be application, registry resource etc. So just to fix it we can make it generic resource or object(instead of API). Then according to our implementation we can do whatever we need during resource registration(get API, Artifact, App from resource). Then we can straightly implement resource registration and dynamic client registration on that interface. If we go for this kind of solution first we need to draft OAuth Server specification and supported methods. Then we can extract interface out of it and do implementation(this is already done in APIM in API Manager specific way so we may generalize it). What do you think about this? Is it good idea to move second solution? Appreciate your suggestions. [1]https://github.com/wso2/carbon-identity/tree/master/components/oauth [2] https://github.com/wso2/carbon-apimgt/tree/master/components/apimgt/org.wso2.carbon.apimgt.keymgt [3] https://github.com/wso2/carbon-device-mgt/tree/master/components/identity-extensions/dynamic-client-registration [4]https://github.com/wso2/carbon-identity/pull/833 Thanks, sanjeewa. -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
