Category Archives: Other

Certificate authority module in CzechIdM, part1 – the overview

Many companies use an on-premise certificate authority (CA) for their internal purposes. Without a doubt, one specific function of the certificate authority in a company is handling users’ certificates. Those certificates are bound to physical persons and as such, they fit neatly into the identity management problematics.

For this reason, CzechIdM implements the CA functionality in the form of a module. In this short series of posts, we will describe basic workings of our CA implementation and how it can be fit into the company’s infrastructure.

Continue reading

Load Balancing with JMS Queue

Some time ago we were implementing Identity Management solution at an electricity distribution company. The core component was our Identity Manager CzechIdM.
CzechIdM interconnects systems with portal application and enables hundreds of thousands of customers to create and manage their login information. Because of the huge number of users, CzechIdM has to withstand a significant load of hundreds of requests per second. In this post, we will show you, how it is done.




Every information system and hardware has its limits. In the complicated application, not mentioning environment of integration platform, the limitations are even stricter. Aside of RAM consumption, disk space and CPU, we have to deal with network throughput, database connectivity and endpoint system delay.
In this deployment, every single user request is important and must be served. This is because of registration, password reset and password change functions. Because of the high load, CzechIdM implements request queue. Under fire, the system with the queue may slow down, but every user request will be processed. And that is what matters.

JMS Technology

Java comes with bundled technology for internal application messaging called Java Messaging Services, JMS. Using internal messaging, some part of the application can transfer data to another part. The JMS messages are stored in the queue until the recipient accepts them. The queue can be either persistent or in-memory.

In our case, user requests are served by classes, which simply encapsulate request into message, push it to the queue and wait for the response from component, which actually processes the request.

Queues themselves are handled by the application server. Thanks to this, configuring new queue is only a matter of creating appropriate xml configuration.
First of all, we define new sender in components.xml:

<jms:managed-queue-sender name="myQueueSender" auto-create="true" queue-jndi-name="queue/myQueue"/>

Then, we will define queue service itself:

<?xml version="1.0" encoding="UTF-8"?>
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>

Finally, we will create a Java class which sends the messages into queue:

public class TaskMultithreadControllerBean implements TaskMultithreadController {

protected QueueSender queueSender;

@In(create = true)
protected QueueSession queueSession;

public Object executeTask(ApplicationTask task, int priority, boolean waitForResponse) {
try {

//prepare a message for send
ObjectMessage message = this.queueSession.createObjectMessage();
TemporaryQueue tempQueue = null;
MessageConsumer consumer = null;

//in case we are expecting response
if (waitForResponse) {
tempQueue = this.queueSession.createTemporaryQueue();
consumer = this.queueSession.createConsumer(tempQueue);

this.queueSender.send(message, DeliveryMode.PERSISTENT, priority, timeout);


//we are waiting for response - we create temporary reverse queue
if (waitForResponse) {
ObjectMessage response = (ObjectMessage) consumer.receive(waitForResponseTimeout);

Object result = null;

//we return the response
if (response != null) {
result = response.getObject();
return result;
} else {
return null;

Message Driven Bean

The queue has attached listeners. These listeners consume messages from the queue and process data. They are generally called Message Driven Beans. Their number is limited by the settings in the application server, so we are sure we will not tun out of memory due to high message count.
Message Driven Bean is a Java class which implements MessageListener interface and is appropriately anotated:

@Depends( {"jboss.web.deployment:war=/idm"} )
        name = "myMDBean",
        activationConfig = {
                @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
                @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/myQueue"),
                @ActivationConfigProperty(propertyName = "maxSession", propertyValue = "10")}
public class TaskMultithreadExecutorBean implements MessageListener {

    @In(create = true)
    protected QueueSession queueSession;

   public void onMessage(Message message) {
        try {
            //do we need to send reply somewhere?
            Destination replyTo = message.getJMSReplyTo();
            Integer timeout = null;
            //get timeout reply
            if (replyTo != null) {
                replyProducer = queueSession.createProducer(null);

                timeout = IdMConfiguration.getInstance().getAsInteger("queueResponseTimeout");
            ApplicationTask task = message.getObject();
             //send reply
             if (replyTo != null) {
                        ObjectMessage response = queueSession.createObjectMessage();                

                        replyProducer.send(replyTo, response, DeliveryMode.PERSISTENT, 9, timeout);
        } catch (Throwable e) {

The most important method of the Bean is onMessage() method. Input of this method is whole message. Only problem here is, that message payload has to be a primitive type (or a String). As a workaround, we used standard Java serialization combined with base64 encoding – we send every request (or response) object in its serialized base64 encoded form.

Maximum number of Message Driven Beans

There can exists a pool of Message Driven Beans. Application server creates a number of threads dedicated to process requests incoming to the pool. The pool size is configurable throught the annotation:

@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "10")

And thats it! The JMS technology takes care of everything else – thread scheduling, pool synchronization or even the message persistence in the database.


In the post, we described how CzechIdM uses JMS for load balancing of user requests. If you have any questions, don’t hesistate and contact us on


RESTful API for legacy SunSSO

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).

The validation servlet could look like this:

public class IsTokenValidServlet extends HttpServlet {

 public static final String TOKENID_GET_PARAM_NAME = "tokenid";


 public void doGet(HttpServletRequest request, HttpServletResponse response) {
 ServletOutputStream out = null;
 try {
   out = response.getOutputStream();
   String tokenid = request.getParameter(TOKENID_GET_PARAM_NAME);

   if (tokenid == null || tokenid.equals("")) {
   } else {
     SSOTokenManager manager = SSOTokenManager.getInstance();
     SSOToken token = manager.createSSOToken(tokenid);

     if (manager.isValidToken(token)) {
     } else {

 } catch (Exception e) {

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:

   <description>REST-like SSO token validation</description>

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:



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:

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

GIT_SSL_NO_VERIFY=true git clone

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:

Delegation of the approval request in CzechIdM

Delegation of the approval request extends options of requests in CzechIdM. This function gives users opportunity dynamically to choose own deputy, who have been entrusted approving incoming requests.

The basic functionality

Delegation, in their basic functionality, allows users move own rights and responsibility related with requests in CzechIdM to other user or a group of users. The user only needs to choose in CzechIdM web interface some other user(s), to whom he would want to delegate own requests and, when the deputy accepts this responsibility delegation, this delegation becomes active without any complicated administration.

Now all of approval requests will stop comes to original approval and it is sent to every active deputy. Every one of this deputies has full rights to approve or reject this request. When someone finishes the request, it is regarded as closed and it is deleted from list of waiting requests by other deputies.

 Time limitation

In choosing deputy is possible in delegation form choose start-date and end-date of delegation validity. This choice enables various options of delegation, then in practice delegation is not active before start neither after end of validity. CzechIdM treats with inactive delegations like they don’t exist – i.e. when user has a lot of delegations but all of them are inactive, CzechIdM sends every request to him.

Specifying start-date or end-date is not mandatory and nothing prevents to user leave one or both fields in form empty. Without specifying end-date is delegation indefinitely (until user cancel it). Without specifying start-date delegation is valid at the moment of confirmation by deputy.

Using the delegation

Users with relevant rights have access to tab “Delegate tasks” in CzechIdM in Tasks section. On this site there is shown overview of all delegations with the time intervals during which are tasks delegated to the deputy (or deputies). By pressing the Edit button we move to the displayed form below, which is for create new delegation.

Form for delegation editation in CzechIdM

By pressing button „Select user“ displays dialog box, which allows searching in list of other users and their filtration by user-name, first name or last name.

The dialog box for deputy selection when creating a new delegation

After selecting a user is added to the list of selected users. In the right part of form is possible to specify start-date and end-date of delegation validity.

Selecting start-date and end-date when creating a new delegation

After selecting users and time range is need to create the delegations. To do this is there button Select, after its pressing is created one line in list of selected users for each user, with time details.

The result of adding a new delegation to the table

In this table is possible to delete any existing delegation (using option „Delete“ at the end of line). To close the edit form are there two buttons on the bottom of the form. By selecting Close the form is only closed and all changes are discarded. The Save option saves all changes to the system and after that closes form. Deleting the existing delegations takes effect immediately but creating a new delegation take effect until after that the deputy approved the delegation.

Delegation in the cascade…

The system does not restrict users to delegation their requests to someone who delegates his request also, even on several levels. The resulting cascade behaves so that any request addressed to one of the users in the resulting delegation concatenation, gradually passes through all participants in the chain and is sent only to the user at the end.

… and in the circle

In the event that users consciously (or unconsciously) close the chain of delegation – ie in chain of delegations would occur one user on two different places – a situation can be call delegation in the circle. System in this situation can not adequately determine to whom requests should be delivered, therefore contains a fuse that will ensure that in the case of delegation in circle, all requests sent to participants in the circle, are sent to the original recipients.


Described delegation function is already standard component of our Identity Manager CzechIdM. Currently, we are planning further extension the functionality for better overview and control and from the perspective of the delegate and few administration functionality for easier delegation management. If you are interested or questions please contact me at


Year 2013 in BCV

2013 in BCV

2013 was for us and for our customers the year, of massive increase in managed accounts and number of systems connected to CzechIdM. We focused on the completion of contracted projects and stabilization, strengthening of our knowledge.

Changes in 2013

– For our customers we manage through CzechIdM over 2mil accounts.

– We have developed new connectors for CzechIdM: Vera, Active Directory, Siebel, Matrix,   Navision, Fama, FIS CVUT, Medea, eIdentity, MS-Exchange 2010, OpenAM, Liferay, Sun Access Management, AW Caesar, VPN, Sun Portal.

– We went through an external audit of accounts for years 2011-2013.

– Traffic on our blog is still increasing. For year 2013 it makes 150%.

– We achieved two new references from our customers.


Developing and improving our product 

–  We managed plenty of internal trainings

– We developed need product suited up for medical devices –

– We changed the internal development methodology to more agile.

– We take the speed of development into whole new level.

– We released 2 new versions of CzechIdM.

– We migrated Oracle Cluster from 10g to 11g.

– We are testing more, until now, 40% spent time is dedicated to testing.


For 2014

We are preparing a product surprise! Coming soon :)

When you say CzechIdM

What is CzechIdM?

The CzechIdM Identity Manager is a tool providing central and automatic management of all user identities (accounts, groups etc.) in the whole network, with no negative impact on the work of the current system. CzechIdM communicates with end systems in their native protocols (LDAP, JDBC, SSH, …). CzechIdM is usually connected to end systems by special connectors written in Java. You can find the list of supported systems below under „List of connectable systems“. CzechIdM is a purely open-source software. It can be adapted to almost all networks and all end systems. You can think of CzechIdM as a powerful engine wrapped in a set of forms, workflows and rules.

Continue reading