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

Reply via email to