Which WSO2 IS server version will API-M 1.9 support?

Thanks,
Samisa...


Samisa Abeysinghe

Vice President Delivery

WSO2 Inc.
http://wso2.com


On Mon, Feb 16, 2015 at 4:23 PM, 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

Reply via email to