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
