Hi Colin, On Wed, Mar 11, 2015 at 12:09 AM, Colin Roy-Ehri <col...@wso2.com> wrote:
> +1 for option 1.a. Because this admin feature should be accessible by the > Subscriber role. Preventing that role from accessing the admin services > would complicate the use of the service. > > Also, for point 3. "Exposing a service to register scopes & resources", > the new admin service access should be accessible by the Creator and/or > Publisher roles. > Yes, the new service should be accessible by the Creator. Thanks for bringing this up. > > Thanks, > Colin Roy-Ehri > Software Engineer > *WSO2, Inc. : wso2.com <http://wso2.com/>* > *Mobile* : 812-219-6517 > > On Tue, Mar 10, 2015 at 1:39 PM, Amila De Silva <ami...@wso2.com> wrote: > >> Hi All, >> >> While carrying out development, we came through several gaps that >> prevents IS to be seamlessly used as an Authorization Server. >> 1. Ability for subscribers to invoke OAuthAdminService. >> Subscribers log into the store create Applications , Subscribe to API and >> then Register the applications with Authorization Server (at this point an >> OAuth app is created in IS) to get Consumer Key/Secret pair. Until now API >> Manager has been registering Apps by directly writing to DB >> (IDN_OAUTH_CONSUMER_APPS , a table that should be written only through IS). >> But in future we’ll be creating the OAuthApp by calling OAuthAdminService. >> The problem is, this being an admin service, only the users with admin >> privileges can invoke this. But subscribers log into the store are only >> required to have subscribe permission. Two options are available to solve >> this ; >> >> a. Reducing permission of the Admin Service. >> >> b. Changing the Service in such a way that an authenticated admin >> user can create an OAuth App behalf of another user. >> >> This issue is discussed in the thread "[APIM] Decoupling Authorization >> Server - Authenticating with Identity Server from API Store" >> >> 2. Need an additional grant handler for creating Application Access >> Tokens. >> Plans is to create Application Access Token using an extended grant type. >> For API Manager to work seamlessly with IS (without any feature >> installation), this new grant type needs to be shipped with IS. >> >> 3. Exposing a service to register scopes & resources >> At the time of creating an API, creators have the ability to indicate >> which scopes are needed for accessing a given resource. These scopes are >> referred when issuing an access token. Currently we are saving the scopes >> in IDN_OAUTH2_SCOPE table and resource-scope mapping in >> IDN_OAUTH2_RESOURCE_SCOPE table through a direct DB write. Since writing to >> these tables is the responsibility of the Authorization Server, a service >> should be provided for creating scopes & resources. >> >> >> 4. Checking whether the user is allowed to have a requested scope when >> issuing tokens >> API Manager has extended the default behaviour of issuing tokens. When a >> token is requested for a scope, IS issues the token without performing >> additional checks. In API Manager, a scope can be associated with a role, >> so that only the users having the particular role will be given access >> tokens generated for that scope. This implementation should also be shipped >> with IS. >> >> -- >> *Amila De Silva* >> >> WSO2 Inc. >> mobile :(+94) 775119302 >> >> >> >> _______________________________________________ >> 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 > > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
