This configuration is suitable when client applications want to access resources on legacy web applications.
For example, an enterprise acme.com has a multi-tier application: a front-end web application utilizing services from web service layers. The enterprise wants to protect these services and applications using OAuth and thereby need to place the RESTful API endpoints behind Access Gateway. The applications need to be modified to fetch OAuth token from Identity server. To minimize this change, Access Manager has the ability to enable Access Gateway to fetch OAuth tokens on behalf of the application and pass it over to the application via HTTP header. Now, the application can simply take the token from the header and use it to invoke the web service.
Figure 5-21 Work flow
A client application requests access to a web resource and provides authentication details to Identity Server.
Identity Server authenticates the client application, gets the user’s consent, generates an OAuth token, and sends the token to the client application.
The client application provides the token to Access Gateway.
Access Gateway sends the token to Identity Server for validation.
If the token is not valid, Access Gateway returns a 401 error.
If the token is valid, Access Gateway performs the following tasks:
Executes the authorization policy, if configured, based on OAuth scopes or claims.
Sends user attributes and grants details provided to the client application to the web application by using the Identity Injection policy, if configured.
The resource server returns a response to Access Gateway and Access Gateway sends this response to the client application.