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
