+1 for these enhancements. I wonder if #1 the Extended Grant Type could cause unnecessary complexity for the External Authorization server? I think #1 is a necessary feature, but we could make simple grant types an option. For initial configuration of an External Authorization server, it may be easier to work with the default Oauth2 Grant Types. Perhaps we could have a configuration point for the External Authorization server, i.e. <useExtendedGrantTypes> . Just an idea.
-Colin Thanks, Colin Roy-Ehri Software Engineer *WSO2, Inc. : wso2.com <http://wso2.com/>* *Mobile* : 812-219-6517 On Mon, Feb 16, 2015 at 5:53 AM, Amila De Silva <[email protected]> wrote: > Hi All, > > With API Manager 1.9.0, capability will be provided to plug in an External > Authorization server. With this change, Authorization Server will be the > only entity creating OAuth clients, and issuing access tokens. > > In order to seamlessly support some of the existing APIM features, certain > changes should be done on the Store: > > 1. Generating Application Token using an Extended Grant Type > > As of now, Store UI allows to specify a validity period when Generating an > Application Access Token. In the previous releases this was possible, since > KeyManager component could directly access the tables where tokens are > kept. So after generating a token through UI, Store could update the newly > generated token giving a preferred validity period. After decoupling > Authorization Server, Store would no longer be able to do this, through a > direct DB call. Solution to overcome this problem would be to use an > entirely new Grant Type to Generate the Application Access Token. The new > Grant type would accept validity period as a new parameter and use it when > generating the Application Access Token. > > > 2. Using a Separate Table to store Application Access Tokens > > Currently, when rendering the UI, Store gets the Access Token by querying > the Database directly. After decoupling AS, if we are to Display the > Application Token, we would have to Keep the token in a separate Table. In > this scenario, Store would act as another client App created on the AS and > the Table for storing tokens will be used as a temporary storage. This > means that only the most recent Access Token will be kept in, and the table > won’t be used to obtain token meta data (such as validity period , Consumer > Key) during an API invocation. > > > 3. Generate the token only using /token, /authorize endpoints > > First time when creating an Application Access Token, Store calls > APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token. > This method, simply creates a token and write it down to > IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when > moving forward, we would have to obtain the the Application Access Token > only using standard OAuth endpoints. > > > 4. Determining the type of a token using a scope > > In API Manager, the type of the token (whether it is Application or > Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token. > Token Type is used when validating API Invocations (When defining a > resource, the type of token required to access it can be specified, and a > resource can be only accessed with a token of the specified type). Since > the type of the token is tightly coupled with our implementation of Tokens, > to make it usable across different Authorization Servers, Token type will > be mapped to a scope. So Application Tokens will have a scope like > am:application_token (we can make the scope name configurable). When a > token is generated through the Store UI, Store will request the token with > this scope. > > > These are the major changes required for the Store to function properly. > Would appreciate your feedback on these. > > -- > *Amila De Silva* > > WSO2 Inc. > mobile :(+94) 775119302 > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
