Hi Colin, On Mon, Apr 6, 2015 at 8:09 PM, Colin Roy-Ehri <[email protected]> wrote:
> 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. > +1. Would have to specifically mention about the changes in official docs. > > In this new model, where would the authorize, revoke, and token gateway > APIs point? > These APIs should point to Key Manager. When using a third party Key Manager, these APIs need to be changed providing the correct OAuth endpoints. In the default case, APIs will point to endpoints in oauth2.war. > > > 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 > > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
