WSO2 API Manager End-User Custom Authentication Policy using Local Database

Question

For a web-application portal, which is accessed via internet through web-browser, there is a requirement to implement the following authentication flow within the WSO2 API manager.

• End Users of Application (Portal-Web Thin client) must login using a user/password scheme.
• The user & credential information are stored in a local application RDBMS database (eg- MySQL).
• Application has user management screens to add/delete/update users and map roles.
• API manager must authenticate the user against the local user store and generate a JWT/Ouath2 token.
• There are custom password policies to be configured (for eg, user must be locked after 5 failure try).
• End user will use the generated token to access the protected API.
• API Manager should authorize the token and route the API to the appropriate micro service.

From the documentation we found that, a secondary user store shall be created to allow the end users of the application to be part of WSO2 API Manager users, and hence the authentication will be taken care by API manager itself. I would like to get a better understanding on how this can be implemented.

1. Changes expected in end-user database is very dynamic via user management screens in the application, does this need to be updated to API manager user store in some manner? Or can the API manager user store can be configured directly read from applicable users table.?
2. Can API manager performs the encrypted password validation, configured in application DB against each user?
3. Is there any alternate approach, for eg, my application expose a rest end-point for authentication, and the API manager invokes this end-point to perform the authentication by passing the username and password received as part of token api.?

Answer 1

You can plug the Application's User store as a secondary in the API Manager and achieve your requirement. Refer to the official documentation on configuring a Secondary User-store for more detail.

Further, if you are having a JDBC User store, then you can either customize the queries of the secondary user-store in the API Manager to query the user entries correctly. In addition, you can also implement a custom User-store manager and plug (if you are having more customized fields and operations).

Answering your questions

Changes expected in the end-user database are very dynamic via user management screens in the application, does this need to be updated to API manager user store in some manner? Or can the API manager user store can be configured directly read from the applicable user's table?

No, it is not required to perform any manual changes in the API Manager unless if you haven't configured the User-stores properly. However, be in note, that if you are planning to use the user's from your application user-store to create APIs and subscribe in the API platform, deletion of those users can cause inconsistent behaviors in the platform.

Can API manager performs the encrypted password validation, configured in application DB against each user?

You can write a custom User-store manager to handle the password validation as you like.

Is there any alternate approach, for eg, my application expose a rest end-point for authentication, and the API manager invokes this end-point to perform the authentication by passing the username and password received as part of token API.?

I can think of one alternate with the REST API approach. Which is to develop a custom Handler and engage it with APIs to perform the validation in addition to Token validation. In brief,

• Develop a Synapse Handler
• Engage the Handler with the APIs along with the default APIAuthenticationHandler
• Read and extract the username and password from the Transport header in the custom handler
• Call the application's REST endpoint and check the validity
• If successful, continue with the API invocation (continuing with the usual token validation process and all), if not, drop and respond back with an error

But, please note that this external validation process needs to be fast enough to not to block the API Manager for a longer period.