Transaction flow

In a typical context-based transaction, the user requests access to a protected resource. Context-based access calculates the risk score and determines whether access is permitted, denied, or permitted with an obligation. In the following example of a context-based access transaction, the risk score indicates the user must be presented with a challenge. The user successfully completes the challenge and receives permission to access the protected resource.

The following process explains the flow of the transaction in the example scenario:

1. The user interacts through a web browser to submit authentication information and requests access to a protected resource. The protected resource is a junctioned web application that WebSEAL protects.

2. WebSEAL inspects the request.

   WebSEAL is the reverse proxy server that interacts with all transactions. For the protected resource the user requests, the WebSEAL policy (POP) is configured to call the runtime security services External Authorization Service (EAS) plug-in to authorize the request. The EAS is a shared library plug-in, internal to the WebSEAL process, so there is no on-the-wire callout between WebSEAL and the EAS.

3. The EAS first checks the local ISAM policy.

   1. If the ISAM policy denies access, then the EAS returns the response and does not continue with a forbidden response.

   2. If the ISAM policy permits access, the EAS collects the context information about the user and the request. The WebSEAL azn-decision-info stanza has the specifications to create an XACML over SOAP authorization decision request.

   3. The EAS sends the request to the context-based access runtime authorization service for the authorization decision.

4. The runtime authorization service (PDP) runs the configured policy and calls the appropriate PIPs based on the current policy.

   1. If a risk score policy attribute is requested, then the risk engine is called.

   2. The risk engine takes the context details, requests additional policy attributes, if required, and then calculates a risk score.

   3. The authorization service applies the risk score policy attribute against the authorization policy and returns an appropriate decision response to the runtime security services EAS.

   4. The EAS supports three decision types: permit, deny, and permit with obligation. In this example, a decision to permit with obligation is returned.

      • If the policy decision is a simple permit or deny, the decision is mapped to the WebSEAL permit and not_permit decisions. The WebSEAL decisions are returned from the azn_svc_decision_access_allowed_ext call.

      • If the response is to permit access, WebSEAL permits the request to continue to the requested resource.

      • If the response is to deny access, WebSEAL displays an error page, which indicates that access is forbidden.

5. The runtime security services EAS parses the response and returns one of the following EAS responses to WebSEAL:
   • Permit
   • Deny
   • Step-up authentication levels
   • Browser redirect to a location configured on the WebSEAL configuration file

   In this example, the response is a redirect to a location on the appliance runtime, so that WebSEAL can enforce the appropriate authentication challenge.

   The context-based access EAS also provides a configuration to map the returned obligation to a specific WebSEAL external authentication interface (EAI) mechanism. The EAI can be either a WebSEAL EAI or CDAS external authentication mechanism, which the customer or IBM Business Partner can implement.

6. WebSEAL specifies the appropriate authentication mechanism to the user.

7. The user is redirected to the authentication mechanism, which builds a challenge response.

8. The challenge response is presented to the user.

9. The user responds to the challenge.

10. If the response of the user to the challenge request is successful, the challenge is processed. The EAI application returns the credentials of the user and a successful step-up level in the HTTP response to WebSEAL.

11. WebSEAL updates the session of the user with the new credential details the EAI application provides and redirects the user to the protected resource.

12. The request from the user to access the protected resource is sent via 302 redirect. The request does not require any user interaction.

13. WebSEAL inspects the request and directs the request to the runtime security services EAS for authorization.

14. The EAS collects all context information about the user and the request and creates an XACML over SOAP decision request. The EAS sends the request to the runtime authorization service.

15. The context-based access runtime service takes the context and other policy attributes and calculates a risk score. The runtime service applies the risk score against the configured authorization policy and returns a policy decision response to permit access.

16. The runtime security services EAS interprets the response and returns the permit decision to WebSEAL.

17. WebSEAL permits the original request to continue without going back to the web browser of the user. The user is not aware of the transaction process.

Parent topic: Overview of context-based access