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
