Policy Server: how to limit user authorized sessions amount by day

Products

CA Single Sign On Agents (SiteMinder) SITEMINDER CA Single Sign On Secure Proxy Server (SiteMinder)

Issue/Introduction

When running a Policy Server, is there's a way to limit for a given user, the number of authorized sessions by day?

Environment

Policy Server 12.8SP5 on RedHat 8

Resolution

At first glance, out of the box, Policy Server doesn't provide that feature. There's a Global Delivery module available, which get a little closer to that need, but there's no mention in it to restrict the amount of logging by day (1)(2).

This module can be downloaded here (3).

This feature Global Delivery Module is also reported in our communities (4).

If it's even possible, customize the authorization to set a counter for a given user, and check the counter at each authorization processing and deny the access when it reaches a given amount. One pitfall is that a given user may be authorized by the Web Agent cache instead of Policy Server, and this will complicate the authorization accountability for the given user.

Additional Information

(1)

Limit Concurrent Login for CA Single Sign-On User Guide
Version 3.2.0

      History of and Rationale for the Original Limit Concurrent Login
      Implementation

      Many (f/k/a SiteMinder) customers have requested the ability to
      limit the number of times that a single user can be "logged into"
      the system. This is a nebulous concept, given the definitions of
      "logged in" and "logged out", when you consider the nature of Web
      sessions.

      What sites want is the ability to prevent a single user from
      authenticating and interacting with their site from multiple
      different instances of a browser, either running on the same or
      different machines. This desire stems from one (or more) of four
      reasons:

      - Security. This would prevent a rogue user from accessing a
        site using a known userid/password while the legitimate user
        was using the site (note that this would not prevent the rogue
        user from using the site when the legitimate user is not using
        the site).

      - Accountability. The site wants to know exactly who performed a
        transaction (and, theoretically, from where, though, with IP
        address spoofing and network address translation, this is not
        realistic).

      - Revenue. Some sites charge their users by user id. Their
        customers can cheat the system by allowing multiple people to
        use the same user id. The site only sees one user in use, so
        the customer is only billed for a single user id. Sites want
        to recover this revenue and charge for the actual number of
        users.

      - Legacy. "Our mainframe does it".

     [...]