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> >> >> <ApplicationClassName>org.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO</ApplicationClassName> >> >> <KeyManagerImplemetationClassName>org.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl</KeyManagerImplemetationClassName> >> >> <KeyValidationHandlerClassName>org.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator</KeyValidationHandlerClassName> >> <Properties> >> <Name>Value</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 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 >>> >> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > *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
