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

book

Article ID: 207857

calendar_today

Updated On:

Products

CA Single Sign On Agents (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 Delievery module available, which get a
little closer to that needs, but there's no mention in it to restrict
the amount of login by day (1)(2).

You can get this module here (3).

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

If it even possible, you may 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
accountablity 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".

     [...]

(2)

    Limit Concurrent Login for CA Single Sign-On

      Customers of CA Single Sign-On may need the ability to limit the
      number of times that a single user can be “logged into” the
      system. This prevents a single user from authenticating and
      accessing their site from two or more different browser
      instances simultaneously
    
    https://docs.broadcom.com/doc/limit-concurrent-login-for-ca-single-sign-on-overview

(3)

    CA Global Delivery Packaged Work Product Download Index

      Limit Concurrent Login for CA Single Sign-On 

    https://support.broadcom.com/external/content/release-announcements/CA-Global-Delivery-Packaged-Work-Product-Download-Index/4800#SSO

(4)

    CA Tuesday Tip: SiteMinder: Limiting a user to a single login
    https://community.broadcom.com/communities/community-home/digestviewer/viewthread?MID=727280