Authentication Service Framework for REST API clients
Optimize the Authentication Service Framework for REST API clients. The optimization uses low-level technical configuration options supported by the web reverse proxy and Advanced Access Control. The Authentication Service Framework within the Security Verify Access Advanced Access Module provides policy based strong and second factor authentication features and functions. The framework is exposed through two runtime endpoints.
- Browser endpoint "/mga/sps/authsvc"
- Configured by default and is optimized for traditional browser-based access and flows. This endpoint responds to clients with HTML and uses browser features such as 302 redirect.
- REST API endpoint "/mga/sps/apiauthsvc"
- Configured by default and is targeted to support non-browser REST API clients such as portals and native mobile applications. This endpoint responds to clients with JSON data.
The Authentication Service supports direct invocation and Context Based Authorization (CBA) triggered invocation use cases. In the direct invocation case, a REST client issues an HTTP GET of the form "POST /mga/sps/apiauthsvc?PolicyId=<policy urn>", which initiates the authentication policy workflow. Single and multi mechanism policies can be invoked. The responses from this endpoint guide the client through the workflow policy steps. However, in most cases, the client is still required to track JSESSION and PD_* cookies.
The authentication policy can be invoked in one of two ways depending on the advanced configuration setting sps.authService.policyKickoffMethod. When this setting is set to 'query' or 'both', policy can be invoked by the following method:
When set to 'path' or 'both', policy can be invoked by the following method:
- /mga/sps/apiauthsvc?PolicyId=urn:ibm:security:authentication:asf:totp
- /mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:totp
- /mga/sps/apiauthsvc/policy/totp
- /mga/sps/authsvc/policy/totp
When the policy runs from the URL paths (/policy/), it cycles the StateId at the end of the policyID. For example, /mga/sps/apiauthsvc/policy/totp?StateId=cf845efa-52d0-4296-a524-9028acba4108.
For the CBA triggered case, a REST client attempts to access a protected resource. This resource is protected by a CBA policy resource attachment. The policy includes an authentication obligation. When triggered, the CBA engine, supported by default configuration of WebSEAL/PEP, responds to the client with a 302 redirect URL of the form "GET /mga/sps/authsvc?TransactionId= <trx ID>". This endpoint is the browser endpoint and not the REST endpoint. The key issues and limitations associated with this use case include:
- Default configuration redirects to the browser-based /authsvc endpoint. Further this endpoint never responds with JSON formatted data.
- 302 redirects place extra processing burden on REST client implementations.
- CBA requires a session.
- Separate REST API channel access
- Use request parameters as input to authentication mechanisms
- OAuth Authentication and Reverse Proxy managed cookies to maintain session and state
- Reverse proxy local redirects and /apiauthsvc obligations url mappings for context-based access
- Example combining CBA, Authentication Service Framework, and OAuth
Parent topic: Developing