Limit MAF Concurrent Sessions?

Hi, Does anyone know if there is a way to limit concurrent sessions in a MAF application for password authenticated users? I have been asked by the business to identify whether or not this would be possible in order to thwart users from sharing usernames across multiple employees - the idea being that a user should only be allowed one active session at a time. Same question would apply if we were to implement OnePass as well. Many thanks, Dave

Answers

  • Hi Dave, We are using login limit for that, but we have experienced different issues along the way. Sometimes, stalled records in prism database are not deleted. That was causing some users couldn't access. The stalled records are deleted 24 hours after they are created. It is quite complicated to explain. Currently I think that it is working more or less acceptable for our products but we have some pending work to do. We also have OnePass in one of our products, and the issues are exactly the same. Regards, Hector
  • Thanks Hector. Just had a chat with Hector. In summary, login_limit is being used on Insignis, WLES and CPES. It's a flag on the PRISM Users table. If set to -1 it's unlimited. Insignis, etc. update this via the API rather than via SAP (but I guess SAP might be able to set it). Set on user by user basis. Re: stale records, PRISM recommendation is to set login limit to 3 or 5 to prevent issue. That doesn't stop user id sharing so Insignis, etc. set to 2 to try to avoid lockout. MAF login action logic not right and caused serious issues that were only addressed locally (not mainline)...
  • View is that login_limit feature is not stable at the moment, but it is the only way to currently restrict concurrent access.
  • I believe it needs to be tested within the business unit. The prism funcionality works fine, and the MAF code on top of that is designed for a simple use case. In the case of Spain, they has put a "microsite " on top of MAF applications, creating sessions and destroying them, which break the login limit funcionality. Pretty hard to debug and reproduce issues due to the high number of round trips created by the "microsite". So, the fixes where mainly for that specific Spain use case.
  • Other systems in Legal are controlling it without using Prism. Westlaw, WestlawNext, Concourse, etc. These are controlling it by knowing the concurrent access limit, and keeping track of the number of sessions a user has started. I can get you a contact if you need more information on how this works. OnePass itself won't do any of this, as we don't know about sessions.
  • Yes, please. If you have a contact/documentation on how this works, that would be most useful.
  • For any Cobalt Platform product (WestlawNext, Doc & Form Builder), I would talk to Ron Burke.
  • Thanks.....
  • Yes, Enrique, you're right, it is not MAF itself, it was our business requirement what cause the issue. But when we launched Insignis we were using formLogin action and we were not using the "microsite" and still had issues. Now we can't reproduce that scenario and probably new business units adopting login limit won't have the same issues we had.
  • PrismSec has a [Login Limits][1] feature that is often used, but it also automatically happens with the login API. > **Login Limits** > > PrismSec login limits > allows an application to limit the > number of times that a user > concurrently logs in. This can be used > to help ensure that multiple users are > not sharing the same user ID. > (PrismSec also supports the concept of > a login limit on a per group basis, > and, this is called Session Metering. > Also, Prism provides a Login > Limits/Meter Terminator service.) > > Note, however, that the vast majority > of users do not logout of > applications. So, setting the login > limit to 1 is not recommended. If you > set a user's login limit to 1, and > that user does not logout, they will > have to wait until their session times > out before they can login again. (And, > if users have to wait a half hour to > login, you'll have a lot of frustrated > users flooding the call center with > calls.) So, I recommend that you think > carefully about what value you set the > login limit to. You are better off > setting the login limit a value higher > than 1 or 2. (You could try 3, 4 or 5 > and see if that keeps most users > satisfied.) That way, users can still > login, even if the have a couple of > "stale" sessions. For the original WLES implementation in 2006, Prism added a [session metering][2] API that allows the application to `incrementSessionMeter()` and `decrementSessionMeter()` at their initiative. This doesn't fix the logoff problem, so the session timeout still needs to call to prism, but does help when this feature is used. Your microsite scenario might be one where the `incrementSessionMeter()` would never be called. As Chad mentioned, OnePass is not aware of product sessions, and has no such facility. However, some MAF applications have had implementation issues with the validation callback in that they login but do not logoff the user, leaving the Prism login limit artificially incremented. For WestlawNext and the Cobalt Platform, we designed concurrent session counts to be the number of UDS session records in the database with an ONLINE session status. Then, when the session is terminated, either via logout or the reaper, the count is effectively terminated. Totaling sessions in this way is also what allows for application or site user totals to be as easily reported on as user totals. For WestlawNext features such as "Patron Access" we allow for greater that one concurrent user. Also, a user can concurrently use the website, mobile website and iPad application without restriction, but not two website sessions in different browsers. [1]:
    http://nsawiki.int.westgroup.com/wiki/index.php5/PrismSec_Online_Service#Login_Limits [2]:
    http://nsawiki.int.westgroup.com/wiki/index.php5/INF_Metering
  • Thanks Kevin. Do you know which MAF products are currently using the PrismSec Login Limits feature successfully in Production?
  • The Login Limits feature is stable. The issues encountered by the Aranzadi/Spain applications that Hector mentions is fairly isolated to a login sequence that is unique to their flow through a portal (microsite). A fix has already been checked into MAF mainline to prevent incorrectly incrementing the login count when attempting to login to an already active session. Note: The login limit is controlled from SAP. Since Aranzadi currently have their own SAP, they do this from their end, which is equivalent to how it is done by Eagan SAP for other MAF applications.
  • Checkpoint World uses the login limit
  • When migrating from original WLES implementation, in STK framework, to MAF, we were considering to implement session metering in MAF, but we discarded it because we thougth that login limit could cover this functionality.