Let's not use two configuration files. That would make things tough to understand/configure.
Let's put the <KeyManager> configuration (you have proposed above) in the api-manager.xml file and make it optional (commented out by default). Since this configuration is only explicitly required when externalising the Key Manager, in most cases the Key Validator and Key Manager will both be the same instance. The particular code that reads this configuration will read the <KeyManager> configuration first and it not found it will fall back to the <KeyValidator> configuration part. This way the two will be the same in the default case and one should configure the Key Manager explicitly if only required to do so. Thanks, NuwanD. On Mon, Apr 6, 2015 at 9:08 PM, Amila De Silva <[email protected]> wrote: > 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 > > -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
