Hi All,
Objective of this mail is to highlight the changes that needs to be done in
server profiles and in configuration files while implementing this feature.
As of now when Gateway receives a request, it talks to a server which
performs the following operations;
1. Get details of the access token by querying the Database.
2. Check the validity of the token.
3. Check if the user is subscribed to the API.
4. Check if the token has necessary scopes to access the resource.
5. Generate JWT using details derived from the token.
In this design, the server to which GW calls is the same entity which
manages tokens. So calling this entity as Key Manager suits in this
scenario.
After decoupling the Authorization server, the server to which GW calls,
will not be the same entity that manages tokens. To make this distinction
clear, a new profile will be introduced (which we'll refer to as Key
Validator for now). Basically GW calls to Key Validator which performs all
the above operations except 1st and 2nd. To complete its validation, Key
Validator obtains token details by calling to a Key Manager (Authorization
Server) - which can either be the one shipped with APIM or else a third
party one.
1st Diagram illustrates the interaction between server profiles we
currently have and the second diagram shows the interactions after adding
the new profile.
Boxes in the diagram represent the profiles, not the server instances in a
deployment. When using the inbuilt KM, a typical deployment will have
KeyValidator and KeyManager profiles in the same JVM. All the server roles
except Gateway, will have to know about Key Manager.
These are the changes happening in configuration files;
1. Key-Manager section in api-manager.xml will be changed as Key-Validator
a. TokenEndPointName and RevokeAPIURL elements will be removed from
Key-Validator section.
b. Two new elements ApplicationTokenScope &
KeyValidationHandlerClassName will be introduced.
2. A new config named key-manager.xml will be introduced.
Purpose of having this file is to provide a single location to keep all the
settings, configs used by a KeyManager implementation.
This is the structure of the key-manager.xml to be shipped with APIM by
default.
<KeyManager class="org.wso2.carbon.apimgt.keymgt.AMDefaultKeyManagerImpl"
xmlns="http://wso2.org/projects/apimgt/key-manager.xml";>
<Configuration>
<AuthorizationServerURL>https://localhost:9443/services/
</AuthorizationServerURL>
<TokenURL>https://localhost:8243/token</TokenURL>
<RevokeURL>https://localhost:8243/revoke</RevokeURL>
</Configuration>
</KeyManager>
Since generating/revoking tokens are done by the class implementing
KeyManager interface, those urls have been moved in to this config.
Contents inside the <Configuration> block can change based on the
implementing class. For example, when plugging in an third party Key
Manager (Authorization Server), introspect endpoint might have to be
provided.
Please share your thoughts.
--
*Amila De Silva*
WSO2 Inc.
mobile :(+94) 775119302
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
