IBM Security Verify

 View Only

IBM Security Access Manager: Stateless Operation of the Authentication Service

By Lachlan James Gleeson posted Wed April 08, 2020 06:49 PM

  

IAM.jpg

The authentication service is a part of the Advanced Access Control module and is a powerful and flexible way to authenticate users in either a first factor or step-up scenario. This post will cover the basics of setting up the authentication service as well as a advanced configuration options to facilitate hardening and horizontal scaling in high availability deployments.

Before you start:

You will need:

  • An activated ISAM appliance with the WebSEAL Runtime component configured and a reverse proxy instance created.


This blog post should take 15-20 minutes to complete.

Key Terms:

  • WebSEAL: ISAM’s Reverse proxy and the backbone of all Identity/Access Managment solutions

  • AAC: Advanced Access Control. Component of ISAM responsible for configuring Access Policies and Risk-Based Access

  • AuthSvc: Part of AAC which covers ISAM’s native authentication capabilities

  • Runtime Server: The Liberty server which hosts AAC’s API’s

  • Cookieless: In this article Cookieless or Stateless refers to the operation of a Runtime server without requiring a user to maintain a session cookie.


Configuring the Authentication Service:


In IBM Security Access Manager 9.0.6.0 a convenient wizard was added to the WebSEAL Module to simplify configuration of the authentication service (AuthSvc). This blog post will guide you through this configuration wizard as well as detail a few advanced features you can use to tune the AuthSvc to your specific deployment needs.


First off, use the LMI to navigate to and select the reverse proxy instance you wish to configure to use the AuthSvc.


Then select the Manage→AAC and Federation Configuration→Authentication and Context Based Access Configuration




On the second tab enter the details of the AAC user who will proxy requests from WebSEAL to the runtime. This example will us the default settings for an appliance deployment where:

  1. ISAM Runtime server is listening on localhost

  2. Runtime server HTTPS listening port is 443

  3. default authentication service user is called “easuser”

  4. default password for easuser is “passw0rd”. This should be changed for production deployments

  5. “/mga” is the default prefix for the authentication service


Any of these values can be modified to suit your deployment.


Once the ISAM Runtime details have been entered, leave the default settings on the next tab (unless you have modified previously run this tool and modified the ACLs created) and allow the configuration wizard to run.


Once the wizard is completed, you will get a notification at the top of the screen. Once you are ready, deploy the changes and restart the WebSEAL instance (this will cause a service outage so be careful if this is a production system).



And that’s it! Now your reverse proxy instance is configured for use with the AuthSvc.

Advanced Configuration: Policy kick-off method


In IBM Security Access Manager 9.0.6.0 the policy kick-off configuration parameter was added to the AuthSvc. This option changes the URL used by the AuthSvc to initialise and complete authentication flows. You might be used to the query string method of starting an authentication policy, where the path of a URL might look something like:

/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:password

This method allows users to initialise any policy from the AuthSvc endpoint. Because an user must be able to start any authentication policy from this endpoint, both authenticated and unauthenticated users are able to access it and you may be unintentionally leaking information about your user’s enrolment status or entitlements.

Navigate to the AAC Advanced configuration menu:


  1. Filter available configuration flags by keyword “sps”

  2. Select the sps.authService.policyKickoffMethod parameter

  3. Open the edit dialog box

  4. Select path from the drop-down menu


If the policy kick-off method is changed in advanced configuration to path, the endpoint that a user interacts with is modified. The last part of the URI path used in the query string above is used to initialise an authentication policy:
/mga/sps/authsvc/policy/password

By changing the behaviour of initialising policies, administrators are able to use WebSEAL ACLs to lock down different authentication methods so that certain users/groups/authentication levels have restricted access to a policy.

Advanced Configuration: High Availability and Cookieless Operation


In some production environments it may be desirable to operate the AuthSvc in a stateless mode, where a user does not need to maintain a session cookie. In ISAM 9.0.6.0 several advanced configuration parameters were added to allow administrators to cache AuthSvc sessions. High Availability (HA) architectures are notoriously difficult to design and manage, so this blog won’t go into the finer detail. Instead we’ll focus on the architecture choices which will have a direct impact on the performance of the AuthSvc in a multi-node environment.


Example deployment of multiple Runtime servers backed by a DSC cluster. This allows for fail-over at the runtime and cache contianers.

When scaling the AuthSvc in HA scenarios, administrators must consider: expected load, both surge and constant; if session affinity will be implemented; and typical connection latency between nodes. The advantage of enabling stateless operation in multi-node environments is that (provided sessions are cached in HVDB or DSC) Runtime servers becomes stateless. This removes the need for session affinity between WebSEAL and Runtime servers and allows administrators to horizontally scale Runtime servers as traffic increases. However administrators must be mindful that there will be replication latency between nodes when caching sessions, which can be a source of error that is difficult to diagnose.

During an authentication policy a user’s session is stored and retrieved using the server generated StateId. This StateId is returned to users when further input is required before a policy is completed. To prevent malicious use of stale sessions it is important to appropriately manage both session lifetime and maximum number of sessions that can be cached by the Runtime server.

The available configuration options for stateless AuthSvc operation are:

  • Enabling stateless operation

    • Set the advanced configuration parameter authsvc.stateMgmt.cookieless to true

    • For DSC caching distributedSessionCache.enabled must also be set to true

  • Where should the sessions be stored (authsvc.stateMgmt.store)

    • High Volume Database (HVDB)

      • SQL solution for distributed sessions

      • Performance considerations, particularly if the HVDB is used for other ISVA services (SAML, OIDC, RBA)

    • Distributed Session Cache (Session)

      • Session stored in ISVA session cache

      • Can be scaled based on load

    • Java Memory (Memory)

      • Session store in Java Virtual Machine’s memory

      • Sessions are not accessible to other Runtimes serving the same WebSEAL junction

  • How long the session is cached for how many sessions are kept

    • Session lifetime

      • authsvc.stateMgmt.HVB.lifetime for HVDB

      • distributedMap.defaultTTL for DSC

    • Maximum number of sessions

      • authsvc.stateMgmt.HVDB.maxSessions for HVDB

      • distributedSessionCache.localCacheSize for DSC

    • Limits maximum memory footprint of AuthSvc session caching

    • Session lifetime prevents stale sessions from being reused

    • Need to find the balance between allowing a reasonable session lifetime and limiting resource consumption

    • Long lived sessions increase the risk of session hijacking by Phishing

  • How often the clean-up thread runs (authsvc.stateMgmt.HVDB.cleanupWait for HVDB or distributedMap.cleanpWait for Session):

    • Are there resource contention consideration for frequently running a clean-up thread

  • How many nodes run the clean-up thread (authsvc.stateMgmt.HVDB.cleanupOnlyOnPrimaryMaster for HVDB):

    • Can run clean-up thread on every node or just the primary master

      • Should restrict to just primary master for HVDB caching

      • In memory should be cleaned up by every node

    • Clean up thread can be disabled altogether and managed externally by a database administrator

Configuring the AuthSvc for stateless operation:


To configure the AuthSvc for stateless operation there are several advanced configuration parameters which need to be set. These can all be found in the Advanced Configuration table in the Secure Access Control drop-down menu.


First filter the table by the “authsvc” keyword to only show the entries we are interested in. Values can be changed by selecting the edit icon on the right hand side.

  1. Enable cookieless operation

  2. Select the session store most applicable to your deployment type

  3. Set the expiry time for session caching

  4. Set the maximum number of sessions to cache


For external database deployments:

  1. Set how often to run the database clean-up thread (a value of 0 will disable the thread)

  2. Set how many sessions can be removed in a singe operation (a value of 0 will remove all expired sessions)

  3. Set whether to only run the clean-up thread on the primary master node in a cluster environment



For DSC deployments:

Filter the advanced configuration table on the keyword “distributed” to only show the DSC paramters. Values can be edited by selecting the edit icon on the right hand side.

  1. Enable the distributed session cache for AAC

  2. Set the session lifetime in seconds (called time to live or TTL in the DSC)

  3. Set the clean-up thread interval in millisecondsIf using local caching:

  1. Set the maximum number of session to cache to control memory footprint


If using an external cache:

  1. Set the parameters for the extenal servers. The format of this parameter is a semi-colon(;) seperated string of “<hostname>:<port>:<ssl>”

0 comments
24 views

Permalink