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. 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