For various reasons, many organizations (have to) use legacy applications. That is simply a fact we need to cope with while creating integration solutions. One of our customers use really old SunSSO, which was released about ten years ago, and use it for authenticating users. This particular version of SunSSO doesn’t have any simple API for external applications. It has only the SOAP service which cannot be used, e.g. for session token validation. Because we needed to validate sessions from other applications, we wrote ourselves a simple RESTful API.

Using servlets as REST providers

SunSSO was open-sourced in 2005 as OpenSSO but, later after acquisition, Oracle removed the source code from the download sites. Company called ForgeRock created a fork of OpenSSO and develops the product under the name OpenAM. OpenAM comes with a nice pack of REST services. Their specification was a base specification for our servlet REST interface. The specification considered here is from OpenAM 10. In version 11, ForgeRock marked it as deprecated and moved to more convenient JSON format. Specification we used can be found here.

For accessing functionality of the access manager itself, we need to deploy servlets into the same application context. This will ensure that requests can be forwarded into the AM’s classes. The principle is that the servlet translates client requests into objects and then forwards those objects in standard manner into the access manager.

Example: Session validation

There comes a simple example on how to write a session validation servlet by yourself. First, we set up the development environment – standard J2SE project is perfectly sufficient.

Now we have to add the development dependencies: am_sdk.jar, am_services.jar, servlet.jar. All those can be found in your existing SunSSO installation. Just copy them over and update classpath of the newly created project. Also, do not forget to set appropriate JVM version (1.5 in most cases).

Example: Servlet deployment

Suppose we created the IsTokenValidServlet as shown in the previous section. Now we need to deploy it.

First, package the compiled class into jar archive (lets call it RESTservlet.jar). Copy this jar into the directory where other SunSSO jars are located. Open the server.xml file of the AM server and add the /path/to/RESTservlet.jar into the classpath so the server can find our class.

Second, register the servlet into the AM namespace. Open the web.xml of the AM application and add those lines:

The final thing you need to do is to restart the application container. After the restart, you should be able to access token validation servlet in the path:

http://host.domain:port/AMserverDeploymentURL/identity/isTokenValid

Conclusion

As we have shown, it is not so hard to write functioning REST-like API even for old SunSSO software but we feel that many people could actually use it. That is why we chose to make sources publicly available. You can clone the git repository from the:

https://proj.bcvsolutions.eu:9443/pub/sunsso-rest.git

We use self-signed certificate. To turn off certificate check temporarily, issue clone in the following form:

In the repository you can find the existing REST servlets source codes. Unfortunately – due to licensing – we couldn’t add the jar dependencies. It probably does not matter since those of you who will need to use these servlets, will probably have access to an instance of SunSSO.

Any feedback, patches or comments are greatly appreciated. If you have questions you can also contact author by email: petr.fiser@bcvsolutions.eu.

From the moment that you could read the article about tools for monitoring our Identity Management CzechIdM, had passed quite a few months and now we made a progress. In the new version CzechIdM, which is being tested and will soon be presented to the public, there is active monitoring and sophisticated environment offers many opportunities for administrators and most simple configuration. Let’s look what we can in the new version CzechIdM monitored and how monitoring customize to your liking.

Diagram of solutions

The Admin interface

In the administration interface CzechIdM there is a new tab in the main menu called “Status Page”.

If you click on it, Czech IdM starts a set of tests and displays a table with the results.

Each line corresponds to one test:

The column “Type” describes the type of test, ie the information if the connection has been tested on any of the connected systems, regular starts of synchronization, functionality of a particular user or your own code.

In the “Target” is the name of the test subject, in case of test connection with the connected system, is there name of the system.

“Message” may contain additional information. When you find that any of the tests fared badly, here you can begin to investigate why.

Administrator therefore just one click and he knows what is OK and what isn’t. CzechIdM runs required set of controls and displays the results in a table.

Configuration

Scope of of tests and their parameters can be set according to your wishes in the configuration file BCV_IdM-ear.ear/BCV_IdM-ejb.jar/META-INF/idm_configuration.properties. Tests have five parameters, their names all begin with the prefix “status_”:

status_resources – List of connected systems, which is to be monitored connection with CzechIdM. Delimiter in the list is a semicolon, for each system you can define a time limit for the test, per colon. Use the special string “__ALL__” instead of the name of the system can determine that are to be tested all of the associated systems.

status_users – list of users to which the operation is “checkout-checkin”, the updating of information in CzechIdM from the source systems and the inclusion of this information in connected systems. Again, you can specify multiple users by separating them with a semicolon, again, you can set a time limit for each user.

status_synchronizations – list of connected systems, which should be checked for regularly starting synchronization. With each system name there is the maximum interval between synchronization runs separated by coma, different systems are separated by a semicolon.

status_recons – similar to status_synchronizations, instead of synchronizing is checked regularly starting reconciliations

status_custom_rules – tests tailored for advanced users. Can you provide a list of rules to be launched, along with every timeout and expected (error less) result.

The above configuration ensures that every time you start the tests will be checked connection systems “Active Directory”, “Docházky” and “MySQL”, the success will be considered if the test for “Active Directory” ends correctly within 10 seconds, other two systems ends correctly within 5 seconds.

Plugin for Nagios

In the screenshot at the introduction you saw a table in the admin interface. For machine processing is more suited its text CSV format. It can be downloaded from the running CzechIdM from address /idm/admin/status/showcsv.seam. For regular monitoring you can use a script checkIdMStatus.sh that comes along with the new version. Before you run it, open it for editing and set the variables at the beginning of the script according to their own use, especially login name and password. If you set run of script in cron or if you use it as part of the monitoring system Nagios, it arrives you reporting on failed test by e-mail (please check that you correctly functioning command “mail” from the shell and you do not have very strict firewall for sending mails). Please make sure to limit the rights for the script, it contains the login name and password.

Conclusion

CzechIdM provides for administrators a new way of active monitoring. A specific set of tests may vary on individual deployments, the administrator it can easily customize the configuration file idm_configuration.properties without having to restart the application server running CzechIdM. Along with CzechIdM is also supplied control script that can serve as a plugin for Nagios. If you need help or would like some upgrades to the next version, email me at jan.effenberger@bcvsolutions.eu.