On Tue, Oct 11, 2016 at 9:46 AM, Abimaran Kugathasan <[email protected]> wrote:
> Hi Nuwan, > > I have some clarifications on this. > > On Mon, Oct 10, 2016 at 6:18 PM, Nuwan Dias <[email protected]> wrote: > >> Hi, >> >> With the current efforts on moving to C5 based architecture, API Manager >> plans to rely on standalone IS (without installing features) so that it can >> operate as the Key Manager for the API Gateway. In order to achieve this, >> there are a few feature gaps in IS we have identified earlier that need to >> be filled in. Please see the list below. >> >> 1. A Dynamic Client Registration Endpoint >> >> When users create Applications and Keys on the API Store, we need to call >> an Endpoint on IS to register the Application. Once an Application is >> registered, API Manager also requires an endpoint to retrieve the >> Application's information by querying using the Application name. >> > > Does this mean, API Manager will no longer keep any data related to OAuth > Application? It will keep only the OAuth Application ID/Name against API > subscription? And for API Manager will call IS all the OAuth application > related queries? > Yes, correct. Even today, we only store the client_id in the API Manager specific tables. All other OAuth related information is stored in the Identity Server tables. > > What will the workaround for any third party Key Managers which don't have > above capabilities (storing OAuth application related information > themselves) ? > As long as the third party Key Manager can create, persist and retrieve a client_id, that should be sufficient for us. Which is of course a primary need for a third party to qualify as a key manager. > Also, with this effort, we no longer have API Manager as Key Manager > scenario, only Identity Server can act as Key Manager? > The idea is to get IS to work solely as the Key Manager. If that is successful, there is no need for a Key Manager profile in API Manager. > > >> >> 2. A Resource Registration Endpoint >> >> When defining scopes and associating Resources to scopes, it is required >> to register these scopes on IS. Scopes should also have a role (or similar) >> binding so that we can perform RBAC (at a minimal) for scopes. It is ideal >> to make this an extensible framework so that others could associate thing >> like permissions to scope as well. >> >> 3. A Resource Validation Endpoint against scopes >> >> When the Gateway grants access on a particular token to a resource, it >> needs to check if the given token bears the necessary scope to access that >> resource. >> >> At the moment we have identified the above 3 as mandatory features to be >> supported by IS if the said integration is to be feasible. We would be >> grateful if these could be taken into consideration when IS is being built >> on C5. >> >> Thanks, >> NuwanD. >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks > Abimaran Kugathasan > Senior Software Engineer - API Technologies > > Email : [email protected] > Mobile : +94 773922820 > > <http://stackoverflow.com/users/515034> > <http://lk.linkedin.com/in/abimaran> > <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> > <https://twitter.com/abimaran> > > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
