We don't expose a validation API in Gateway.External clients will not call directly to the token validation service exposed by the Key Manager. Only the Gateway will consume this service. Since this service is only invoked during an API invocation, and GW and Key Manager should be of the same version, I don't thing there can be a compatibility issue.
On Thu, Sep 25, 2014 at 12:15 AM, Sumedha Rubasinghe <sume...@wso2.com> wrote: > No. The one exposed by API Gateway. > > On Thu, Sep 25, 2014 at 1:59 AM, Amila De Silva <ami...@wso2.com> wrote: > >> >> >> On Wed, Sep 24, 2014 at 10:48 PM, Sumedha Rubasinghe <sume...@wso2.com> >> wrote: >> >>> >>> >>> On Wed, Sep 24, 2014 at 4:25 PM, Amila De Silva <ami...@wso2.com> wrote: >>> >>>> Hi, >>>> >>>> Following are changes done up to now on the Gateway, as a part of >>>> decoupling AS from API Manager. >>>> >>>> 1. Using OAuth2TokenValidationService to validate Access Tokens >>>> >>>> a. APIMgtTokenValidator is the default implementation provided for >>>> OAuth2TokenValidator, which only overrides the validateScope and >>>> validateAccessToken methods. All the sub steps related to token validation >>>> will have to be performed in validateAccessToken method. >>>> >>>> b. To make a clear distinction between the different steps involved in >>>> token validation, a second Handler - KeyValidationHandler has been >>>> introduced. This is an interface having methods >>>> validateToken(),validateSubscription,validateScopes(), >>>> generateConsumerToken(). This will be the interface developers have to >>>> extend when plugging an external Authorization Server. APIMgtTokenValidator >>>> will execute all the methods defined in KeyValidationHandler inside its >>>> validateAccessToken method. >>>> >>>> 2. Modifying OAuth2TokenValidationResponseDTO to pass an Array of Name >>>> Value pairs >>>> >>>> Gateway relies on several parameters like Application Name, Application >>>> Tier, API Tier to throttle API Calls and publish statistics. >>>> APIKeyValidationInfoDTO which is being used now, has separate fields to >>>> represent these parameters.When switching to OAuth2TokenValidationService, >>>> we’ll have to use OAuth2TokenValidationResponseDTO and then these >>>> parameters will be passed as an array of custom name value pairs. >>>> >>>> >>> This would break backward compatibility, If there are clients who are >>> using our token endpoint to get tokens validated. >>> >> You mean the clients calling OAuth2TokenValidationService service (the >> one exposed by IS)? >> >>> >>> 3. Adding Util methods to convert APIKeyValidationInfoDTO >>>> >>>> For their internal operations Gateway and KeyManager uses >>>> APIKeyValidationInfoDTO objects. >>>> >>>> It is these types of objects being kept in KeyManager and Gateway >>>> caches, it is the same type being passed across different methods when >>>> validating keys and JWTs and this used to be the type returned when calling >>>> validateKey method in APIKeyValidationService. But when switching to >>>> OAuth2TokenValidationService, since the response it returns is a >>>> OAuth2TokenValidationResponseDTO ,several util methods were added to >>>> convert APIKeyValidationInfoDTO to OAuth2TokenValidationResponseDTO and >>>> vice versa. >>>> >>>> Will provide some sequence diagrams illustrating the flow for a key >>>> validation call. >>>> -- >>>> *Amila De Silva* >>>> >>>> WSO2 Inc. >>>> mobile :(+94) 775119302 >>>> >>>> >>> >>> >>> -- >>> /sumedha >>> m: +94 773017743 >>> b : bit.ly/sumedha >>> >> >> >> >> -- >> *Amila De Silva* >> >> WSO2 Inc. >> mobile :(+94) 775119302 >> >> > > > -- > /sumedha > m: +94 773017743 > b : bit.ly/sumedha > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
