Effective HTTP Session Monitoring in WebLogic Server With monitoring-attribute-name

Monitoring HTTP Session on WebLogic Server is one of the common task for administrators when monitoring web applications for performance or for activity or usage. Web application modules deployed to WebLogic Server maintains a "monitoring ID", which although looks like a session ID is not the same as the real session ID. You can use the monitoring id to identify the session uniquely. Monitoring IDs are not same as session IDs for security reason. You can turn on session debugging which prints session IDs to the log but these will not match what you see in the console/WLST. Monitoring ids are randomly generated by default. You can set a value to this monitoring id through a session attribute using "monitoring-attribute-name" element in session-descriptor of the weblogic.xml. This can simplify the task of monitoring sessions for administrators in production environment.

For e.g. if you set the "monitoring-attribute-name" to be "user-name" then it will use the string value of the session attribute named "user-name" as the value for Monitoring ID instead of the randomly generated value. When getMonitoringID(sessionid) method is called on the ServletSession, it will return session.getAttribute("user-name").toString().

weblogic.xml
-------------
...
    
     600
     user-name
    
    
    
 true
    
...

So if you have an attribute within the HTTP Session which can identify the user/session uniquely then you can use that as the monitoring id. This is the recommended approach to track/monitor sessions instead of the session id which is an internal attribute. If you don't set the monitoring-attribute-name, WLS will randomly generate a monitoring id for each session. When developers set the monitoring-attribute-name, this will help administrator to associate sessions to the actual users.

Sample WLST script to get all the monitoring ids (for the respective session) as an array:

...
AppName = 'MedRecEar'
TargetServerName = 'MedRecSvr1'
WebCompName = 'MedRecWar'
serverRuntime()
cd('ApplicationRuntimes/' + AppName + '/ComponentRuntimes/' + TargetServerName + '_/' + WebCompName) MIDs = mon_ids = cmo.getServletSessionsMonitoringIds()
...

In the above example, the variable mon_ids will contain an array of monitoring ids as strings. Using these monitoring ids information about the individual session can be obtained from other operations like:
- getSessionLastAccessedTime
- getSessionMaxInactiveInterval

One can even invalidate the session using the following opertion:
- invalidateServletSession

This will give an option for administrators to cleanup or delete stale sessions if there are any. These are the only information that are exposed for sessions unless you want to use the deprecated ServletSessionRuntimeMBeans. This is an old MBean that has more methods/operations. Admin console doesn't expose the session id for security reason. If you need access to all the session ids for some reason then you have to use this deprecated ServletSessionRuntimeMBeans. You can get all the ServletSessionRuntimeMBeans as an array from a WebAppComponentRuntimeMBean using a deprecated getServletSessions() method. WLST script to access the above mentioned deprecated ServletSessionRuntimeMBeans:

...
AppName = 'MedRecEar'
TargetServerName = 'MedRecSvr1'
WebCompName = 'MedRecWar'
serverRuntime()
cd('ApplicationRuntimes/' + AppName + '/ComponentRuntimes/' + TargetServerName + '_/' + WebCompName + '/ServletSessions')
ls()
....

The above ls() command will list you all the sessions with session id as their name. Even though this post has lot of information on how to monitor sessions and make use of the monitoring-attribute-name, I shall write another to provide a complete example of how to use this.

Also see my other post on how to monitor HTTP sessions from the administration console and WLST.

User Lockout & WLST

WebLogic server provides an option to lockout users to protect accounts from password guessing attack. It is implemented with a realm-wide Lockout Manager. This feature can be used with custom authentication provider also. But if you implement your own authentication provider and wish to implement your own lockout manager that is possible too.

If your domain is configured to use the user lockout manager the following WLST script will help you to:
- check whether a user is locked using a WLST script
- find out the number of locked users in the realm

#Define constants
url='t3://localhost:7001'
username='weblogic'
password='weblogic'
checkuser='test-deployer'

#Connect
connect(username,password,url)

#Get Lockout Manager Runtime
serverRuntime()
dr = cmo.getServerSecurityRuntime().getDefaultRealmRuntime()
ulmr = dr.getUserLockoutManagerRuntime()

print '-------------------------------------------'
#Check whether a user is locked
if (ulmr.isLockedOut(checkuser) == 0):
 islocked = 'NOT locked'
else:
 islocked = 'locked'
print 'User ' + checkuser + ' is ' + islocked

#Print number of locked users
print 'No. of locked user -> ', Integer(ulmr.getUserLockoutTotalCount())

print '-------------------------------------------'
print ''

#Disconnect & Exit
disconnect()
exit()