Is it possible to limit the number of active user on a protected resources on a siteminder SPS? I want to assure that the protected resources is used by a limit number of active users let's say n.
Thanks,
Andrea
Session Limiting is available with SiteMinder as an add-on module by the vendor. Please reach out to them, the maximum number of session for a given identity will be limited to the max that is setup in the authentication mechanism. It will bump the oldest session to grant a new one - or it may even be configurable to not allow a new one, based on configuration.
Related
I just took over a project and noticed that they are using a DB profile as such for service accounts used for connection caching
ALTER PROFILE APP_PROF LIMIT
SESSIONS_PER_USER 100
CONNECT_TIME 640
IDLE_TIME 15
...
I believe that is why we are sometimes getting stale connections, and the "ORA-02399: exceeded maximum connect time, you are being logged off".
My question will be: For middle-tiered applications where connections are cached, are there any good reasons why such a profile would be used for service accounts with such limits ?
Personally, I'd be hard-pressed to imagine a situation where I'd want to have a middle tier service account with a connect_time or idle_time set. I suppose it's possible that someone somewhere has a reasonable reason to use such a configuration-- maybe forcing connections to be frequently recycled is the least painful way to quickly put a band-aid on a resource leak, for example, while you looked to fix the underlying code issue. But those would certainly be settings I'd look at carefully.
I've seen and heard of cases where someone wanted to set sessions_per_user for a middle tier service account where the relationships between the middle tier app server admins and the database admins were strained. Normally, the middle tier admins set a cap for the size of the connection pool in the middle tier in consultation with the DBA team that makes sure that the database can handle connection_pool_max * number_of_app_servers connections. If the middle tier admins have a history of spinning up new app server farms or bumping up the number of allowed connections in the connection pool without talking to the DBA team, the DBA team may want to set their own limit to protect the database. I'd much rather solve the communication problem than have a separate database limit.
I am facing session swapping or session expire issue in Oracle APEX. Is there any solution for this problem?
As of session timeout:
connect as ADMIN to your Apex
Manage Instance
Security
Session Timeout - set those numbers to larger values than they currently are
Alternatively, there's the same option in your own application - it can be found within Shared Components. If it is not set, it'll take values set for the instance (or the workspace).
I don't know what session swapping is.
Help us help you. Always include the version number of the software you are asking about and what steps you have tried and what the outcome was.
You can control session timeout at the individual Application Level. Docs here : Session Management
Use Session Management attributes to reduce exposure by application to abandoned computers with an open web browser.
No idea what session swappin gis.
I'm working in a project with session independent mode configured (worklight.properties file). In my Analytics Console I can see 68 total adapter calls but the total sessions number shows 0. Is this behavior right? I think must have 1 session created at least.
In this link I found information related, however 0 sessions versus 68 adapter calls sounds rare.
The behaviour you observe is expected. This is because in session independent mode, session count increases when a protected resource is invoked and an OAuth token is issued from the server. This does not appear to be happening in your case with the use of WL.Client.invokeProcedure().
If you use WLResourceRequest API to invoke your adapter resources , the session count will increase on the first resource request as a new token will be issued from the server. More details on the API in this link.
Session count will not increase again until the token expires, a protected resource is called, and a new token is issued from the server.
The information is available in the link you have already referenced.
I need in my project more session management than I thought at the beginning. The major feature that I need is to list all sessions for (or per) identified principal (for example to delete/invalidate all his session id's). I don't want to use SessionsRegistry because of distributed kind of a system.
So two questions:
How to list session ids in Spring-Session (Do I need to come with custom implementation) ?
Is there a way to set sessions time-out that is not interval between requests but max session time life?
Typical use case for such functionality is to prevent malicious user to continue his activity by blocking his account and invalidate his all sessions across the servers.
We have a clustered WebSphere environment and have 4 nodes in the cluster. I am trying to find number of concurrent users that use the application. I have turned ON Performance Monitoring Infrastructure (PMI) in WAS for Servlet, JVM and Thread Pool. When I monitor using Tivoli Performance Viewer, I believe I need to look at "LiveCount" under the "Servlet Session Manager". But the count seem to be VERY high, more than what I was expecting (LiveCount shows as 80-100).
Is this the Metric to look at when trying to find the total number of concurrent users?
Does it keep true login count or is it keeping track of number of sessions?
I was told the underlying application creates only 1 session per login until it gets timeout. At which point, the user will have to login again. So to me concurrent user count = session count = this Servlet Session Live Count.
Can anyone help me here and let me know which metric I should look in PMI to get the concurrent user count? We are are WebSphere 7.x.
I believe I need to count this metric value for all 4 nodes to come up with the total concurrent users.
You may consider logged on users vs concurrent users, depending what you are really looking for.
The logged on users would be successfully authenticated and having valid session in the application, but... they may currently do nothing in your application, or abandoned your application but not logged out.
They will be represented by LiveCount - The total number of sessions that are currently live.
The concurrent users would be users simultaneously access your application. They will be represented by ActiveCount - The total number of sessions that are currently accessed by requests.
And yes, you have to sum this from all your app servers.
See also:
Servlet session counters