Hi, Adding an additional server profile adds additional complexity, and separating the config files may help clarify this. I highly recommend extensive comments describing the different configurations within the new xml file. Also, adding comments to the renamed api-validator section of the api-manager file would also be helpful.
In this new model, where would the authorize, revoke, and token gateway APIs point? Thanks, Colin Roy-Ehri Software Engineer *WSO2, Inc. : wso2.com <http://wso2.com/>* *Mobile* : 812-219-6517 On Mon, Apr 6, 2015 at 5:14 AM, Amila De Silva <[email protected]> wrote: > Hi All, > > Objective of this mail is to highlight the changes that needs to be done > in server profiles and in configuration files while implementing this > feature. > > As of now when Gateway receives a request, it talks to a server which > performs the following operations; > > 1. Get details of the access token by querying the Database. > 2. Check the validity of the token. > 3. Check if the user is subscribed to the API. > 4. Check if the token has necessary scopes to access the resource. > 5. Generate JWT using details derived from the token. > > In this design, the server to which GW calls is the same entity which > manages tokens. So calling this entity as Key Manager suits in this > scenario. > > After decoupling the Authorization server, the server to which GW calls, > will not be the same entity that manages tokens. To make this distinction > clear, a new profile will be introduced (which we'll refer to as Key > Validator for now). Basically GW calls to Key Validator which performs all > the above operations except 1st and 2nd. To complete its validation, Key > Validator obtains token details by calling to a Key Manager (Authorization > Server) - which can either be the one shipped with APIM or else a third > party one. > > > 1st Diagram illustrates the interaction between server profiles we > currently have and the second diagram shows the interactions after adding > the new profile. > > > > > Boxes in the diagram represent the profiles, not the server instances in a > deployment. When using the inbuilt KM, a typical deployment will have > KeyValidator and KeyManager profiles in the same JVM. All the server roles > except Gateway, will have to know about Key Manager. > > These are the changes happening in configuration files; > > 1. Key-Manager section in api-manager.xml will be changed as Key-Validator > a. TokenEndPointName and RevokeAPIURL elements will be removed from > Key-Validator section. > b. Two new elements ApplicationTokenScope & > KeyValidationHandlerClassName will be introduced. > > 2. A new config named key-manager.xml will be introduced. > Purpose of having this file is to provide a single location to keep all > the settings, configs used by a KeyManager implementation. > > This is the structure of the key-manager.xml to be shipped with APIM by > default. > > <KeyManager class="org.wso2.carbon.apimgt.keymgt.AMDefaultKeyManagerImpl" > xmlns="http://wso2.org/projects/apimgt/key-manager.xml";> > <Configuration> > <AuthorizationServerURL>https://localhost:9443/services/ > </AuthorizationServerURL> > <TokenURL>https://localhost:8243/token</TokenURL> > <RevokeURL>https://localhost:8243/revoke</RevokeURL> > </Configuration> > </KeyManager> > > Since generating/revoking tokens are done by the class implementing > KeyManager interface, those urls have been moved in to this config. > > Contents inside the <Configuration> block can change based on the > implementing class. For example, when plugging in an third party Key > Manager (Authorization Server), introspect endpoint might have to be > provided. > > Please share your thoughts. > > -- > *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
