Re: [Architecture] [APIM] Authorization server decoupling - Changes in configurations and in Server Profiles
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 ami...@wso2.com wrote: Hi Colin, On Mon, Apr 6, 2015 at 8:09 PM, Colin Roy-Ehri col...@wso2.com 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 ami...@wso2.com 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 AuthorizationServerURLhttps://localhost:9443/services/ /AuthorizationServerURL TokenURLhttps://localhost:8243/token/TokenURL RevokeURLhttps://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 Architecture@wso2.org
[Architecture] [APIM] Authorization server decoupling - Changes in configurations and in Server Profiles
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 AuthorizationServerURLhttps://localhost:9443/services/ /AuthorizationServerURL TokenURLhttps://localhost:8243/token/TokenURL RevokeURLhttps://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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Authorization server decoupling - Changes in configurations and in Server Profiles
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 ami...@wso2.com 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 AuthorizationServerURLhttps://localhost:9443/services/ /AuthorizationServerURL TokenURLhttps://localhost:8243/token/TokenURL RevokeURLhttps://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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Authorization server decoupling - Changes in configurations and in Server Profiles
Hi Colin, On Mon, Apr 6, 2015 at 8:09 PM, Colin Roy-Ehri col...@wso2.com 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 ami...@wso2.com 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 AuthorizationServerURLhttps://localhost:9443/services/ /AuthorizationServerURL TokenURLhttps://localhost:8243/token/TokenURL RevokeURLhttps://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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
