Re: [Architecture] API Manager Authorization Server Decoupling
Hi, As we discussed in last time we will let external key manager integrator to come up with their own application. At the same time we will be maintaining application object in APIM side to have minimum fields. And other data will hold as key value pairs. May be we can discuss this further and remove one class(external application class). In that case they might need to maintain their own application abject. And i added this these configurations to key manager section. Thanks, sanjeewa. On Wed, Oct 15, 2014 at 7:36 PM, Amila De Silva ami...@wso2.com wrote: Hi Sanjeewa, Why do we need an ApplicationClassName? I assume this is to provide an Abstraction for different Applications (or clients ) created from an External Authorization Server. If this is the case, do we really need to Abstract that out ? If I understood it correctly , we discussed about having one AppInfo object to represent an Application, which will have one or two common fields (like Consumer Key and Key Type) and then a Map to hold all the other Authorization Server specific fields . On Wed, Oct 15, 2014 at 5:57 AM, Sanjeewa Malalgoda sanje...@wso2.com wrote: Hi All, Here is a brief update on status of External Key Management server -APIM integration implementation. We will move all External Key Management server related implementation classes outside from impl and other API Manager related code. So once this is completed we need to build this jar and put it to dropins directory and restart server. And they need to add required configuration to configs. IMO we need to begin this implementation with clear separation of external jar file and API Manager implementation. For the moment we will use following package name for this newly added package(if need we can change it in future). org.wso2.carbon.apimgt.ext.keymgt There we will have following package hierarchy . └── 1.0.0 ├── pom.xml └── src └── main └── java └── org └── wso2 └── carbon └── ext.keymgt ├── APIManagerTest.java ├── ExtKeyMgtAppInfoDTO.java ├── ExtKeyMgtAuthenticator.java ├── ExtKeyMgtDao.java └── ExternalKeyManagerImpl.java Here ExternalKeyManagerImpl will be implementation of KeyManager interface. ExtKeyMgtAppInfoDTO will be data level representation of application in External Key Manager side. This should be implemented ApplicationInfo interface. ExtKeyMgtDao will be used to data access required to external key manager. ExtKeyMgtAuthenticator will be used to authenticate requests. And we will use it from authentication handler. Inside API MAnager we need to provide following 3 parameters as full qualified class names. Then we will use that class names to create instances when required. So we will add following configuration to key manager section of api-manager configuration file. ExternalKeyManagerConfiguration ApplicationClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO/ApplicationClassName KeyManagerImplemetationClassNameorg.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl/KeyManagerImplemetationClassName KeyValidationHandlerClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator/KeyValidationHandlerClassName Properties NameValue/Name Properties /ExternalKeyManagerConfiguration If external key management server required additional parameters for their implementation we can define those as properties in above configuration. So we may use that to store external server urls and other required parameters etc. Please let us know your feedback and suggestions on this. Based on that we can move forward and implement other required things. Thanks, Sanjeewa. On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias nuw...@wso2.com wrote: Make sure the class name is OAuthApplication, not oAuthApplication. On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena ros...@wso2.com wrote: Hi All, After having few discussions we have decided to change our earlier proposed interface design bit and here I would like to briefly describe newly proposed interfaces and their tasks below. Now we have three interfaces. 1.oAuthApplication 2.KeyManager. 3.KeyValidationHandler. Third party authorization server implementation can write there own custom classes by implementing these interfaces and gain ability to perform below tasks. 1 By implementing oAuthApplication interface Third party authorization server can introduce their own custom attributes when they are creating an application via wso2apimanager. Sample custom attributes for example, scopes,grant_type, response_type,contacts etc.. 2. By implementing KeyManager interface Third party authorization server can create/update/delete/retrieve an oAuthApplication from
Re: [Architecture] API Manager Authorization Server Decoupling
Hi All, Here is a brief update on status of External Key Management server -APIM integration implementation. We will move all External Key Management server related implementation classes outside from impl and other API Manager related code. So once this is completed we need to build this jar and put it to dropins directory and restart server. And they need to add required configuration to configs. IMO we need to begin this implementation with clear separation of external jar file and API Manager implementation. For the moment we will use following package name for this newly added package(if need we can change it in future). org.wso2.carbon.apimgt.ext.keymgt There we will have following package hierarchy . └── 1.0.0 ├── pom.xml └── src └── main └── java └── org └── wso2 └── carbon └── ext.keymgt ├── APIManagerTest.java ├── ExtKeyMgtAppInfoDTO.java ├── ExtKeyMgtAuthenticator.java ├── ExtKeyMgtDao.java └── ExternalKeyManagerImpl.java Here ExternalKeyManagerImpl will be implementation of KeyManager interface. ExtKeyMgtAppInfoDTO will be data level representation of application in External Key Manager side. This should be implemented ApplicationInfo interface. ExtKeyMgtDao will be used to data access required to external key manager. ExtKeyMgtAuthenticator will be used to authenticate requests. And we will use it from authentication handler. Inside API MAnager we need to provide following 3 parameters as full qualified class names. Then we will use that class names to create instances when required. So we will add following configuration to key manager section of api-manager configuration file. ExternalKeyManagerConfiguration ApplicationClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO/ApplicationClassName KeyManagerImplemetationClassNameorg.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl/KeyManagerImplemetationClassName KeyValidationHandlerClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator/KeyValidationHandlerClassName Properties NameValue/Name Properties /ExternalKeyManagerConfiguration If external key management server required additional parameters for their implementation we can define those as properties in above configuration. So we may use that to store external server urls and other required parameters etc. Please let us know your feedback and suggestions on this. Based on that we can move forward and implement other required things. Thanks, Sanjeewa. On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias nuw...@wso2.com wrote: Make sure the class name is OAuthApplication, not oAuthApplication. On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena ros...@wso2.com wrote: Hi All, After having few discussions we have decided to change our earlier proposed interface design bit and here I would like to briefly describe newly proposed interfaces and their tasks below. Now we have three interfaces. 1.oAuthApplication 2.KeyManager. 3.KeyValidationHandler. Third party authorization server implementation can write there own custom classes by implementing these interfaces and gain ability to perform below tasks. 1 By implementing oAuthApplication interface Third party authorization server can introduce their own custom attributes when they are creating an application via wso2apimanager. Sample custom attributes for example, scopes,grant_type, response_type,contacts etc.. 2. By implementing KeyManager interface Third party authorization server can create/update/delete/retrieve an oAuthApplication from their server. Further KeyManager interface will support to retrieve client meta data by reading introspection endpoint. Moreover Third party authorization server implementation can hard-code their custom properties/metadata to a config file and KeyManager interface will provide a method to read that config file and generate corresponding UIs in API manager store according to configurations. 3. Finally,Third party authorization server can validate their tokens/subscriptions/scopes by implementing KeyValidationHandler interface. Regards Roshan. On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva ami...@wso2.com wrote: Hi, *Extension points for token validation* These changes are the planned changes. 1. All the extensions will be done in Key Manager - Earlier it was suggested to allow GW to call directly to a different Authorization Server and use the result returned by that to validate the subscription. After some discussions it seemed that keeping GW intact and changing the validate operation in KM would be much simple. GW will always receive a uniform response irrespective of the Authorization Server used behind. 2 Use validate operation in OAuth2TokenValidationService
Re: [Architecture] API Manager Authorization Server Decoupling
Quick feedback - please do not use DTO in the name: ExtKeyMgtAppInfoDTO Thanks regards, -Prabath On Wed, Oct 15, 2014 at 6:27 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: Hi All, Here is a brief update on status of External Key Management server -APIM integration implementation. We will move all External Key Management server related implementation classes outside from impl and other API Manager related code. So once this is completed we need to build this jar and put it to dropins directory and restart server. And they need to add required configuration to configs. IMO we need to begin this implementation with clear separation of external jar file and API Manager implementation. For the moment we will use following package name for this newly added package(if need we can change it in future). org.wso2.carbon.apimgt.ext.keymgt There we will have following package hierarchy . └── 1.0.0 ├── pom.xml └── src └── main └── java └── org └── wso2 └── carbon └── ext.keymgt ├── APIManagerTest.java ├── ExtKeyMgtAppInfoDTO.java ├── ExtKeyMgtAuthenticator.java ├── ExtKeyMgtDao.java └── ExternalKeyManagerImpl.java Here ExternalKeyManagerImpl will be implementation of KeyManager interface. ExtKeyMgtAppInfoDTO will be data level representation of application in External Key Manager side. This should be implemented ApplicationInfo interface. ExtKeyMgtDao will be used to data access required to external key manager. ExtKeyMgtAuthenticator will be used to authenticate requests. And we will use it from authentication handler. Inside API MAnager we need to provide following 3 parameters as full qualified class names. Then we will use that class names to create instances when required. So we will add following configuration to key manager section of api-manager configuration file. ExternalKeyManagerConfiguration ApplicationClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO/ApplicationClassName KeyManagerImplemetationClassNameorg.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl/KeyManagerImplemetationClassName KeyValidationHandlerClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator/KeyValidationHandlerClassName Properties NameValue/Name Properties /ExternalKeyManagerConfiguration If external key management server required additional parameters for their implementation we can define those as properties in above configuration. So we may use that to store external server urls and other required parameters etc. Please let us know your feedback and suggestions on this. Based on that we can move forward and implement other required things. Thanks, Sanjeewa. On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias nuw...@wso2.com wrote: Make sure the class name is OAuthApplication, not oAuthApplication. On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena ros...@wso2.com wrote: Hi All, After having few discussions we have decided to change our earlier proposed interface design bit and here I would like to briefly describe newly proposed interfaces and their tasks below. Now we have three interfaces. 1.oAuthApplication 2.KeyManager. 3.KeyValidationHandler. Third party authorization server implementation can write there own custom classes by implementing these interfaces and gain ability to perform below tasks. 1 By implementing oAuthApplication interface Third party authorization server can introduce their own custom attributes when they are creating an application via wso2apimanager. Sample custom attributes for example, scopes,grant_type, response_type,contacts etc.. 2. By implementing KeyManager interface Third party authorization server can create/update/delete/retrieve an oAuthApplication from their server. Further KeyManager interface will support to retrieve client meta data by reading introspection endpoint. Moreover Third party authorization server implementation can hard-code their custom properties/metadata to a config file and KeyManager interface will provide a method to read that config file and generate corresponding UIs in API manager store according to configurations. 3. Finally,Third party authorization server can validate their tokens/subscriptions/scopes by implementing KeyValidationHandler interface. Regards Roshan. On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva ami...@wso2.com wrote: Hi, *Extension points for token validation* These changes are the planned changes. 1. All the extensions will be done in Key Manager - Earlier it was suggested to allow GW to call directly to a different Authorization Server and use the result returned by that to validate the subscription. After some discussions it seemed that keeping
Re: [Architecture] API Manager Authorization Server Decoupling
On Wed, Oct 15, 2014 at 6:30 PM, Prabath Siriwardena prab...@wso2.com wrote: Quick feedback - please do not use DTO in the name: ExtKeyMgtAppInfoDTO +1. It was mistake and will remove that. Thanks, sanjeewa. Thanks regards, -Prabath On Wed, Oct 15, 2014 at 6:27 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: Hi All, Here is a brief update on status of External Key Management server -APIM integration implementation. We will move all External Key Management server related implementation classes outside from impl and other API Manager related code. So once this is completed we need to build this jar and put it to dropins directory and restart server. And they need to add required configuration to configs. IMO we need to begin this implementation with clear separation of external jar file and API Manager implementation. For the moment we will use following package name for this newly added package(if need we can change it in future). org.wso2.carbon.apimgt.ext.keymgt There we will have following package hierarchy . └── 1.0.0 ├── pom.xml └── src └── main └── java └── org └── wso2 └── carbon └── ext.keymgt ├── APIManagerTest.java ├── ExtKeyMgtAppInfoDTO.java ├── ExtKeyMgtAuthenticator.java ├── ExtKeyMgtDao.java └── ExternalKeyManagerImpl.java Here ExternalKeyManagerImpl will be implementation of KeyManager interface. ExtKeyMgtAppInfoDTO will be data level representation of application in External Key Manager side. This should be implemented ApplicationInfo interface. ExtKeyMgtDao will be used to data access required to external key manager. ExtKeyMgtAuthenticator will be used to authenticate requests. And we will use it from authentication handler. Inside API MAnager we need to provide following 3 parameters as full qualified class names. Then we will use that class names to create instances when required. So we will add following configuration to key manager section of api-manager configuration file. ExternalKeyManagerConfiguration ApplicationClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO/ApplicationClassName KeyManagerImplemetationClassNameorg.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl/KeyManagerImplemetationClassName KeyValidationHandlerClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator/KeyValidationHandlerClassName Properties NameValue/Name Properties /ExternalKeyManagerConfiguration If external key management server required additional parameters for their implementation we can define those as properties in above configuration. So we may use that to store external server urls and other required parameters etc. Please let us know your feedback and suggestions on this. Based on that we can move forward and implement other required things. Thanks, Sanjeewa. On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias nuw...@wso2.com wrote: Make sure the class name is OAuthApplication, not oAuthApplication. On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena ros...@wso2.com wrote: Hi All, After having few discussions we have decided to change our earlier proposed interface design bit and here I would like to briefly describe newly proposed interfaces and their tasks below. Now we have three interfaces. 1.oAuthApplication 2.KeyManager. 3.KeyValidationHandler. Third party authorization server implementation can write there own custom classes by implementing these interfaces and gain ability to perform below tasks. 1 By implementing oAuthApplication interface Third party authorization server can introduce their own custom attributes when they are creating an application via wso2apimanager. Sample custom attributes for example, scopes,grant_type, response_type,contacts etc.. 2. By implementing KeyManager interface Third party authorization server can create/update/delete/retrieve an oAuthApplication from their server. Further KeyManager interface will support to retrieve client meta data by reading introspection endpoint. Moreover Third party authorization server implementation can hard-code their custom properties/metadata to a config file and KeyManager interface will provide a method to read that config file and generate corresponding UIs in API manager store according to configurations. 3. Finally,Third party authorization server can validate their tokens/subscriptions/scopes by implementing KeyValidationHandler interface. Regards Roshan. On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva ami...@wso2.com wrote: Hi, *Extension points for token validation* These changes are the planned changes. 1. All the extensions will be done in Key Manager - Earlier it was suggested to allow GW to call directly to
Re: [Architecture] API Manager Authorization Server Decoupling
Hi Sanjeewa, Why do we need an ApplicationClassName? I assume this is to provide an Abstraction for different Applications (or clients ) created from an External Authorization Server. If this is the case, do we really need to Abstract that out ? If I understood it correctly , we discussed about having one AppInfo object to represent an Application, which will have one or two common fields (like Consumer Key and Key Type) and then a Map to hold all the other Authorization Server specific fields . On Wed, Oct 15, 2014 at 5:57 AM, Sanjeewa Malalgoda sanje...@wso2.com wrote: Hi All, Here is a brief update on status of External Key Management server -APIM integration implementation. We will move all External Key Management server related implementation classes outside from impl and other API Manager related code. So once this is completed we need to build this jar and put it to dropins directory and restart server. And they need to add required configuration to configs. IMO we need to begin this implementation with clear separation of external jar file and API Manager implementation. For the moment we will use following package name for this newly added package(if need we can change it in future). org.wso2.carbon.apimgt.ext.keymgt There we will have following package hierarchy . └── 1.0.0 ├── pom.xml └── src └── main └── java └── org └── wso2 └── carbon └── ext.keymgt ├── APIManagerTest.java ├── ExtKeyMgtAppInfoDTO.java ├── ExtKeyMgtAuthenticator.java ├── ExtKeyMgtDao.java └── ExternalKeyManagerImpl.java Here ExternalKeyManagerImpl will be implementation of KeyManager interface. ExtKeyMgtAppInfoDTO will be data level representation of application in External Key Manager side. This should be implemented ApplicationInfo interface. ExtKeyMgtDao will be used to data access required to external key manager. ExtKeyMgtAuthenticator will be used to authenticate requests. And we will use it from authentication handler. Inside API MAnager we need to provide following 3 parameters as full qualified class names. Then we will use that class names to create instances when required. So we will add following configuration to key manager section of api-manager configuration file. ExternalKeyManagerConfiguration ApplicationClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO/ApplicationClassName KeyManagerImplemetationClassNameorg.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl/KeyManagerImplemetationClassName KeyValidationHandlerClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator/KeyValidationHandlerClassName Properties NameValue/Name Properties /ExternalKeyManagerConfiguration If external key management server required additional parameters for their implementation we can define those as properties in above configuration. So we may use that to store external server urls and other required parameters etc. Please let us know your feedback and suggestions on this. Based on that we can move forward and implement other required things. Thanks, Sanjeewa. On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias nuw...@wso2.com wrote: Make sure the class name is OAuthApplication, not oAuthApplication. On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena ros...@wso2.com wrote: Hi All, After having few discussions we have decided to change our earlier proposed interface design bit and here I would like to briefly describe newly proposed interfaces and their tasks below. Now we have three interfaces. 1.oAuthApplication 2.KeyManager. 3.KeyValidationHandler. Third party authorization server implementation can write there own custom classes by implementing these interfaces and gain ability to perform below tasks. 1 By implementing oAuthApplication interface Third party authorization server can introduce their own custom attributes when they are creating an application via wso2apimanager. Sample custom attributes for example, scopes,grant_type, response_type,contacts etc.. 2. By implementing KeyManager interface Third party authorization server can create/update/delete/retrieve an oAuthApplication from their server. Further KeyManager interface will support to retrieve client meta data by reading introspection endpoint. Moreover Third party authorization server implementation can hard-code their custom properties/metadata to a config file and KeyManager interface will provide a method to read that config file and generate corresponding UIs in API manager store according to configurations. 3. Finally,Third party authorization server can validate their tokens/subscriptions/scopes by implementing KeyValidationHandler interface. Regards Roshan. On Thu, Sep 4,
Re: [Architecture] API Manager Authorization Server Decoupling
I don't think we should be using the term 'External' or 'Ext' anywhere in the configuration. It should just be 'KeyManager' (or similar) and default value should be the implementation class names that are shipped with the product OOTB. On Wed, Oct 15, 2014 at 7:36 PM, Amila De Silva ami...@wso2.com wrote: Hi Sanjeewa, Why do we need an ApplicationClassName? I assume this is to provide an Abstraction for different Applications (or clients ) created from an External Authorization Server. If this is the case, do we really need to Abstract that out ? If I understood it correctly , we discussed about having one AppInfo object to represent an Application, which will have one or two common fields (like Consumer Key and Key Type) and then a Map to hold all the other Authorization Server specific fields . On Wed, Oct 15, 2014 at 5:57 AM, Sanjeewa Malalgoda sanje...@wso2.com wrote: Hi All, Here is a brief update on status of External Key Management server -APIM integration implementation. We will move all External Key Management server related implementation classes outside from impl and other API Manager related code. So once this is completed we need to build this jar and put it to dropins directory and restart server. And they need to add required configuration to configs. IMO we need to begin this implementation with clear separation of external jar file and API Manager implementation. For the moment we will use following package name for this newly added package(if need we can change it in future). org.wso2.carbon.apimgt.ext.keymgt There we will have following package hierarchy . └── 1.0.0 ├── pom.xml └── src └── main └── java └── org └── wso2 └── carbon └── ext.keymgt ├── APIManagerTest.java ├── ExtKeyMgtAppInfoDTO.java ├── ExtKeyMgtAuthenticator.java ├── ExtKeyMgtDao.java └── ExternalKeyManagerImpl.java Here ExternalKeyManagerImpl will be implementation of KeyManager interface. ExtKeyMgtAppInfoDTO will be data level representation of application in External Key Manager side. This should be implemented ApplicationInfo interface. ExtKeyMgtDao will be used to data access required to external key manager. ExtKeyMgtAuthenticator will be used to authenticate requests. And we will use it from authentication handler. Inside API MAnager we need to provide following 3 parameters as full qualified class names. Then we will use that class names to create instances when required. So we will add following configuration to key manager section of api-manager configuration file. ExternalKeyManagerConfiguration ApplicationClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO/ApplicationClassName KeyManagerImplemetationClassNameorg.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl/KeyManagerImplemetationClassName KeyValidationHandlerClassNameorg.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator/KeyValidationHandlerClassName Properties NameValue/Name Properties /ExternalKeyManagerConfiguration If external key management server required additional parameters for their implementation we can define those as properties in above configuration. So we may use that to store external server urls and other required parameters etc. Please let us know your feedback and suggestions on this. Based on that we can move forward and implement other required things. Thanks, Sanjeewa. On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias nuw...@wso2.com wrote: Make sure the class name is OAuthApplication, not oAuthApplication. On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena ros...@wso2.com wrote: Hi All, After having few discussions we have decided to change our earlier proposed interface design bit and here I would like to briefly describe newly proposed interfaces and their tasks below. Now we have three interfaces. 1.oAuthApplication 2.KeyManager. 3.KeyValidationHandler. Third party authorization server implementation can write there own custom classes by implementing these interfaces and gain ability to perform below tasks. 1 By implementing oAuthApplication interface Third party authorization server can introduce their own custom attributes when they are creating an application via wso2apimanager. Sample custom attributes for example, scopes,grant_type, response_type,contacts etc.. 2. By implementing KeyManager interface Third party authorization server can create/update/delete/retrieve an oAuthApplication from their server. Further KeyManager interface will support to retrieve client meta data by reading introspection endpoint. Moreover Third party authorization server implementation can hard-code their custom properties/metadata to a config file and KeyManager
Re: [Architecture] API Manager Authorization Server Decoupling
Hi All, After having few discussions we have decided to change our earlier proposed interface design bit and here I would like to briefly describe newly proposed interfaces and their tasks below. Now we have three interfaces. 1.oAuthApplication 2.KeyManager. 3.KeyValidationHandler. Third party authorization server implementation can write there own custom classes by implementing these interfaces and gain ability to perform below tasks. 1 By implementing oAuthApplication interface Third party authorization server can introduce their own custom attributes when they are creating an application via wso2apimanager. Sample custom attributes for example, scopes,grant_type, response_type,contacts etc.. 2. By implementing KeyManager interface Third party authorization server can create/update/delete/retrieve an oAuthApplication from their server. Further KeyManager interface will support to retrieve client meta data by reading introspection endpoint. Moreover Third party authorization server implementation can hard-code their custom properties/metadata to a config file and KeyManager interface will provide a method to read that config file and generate corresponding UIs in API manager store according to configurations. 3. Finally,Third party authorization server can validate their tokens/subscriptions/scopes by implementing KeyValidationHandler interface. Regards Roshan. On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva ami...@wso2.com wrote: Hi, *Extension points for token validation* These changes are the planned changes. 1. All the extensions will be done in Key Manager - Earlier it was suggested to allow GW to call directly to a different Authorization Server and use the result returned by that to validate the subscription. After some discussions it seemed that keeping GW intact and changing the validate operation in KM would be much simple. GW will always receive a uniform response irrespective of the Authorization Server used behind. 2 Use validate operation in OAuth2TokenValidationService instead of using APIKeyValidationService. - Behaviour of the validate operation of can be changed by providing a custom handler. We can put the current validate method in the default implementation,without any changes. One expected benefit of using OAuth2TokenValidationService is, eliminating the need to install Key Manager features on IS, when using IS as an Authorization Server. But the suggested change alone would not make it possible, since GW calls getAllURITemplates operation, which is only available in APIKeyValidationService, to get the Authentication Scheme of a resource. -- Roshan Wijesena. Senior Software Engineer-WSO2 Inc. Mobile: *+94752126789* Email: ros...@wso2.com *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] API Manager Authorization Server Decoupling
Make sure the class name is OAuthApplication, not oAuthApplication. On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena ros...@wso2.com wrote: Hi All, After having few discussions we have decided to change our earlier proposed interface design bit and here I would like to briefly describe newly proposed interfaces and their tasks below. Now we have three interfaces. 1.oAuthApplication 2.KeyManager. 3.KeyValidationHandler. Third party authorization server implementation can write there own custom classes by implementing these interfaces and gain ability to perform below tasks. 1 By implementing oAuthApplication interface Third party authorization server can introduce their own custom attributes when they are creating an application via wso2apimanager. Sample custom attributes for example, scopes,grant_type, response_type,contacts etc.. 2. By implementing KeyManager interface Third party authorization server can create/update/delete/retrieve an oAuthApplication from their server. Further KeyManager interface will support to retrieve client meta data by reading introspection endpoint. Moreover Third party authorization server implementation can hard-code their custom properties/metadata to a config file and KeyManager interface will provide a method to read that config file and generate corresponding UIs in API manager store according to configurations. 3. Finally,Third party authorization server can validate their tokens/subscriptions/scopes by implementing KeyValidationHandler interface. Regards Roshan. On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva ami...@wso2.com wrote: Hi, *Extension points for token validation* These changes are the planned changes. 1. All the extensions will be done in Key Manager - Earlier it was suggested to allow GW to call directly to a different Authorization Server and use the result returned by that to validate the subscription. After some discussions it seemed that keeping GW intact and changing the validate operation in KM would be much simple. GW will always receive a uniform response irrespective of the Authorization Server used behind. 2 Use validate operation in OAuth2TokenValidationService instead of using APIKeyValidationService. - Behaviour of the validate operation of can be changed by providing a custom handler. We can put the current validate method in the default implementation,without any changes. One expected benefit of using OAuth2TokenValidationService is, eliminating the need to install Key Manager features on IS, when using IS as an Authorization Server. But the suggested change alone would not make it possible, since GW calls getAllURITemplates operation, which is only available in APIKeyValidationService, to get the Authentication Scheme of a resource. -- Roshan Wijesena. Senior Software Engineer-WSO2 Inc. Mobile: *+94752126789* Email: ros...@wso2.com *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] API Manager Authorization Server Decoupling
Hi Sanjeewa On Thu, Sep 4, 2014 at 10:29 AM, Sanjeewa Malalgoda sanje...@wso2.com wrote: Hi Amila, This is very valid use case and thanks for bring this up. Please find comments inline. On Mon, Sep 1, 2014 at 9:30 AM, Amila De Silva ami...@wso2.com wrote: Hi, Currently a development is going onto decouple Authorization Server from API Manager. In the existing design, creating Applications, generating validating Tokens are done through non-standard interfaces and these operations are tightly coupled with the Key Manager ,which is the default Authorization Server in a typical API Manager Deployment. The ongoing effort is to identify such tightly coupled areas and provide extension points for them, allowing an external Authorization Server to issue and validate Access Tokens. There are 2 major Tasks involved in this. 1. Changing the way Applications are registered on the Store – An Application created in Store can have two types of Keys PRODUCTION and SANDBOX. When a user clicks on the Generate button, a. An Oauth app is created with the given key type b. An Application Access token is Generated When creating the OAuth app entries get written to IDN_CONSUMER_APPS and AM_APPLICATION_KEY_MAPPING tables. Access Token is generated by creating an entry in IDN_OAUTH2_ACCESS_TOKEN table. By providing the capability to plug-in a custom implementation for an Oauth app, users will be able to store/create Oauth Apps in their own Authorization Server, eliminating the need to keep Access Tokens in AM Tables. In this case do we still need to maintain apps inside API Manager. Applications, subscriptions and tokens are tightly coupled and inter related. So how do we plan decouple these? First we might need to identify the roles and tasks of authorization server. Following are required IMO Create, update and maintains applications. The Application created in the Store (let's refer to this as the AM Application) , doesn't get changed by these. Subscriptions are maintained against an AM Application, therefore, we don't need to change the way subscriptions are stored. The OAuth Application being discussed here, is an abstract representation of an OAuth 2.0 client. It is for an OAuth Application we obtain an Application Access Token for. When you generate a key under the AM Application (say a Production key), a. First an OAuth Application is created (Consumer Key and Consumer Secret belongs to that particular OAuth App) b. And then a Token is generated. Instead of creating the OAuth App in the APIM, users can choose to create them in an external Authorization Server. We can use the Consumer Key issued by the Authorization Server to keep the mapping between the AM Application and the OAuth Application. When implementing OAuthApplication interface, developers have to determine where they are going to keep the App, and how they are going to retrieve it. It should be possible to retrieve an OAuthApplication by the consumer key. Maintains subscriptions. Generate tokens and manage them. In the case of an External Authorization server, generating/managing tokens will not be handled by APIM. Handle token validation, verification. Yes, the capability should be given to plug in a custom handler to do the Token Validation. So from API Manager side we can provide interface to access authorization server. Are we planning to create interface and decouple current implementation as authorization server? Or are we going to consider external common authorization server pluggability ? We are going to do both. We have to decouple the current implementation and also we have to make sure that the interfaces we provide contain all the necessary methods needed to plug in an external Authorization Server. Thought it would be better to explain certain terms clearly, hence the long description :) Thanks, sanjeewa. 2. Changes on Token Validation During an API Invocation, GW calls the KM to get the Key Validated. During the validation a. Token is checked for it's Validity- whether it is Active or not b. Subscription gets validated - If the API being invoked is subscribed by the Application that obtained the token. c. A JWT is generated using the default claims and the custom claims user has provided. As of now, all of these operations are performed by APIKeyValidationService running in KM. There can be scenarios where user needs to delegate , token validation to a different Authorization Server. To use in such scenarios, a service needs to be provided in KM, which only checks the state of the subscription. APIAuthenticationHandler which is responsible for calling KM and getting the token validated needs to be modified to call an external service/endpoint and fetch details(such as consumer key) about the client that obtained the token. Details about the design and the tasks will be provided in the mails to follow. -- *Amila De Silva* WSO2 Inc.
Re: [Architecture] API Manager Authorization Server Decoupling
Hi Amila, This is very valid use case and thanks for bring this up. Please find comments inline. On Mon, Sep 1, 2014 at 9:30 AM, Amila De Silva ami...@wso2.com wrote: Hi, Currently a development is going onto decouple Authorization Server from API Manager. In the existing design, creating Applications, generating validating Tokens are done through non-standard interfaces and these operations are tightly coupled with the Key Manager ,which is the default Authorization Server in a typical API Manager Deployment. The ongoing effort is to identify such tightly coupled areas and provide extension points for them, allowing an external Authorization Server to issue and validate Access Tokens. There are 2 major Tasks involved in this. 1. Changing the way Applications are registered on the Store – An Application created in Store can have two types of Keys PRODUCTION and SANDBOX. When a user clicks on the Generate button, a. An Oauth app is created with the given key type b. An Application Access token is Generated When creating the OAuth app entries get written to IDN_CONSUMER_APPS and AM_APPLICATION_KEY_MAPPING tables. Access Token is generated by creating an entry in IDN_OAUTH2_ACCESS_TOKEN table. By providing the capability to plug-in a custom implementation for an Oauth app, users will be able to store/create Oauth Apps in their own Authorization Server, eliminating the need to keep Access Tokens in AM Tables. In this case do we still need to maintain apps inside API Manager. Applications, subscriptions and tokens are tightly coupled and inter related. So how do we plan decouple these? First we might need to identify the roles and tasks of authorization server. Following are required IMO Create, update and maintains applications. Maintains subscriptions. Generate tokens and manage them. Handle token validation, verification. So from API Manager side we can provide interface to access authorization server. Are we planning to create interface and decouple current implementation as authorization server? Or are we going to consider external common authorization server pluggability ? Thanks, sanjeewa. 2. Changes on Token Validation During an API Invocation, GW calls the KM to get the Key Validated. During the validation a. Token is checked for it's Validity- whether it is Active or not b. Subscription gets validated - If the API being invoked is subscribed by the Application that obtained the token. c. A JWT is generated using the default claims and the custom claims user has provided. As of now, all of these operations are performed by APIKeyValidationService running in KM. There can be scenarios where user needs to delegate , token validation to a different Authorization Server. To use in such scenarios, a service needs to be provided in KM, which only checks the state of the subscription. APIAuthenticationHandler which is responsible for calling KM and getting the token validated needs to be modified to call an external service/endpoint and fetch details(such as consumer key) about the client that obtained the token. Details about the design and the tasks will be provided in the mails to follow. -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 http://sanjeewamalalgoda.blogspot.com/blog :http://sanjeewamalalgoda.blogspot.com/ http://sanjeewamalalgoda.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] API Manager Authorization Server Decoupling
Hi, Currently a development is going onto decouple Authorization Server from API Manager. In the existing design, creating Applications, generating validating Tokens are done through non-standard interfaces and these operations are tightly coupled with the Key Manager ,which is the default Authorization Server in a typical API Manager Deployment. The ongoing effort is to identify such tightly coupled areas and provide extension points for them, allowing an external Authorization Server to issue and validate Access Tokens. There are 2 major Tasks involved in this. 1. Changing the way Applications are registered on the Store – An Application created in Store can have two types of Keys PRODUCTION and SANDBOX. When a user clicks on the Generate button, a. An Oauth app is created with the given key type b. An Application Access token is Generated When creating the OAuth app entries get written to IDN_CONSUMER_APPS and AM_APPLICATION_KEY_MAPPING tables. Access Token is generated by creating an entry in IDN_OAUTH2_ACCESS_TOKEN table. By providing the capability to plug-in a custom implementation for an Oauth app, users will be able to store/create Oauth Apps in their own Authorization Server, eliminating the need to keep Access Tokens in AM Tables. 2. Changes on Token Validation During an API Invocation, GW calls the KM to get the Key Validated. During the validation a. Token is checked for it's Validity- whether it is Active or not b. Subscription gets validated - If the API being invoked is subscribed by the Application that obtained the token. c. A JWT is generated using the default claims and the custom claims user has provided. As of now, all of these operations are performed by APIKeyValidationService running in KM. There can be scenarios where user needs to delegate , token validation to a different Authorization Server. To use in such scenarios, a service needs to be provided in KM, which only checks the state of the subscription. APIAuthenticationHandler which is responsible for calling KM and getting the token validated needs to be modified to call an external service/endpoint and fetch details(such as consumer key) about the client that obtained the token. Details about the design and the tasks will be provided in the mails to follow. -- *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] API Manager Authorization Server Decoupling
On Mon, Sep 1, 2014 at 10:00 PM, Amila De Silva ami...@wso2.com wrote: Hi, Currently a development is going onto decouple Authorization Server from API Manager. In the existing design, creating Applications, generating validating Tokens are done through non-standard interfaces and these operations are tightly coupled with the Key Manager ,which is the default Authorization Server in a typical API Manager Deployment. The ongoing effort is to identify such tightly coupled areas and provide extension points for them, allowing an external Authorization Server to issue and validate Access Tokens. There are 2 major Tasks involved in this. 1. Changing the way Applications are registered on the Store – An Application created in Store can have two types of Keys PRODUCTION and SANDBOX. When a user clicks on the Generate button, a. An Oauth app is created with the given key type b. An Application Access token is Generated When creating the OAuth app entries get written to IDN_CONSUMER_APPS and AM_APPLICATION_KEY_MAPPING tables. Access Token is generated by creating an entry in IDN_OAUTH2_ACCESS_TOKEN table. By providing the capability to plug-in a custom implementation for an Oauth app, users will be able to store/create Oauth Apps in their own Authorization Server, eliminating the need to keep Access Tokens in AM Tables. 2. Changes on Token Validation During an API Invocation, GW calls the KM to get the Key Validated. During the validation a. Token is checked for it's Validity- whether it is Active or not b. Subscription gets validated - If the API being invoked is subscribed by the Application that obtained the token. c. A JWT is generated using the default claims and the custom claims user has provided. As of now, all of these operations are performed by APIKeyValidationService running in KM. There can be scenarios where user needs to delegate , token validation to a different Authorization Server. To use in such scenarios, a service needs to be provided in KM, which only checks the state of the subscription. Its better if we can provide this as an extension mechanism so that we can extend the logic if necessary. We also need to think to how to handle the JWT scenario (including signatures). Currently its the Key Manager who creates the JWT entirely. But moving forward, its another server that validates the token and the KM which validates the subscription, etc. Therefore will the JWT creation be a shared responsibility between the two? If so, who should be signing the JWT now? APIAuthenticationHandler which is responsible for calling KM and getting the token validated needs to be modified to call an external service/endpoint and fetch details(such as consumer key) about the client that obtained the token. Details about the design and the tasks will be provided in the mails to follow. -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
