Yes, there are some SP 1 fixes, on which some KM features depend on. On Mon, Feb 23, 2015 at 4:15 PM, Samisa Abeysinghe <[email protected]> wrote:
> > > 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 > > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
