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. >> 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 > > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
