On Mon, Feb 23, 2015 at 4:07 PM, Amila De Silva <[email protected]> wrote:
> Hi Samisa, > > Should be compatible with IS 5.0. > With the SP I suppose? > > On Mon, Feb 23, 2015 at 3:38 PM, Samisa Abeysinghe <[email protected]> > wrote: > >> 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 >> >> > > > -- > *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
