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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
