Wikis - Page

How to forcefully remove an existing authenticated user from the IDP server with this free tool

0 Likes
Authors: Neil Cashell
Chandra Shekhar Tumula

Introduction:


NetIQ Access Manager has always provided the ability for users to single sign on to back end web servers. These back end web servers provide a series of protected resources that users can only access once authenticated to an Identity Server, and authorised by the Access Gateway. Having parsed the user credentials, and validated these credentials against a back end user store, the Identity server creates and maintains an active session for that user. Only when the user manually logs out of the Identity server, or if the user's session timeout expires, will the user's active session be removed. If the user continuously accesses protected resources before the session timeout expires, the session can technically remain active forever.

There may be cases where an administrator wants to forcefully remove an authenticated user. An example of this maybe the following:

  • A user Neil, who currently has an active session on the Identity Server and access to many protected resources, has had a position change within the organisation causing a change to resources that may be available.

    • By forcing Neil to logout and login again, his new roles or attributes may be retrieved by the Identity server and used in policy evaluations by Access Manager to accurately reflect his new position



  • A user Chandu, who currently has an active session on the Identity Server and access to many protected resources, has been let go by the organisation and all access to protected resources must be removed

    • By forcing the removal of Chandu's session on the Identity server, any subsequent requests to the Identity Server would require a new login.




With NetIQ Access Manager, no tool exists that allows an administrator to forcefully remove an active user session.

Solution:


The following JAR file and JSP pages will allow an administrator to:

  1. View all authenticated user session on the IDP server and

  • Forcefully remove an existing, active authenticated user session on the Identity Server.


Simply copy the killusersession.jar to any Java host, and the getUserSession.jsp to /opt/novell/nids/lib/webapp/jsp/getUserSession.jsp on the Identity Server.

When the Admin user has authenticated to the Identity server, they can then access the following URL on the Identity server to see all authenticated and active user sessions to that server - "https://<$IDP_Base_URL:$IDP_Port>/nidp/jsp/getUserSession.jsp - and see the following output:

28203-1

Note that only the admin user can view all user session info by default. To customise the JSP so that other delegated users can also view the session information, locate and modify the following line in the getUserSession.jsp file
if(currentprincipal.getDN().startsWith("cn=admin"))

to include other usernames.

The JSP page will be accessible by all users, but only that user's session information will be displayed. No other user session info will be available unless the user has logged in with an Admin username as configured in the getUserSession.jsp file.

If you know the name of the user that you want to forcefully remove, you can simply run the following command on the host running the JAR file:
KillUserSession  <<SEARCH_USERID>> <<IDP_HOST>> <<IDP_PORT>> <<IDP_SCHEME>> <<admin>> <<adminpwd>>  [contractID]

Where:

  • IDP_HOST is the IP address or DNS name of the Identity server

  • IDP_PORT is the TCP port that the Identity server is listening on (typically 443, or 8443)

  • IDP_SCHEME is the scheme used to access the Identity server - either ssl or nossl depending on whether we are using https or http respectively

  • SEARCH_USERID is the context less username of the user session you want to forcefully remove

  • Admin is the LDAP proxy user defined for the back end LDAP user store

  • Adminpwd is the LDAP proxy user password defined for the back end LDAP user store

  • contractID (Optional) is the form based contract ID that the LDAP Admin User logs in with. The Admin user must login to retrieve the session information for the user we are trying to forcibly remove. This only needs to be specified if

    • no form based default contract is assigned to the IDP server




An example of the command is the following - an existing user ncashell is authenticated at the Identity server with a custom contract whose ID is CustAuthCont, but needs to be removed immediately. This CustAuthCont contract is not defined as the default contract in the Identity Server configuration.
nam32phys:~ # /opt/novell/java/bin/java -classpath killusersession.jar KillUserSession ncashell 147.2.16.135 8443 ssl admin novell CustAuthCont

Current admin user session id : JSESSIONID=C73BA60DF1D20E0626C4DFAA7B9E8E6D
UserSessions: cn=ncashell,o=novell::0C3454655531B2DFE3E92C62C3A8F0F7
Logout Successful. -JSESSIONID=0C3454655531B2DFE3E92C62C3A8F0F7
Logout Successful. -JSESSIONID=C73BA60DF1D20E0626C4DFAA7B9E8E6D
I am done!

As soon as this operation is performed, the user ncashell session is terminated from the Identity server, and any other trusted service providers it has provided an identity to during this session e.g. an Access Gateway or SAML2 Service Provider.

The getUserSession.jsp link above will confirm this - the Admin user can check this and confirm the session is no longer displayed. If the same user then tries to access the Identity server again, or an Access Gateway protected resource it was communicating with, the login page will be displayed asking the user ncashell for the credentials again.

Note: In a clustered environment, there is no guarantee that each cluster member will own the users session e.g. If the user ncashell authenticated to Identity Server IDP1, but the killusersession command to remove the user session was sent to Identity Server IDP2, the session will not be removed. In order to make sure that the users session is removed, run the killusersession application against each node in the cluster.

Labels:

How To-Best Practice
Collateral
Comment List
Parents Comment Children
No Data
Related
Recommended