Integrating JBoss with Open DS

Integrating Open DS for use with JBoss

This article looks at how you can use Open LDAP to authenticate users in JBoss. This article takes you through the steps required to secure the JBoss JMX console using OpenDS.

Author
Steve Millidge is the founder of C2B2 and is an expert in the security configuration and integration of JEE application server.

Open DS is an open source LDAPv3 server written in Java and released as open source by Sun. OpenDS can be used to provide a centralised authentication service for JBoss. Out if the box JBoss uses properties files to configure usernames, passwords and roles. This can become unwieldy and difficult to manage in a large JBoss system with multiple JBoss instances.Using OpenDS to storedetails about your users and their roles will provide a central repository which all the JBoss nodes can refer to to authenticate users and retrieve their roles.

Installing OpenDS

Installing OpenDS is straight forward.

• Download the OpenDS zip file from OpenDS.org 
• Unzip the installation on your filesystem e.g. C:\opends
• Run setup and a GUI utility starts to walk you through the installation 
• 

• Next step set your password for the admin user
  In our case we used password
  
  
  
• Create the Directory Base DN appropriate for your server, typically similar to your company domain name
  
  

• Review your settings
  
  
  
  Once you click Finish the Open LDAP directory server is installed and you can click on the Launch Control Panel button to start creating users and groups.
  

Creating Users and Groups

If you've followed the instructions above click on the "Launch Control Panel" button to fire up the LDAP control panel. Alternatively look in the bin (Linux) or bat (Windows) directory of your OpenDS and run control-panel(.bat). This will start up the LDAP control panel. Once it starts you will be asked to login to OpenDS using the password you entered during the installation.

The you will be presented with the OpenDS control panel.

Within the Control Panel select Manage Entries to bring up the LDAP browser.

Now we need to create two organisational units one to hold the Roles and one to hold the Users.
Now select the base DN as shwon and right click and choose "New Organisational Unit..." and create an Organisational Unit with the Common Name "Roles" and a second Organisational unit with the Common Name "Users".
These Units will hold our roles and users respectively and will be queried by JBoss to authenticate the user and find their roles.
Now we will create the JMX console admin user and Role.

Right click on the "Users" unit in the Manage Entries screen and choose "New User..." from the menu,

Fill in the user details as follows;

The Common Name entry is key as this is the username the user will use to log in to JBoss.
Right click on the "Roles" Unit in the Manage Entries Control Panel. Select "New Group..." from the menu and give the group the name "JBossAdmin" leave all the other entries in the dialog at their default but click on the Add Members... button andselect the admin user we created earlier.

We have now finished our LDAP configuration. We have created the JBossAdmin group and added the admin user as a member of the group.

Configure JBoss Authentication

We are now ready to configure the JBoss administration console to use Open DS to obtain user names and passwords.
JBoss has a very configurable security infrastructure which supports many different authentication realms. Out of the box the JBoss security configuration is in the file /conf/login-config.xml.

Open this file and find the entries for the jmx-console. It should look something like by default

this is using the properties files to define the users and groups in JBoss.
We need to change this configuration to use the LDAP Authenticator.
The LDAP authenticator module we want is org.jboss.security.auth.spi.LdapLoginModule as this will retrieve the authentication details from the LDAP server. This module however needs to be told where to look in the LDAP server to find users and roles. This is configured by a number of key module options;
First we need to tell JBoss how to find the user in LDAP from the username entered by the user when prompted. The two options which do this are;

principalDNPrefix which adds a prefix to the username typed by the user. For OpenDS this should be cn=
principalDNSuffic which adds a suffix to the username typed by the user. For our setup above this should be,ou=Users,dc=c2b2,dc=co,dc=uk The exact value will depend on the base dn you entered when installing OpenDS

We also need to tell JBoss where to find the Roles for a user. We do this with the following two module options

rolesCtxDN tells JBoss what branch of the LDAP server to look in for roles. For our configuration above the value of this should be; ou=Roles,dc=c2b2,dc=co,dc=uk
uidAttributeID tells JBoss which attribute within the Group object holds the members. For OpenDS this should be set touniqueMember
roleAttributeID tells JBoss which attribute of the group corresponds to the Role name in this case this should be cn which is short for Common Name

Additional entries need to be set to tell JBoss how to connect to the LDAP server. The completed entry for the jmx-console should look like.

    <application-policy name="jmx-console">
    <authentication>
        <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="required">
            <module-option name="java.naming.factory.initial">
                com.sun.jndi.ldap.LdapCtxFactory
            </module-option>
            <module-option name="java.naming.provider.url">
                ldap://127.0.0.1:389
            </module-option>
            <module-option name="java.naming.security.authentication">
                simple
            </module-option>
            <module-option name="principalDNPrefix">cn=</module-option>
            <module-option name="principalDNSuffix">
              ,ou=Users,dc=c2b2,dc=co,dc=uk
            </module-option>
            <module-option name="rolesCtxDN">
                ou=Roles,dc=c2b2,dc=co,dc=uk
            </module-option>
            <module-option name="uidAttributeID">uniqueMember</module-option>
            <module-option name="matchOnUserDN">true</module-option>
            <module-option name="roleAttributeID">cn</module-option>
            <module-option name="roleAttributeIsDN">false</module-option>
        </login-module>
    </authentication>
    </application-policy>

Once you have edited the login-config.xml jmx-console section to look like above. Restart your JBoss server.
You should now be able to browse to the JMX console and login using the credentials configured above.

Conclusions

We have seen how easy it is to secure the JBoss console using OpenDS. Although we have only secured the JMX console the same principals can be used to secure all the different subsystems in JBoss.

Transactions in SOA

This short article looks at options available for implementing transactional behaviour in service oriented systems.

What is a Transaction?

In modern systems, with data and processing distributed across numerous physical nodes, transactions are one of the ways of co-ordinating data and processing into a single 'unit of work' that either succeeds or fails together. This is done to ensure that the data is always in a consistent state across the whole system. The traditional example of this approach is a bank transfer, where you want the money to be taken from account A and placed into account B, or not to be taken from account A and not placed into account B. Transactions are often referred to as having the ACID properties, that is, Atomic, Consistent, Isolated and Durable.

Java EE has standards based interfaces (JTA) for the demarcation and management of transactions, with in an application and across application or system boundaries.

Due to their universal availability in application servers, transactions get used for different purposes in different applications, in some cases, end-to-end, guaranteed, data consistency is the goal, wheras in other systems the objective is guaranteed delivery and processing. In these situations, it is only a subset of the ACID properties that are required by the applicaiton, but the ease of configuring a fully ACID transcation means that it is easier to obtain them all.

Transactions in SOA

Using a Service Oriented Architecture introduces a number of challenges when dealing with operations that need to occur in a transactional manner. SOA Best practices encourage the use of asyncronous services, which do not mix well with the tight coupling used in transactional systems. In addition, while there are a number of protocol-level technologies available for transactional behaviour, there are no standards or technologies for end-to-end transactions in an SOA system. In addition, existing technologies for describing the interfaces between components in an SOA system do not have nice ways of describing the transactional behaviour of operations.


There are a number of techniques used to obtain transaction-like behaviour in service oriented systems, but before chosing an approach, or combination of approaches, it is important to understand exactly what the desired behaviour is, and which of the ACID properties are required in the particular application use-case.

Protocol level approaches

Using a transaction technology provided by the transport protocol, such as WS-Coordination, and other associated web services standards, can go some way to providing the desired behaviour, but there are limited integrations between these standards and SOA products such as ESBs. WS-Coordination is a technology that allows a number of web-services to come to an agreed decision regarding the outcome of an operation, and provides the building block for a number of transaction related web services standards, such as WS-Atomic Transaction and WS-BusinessActivity. Support for these standards in ESBs and other SOA technologies is currently very weak, but as SOA appraoches gain market share, we may see the support for these standards becoming more common, until then, these technologies do not provide a good method of implementing transactional behaviour.

For situations where only guaranteed message delivery/processing is required, then depending on the characterstics of the processing pipeline, using a reliable/transacted delivery protocol (such as JMS) can be enough. When doing this, you are relying on the transactional behaviour of the protocol though, and must ensure that it is configured for the correct behaviour.

Compensating Operations

The most common approach used to provide 'transaction like' behaviour to service oriented systems, is the use of compensating operations. In this approach, each operation that modifies state has a corresponding operation to undo that modification. The orchestration level on top of the services then needs to check that all operations succeeded. If an operation failed, the orchestration level should call the copensation operations on each service that did not fail.

This approach relies on the developers of the services and orchestration layers to specifically code for transactional behaviour, and can therefore be seen as a step backwards from the declaritive transaction demarcation that enterprse developers are used to. However this appr oach ensures that the behaviour is as expected, and in my view, having developers think explicitly about required transaction behaviour is no bad thing.

Conclusion

While there are a number of standards for transactions at the protocol level, no overarching standard has emerged at the SOA level. For this reason, the compensating operation approach is the most common approach seen in the current generation of service oriented systems, and while it is a more manual approach than declaritive transaction demarcation, having developers think about the desired transactional behaviour is not necessarily a bad thing.

Introduction to Application Performance Management (APM)

The Problem

Traditionally performance monitoring of client server based applications has focused on the underlying infrastructure, namely the servers, networks and databases, with basic memory and cpu utilisation of the applications monitored using the operating systems tools and in some cases by adding bespoke instrumentation into the application code to obtain more detailed performance metrics.

Organisations are implementing Service Orientated Architecture as a means of aligning their business with IT, and gaining greater business agility from new and existing IT infrastructure. This is resulting in more dynamic and globally-distributed services and infrastructures. While these technologies add significant value, they also add significant complexity to the monitoring and management of these environments.

Application performance management is increasingly becoming critical to monitoring and maintaining the health of the applications throughout the enterprise in order to maintain application availability and meet the required service level agreements with all the relevant parties. This requires a more holistic approach to application performance management which has led to a new breed of tools being introduced into application performance management.


APM Tools

The APM tools of today must provide detailed application profiling metrics in a production environment 24/7 in order to monitor and highlight potential performance issues before they impact on the business service being provided by the IT infrastructure. This must be achieved with minimum overhead so as not to impact on the performance of the applications they are monitoring.

Most application performance monitors gather information on applications by placing probes in key locations throughout the application code, typically before and after a method is invoked to determine the amount time spent in each method. By comparing measurements taken before and after the method's execution, for example, time and memory usage, we can gain an understanding of the individual method's impact on the overall performance of the application.

The process of inserting probes into the application code is called instrumentation. The two main techniques that are currently used by APM tool vendors are:-

• byte-code instrumentation which allows insertion of probes into the classes' and methods' binary code at run time as the classes are loaded. This technique removes the need to access the application's source code and thereby allows instrumentation of any Java application.
• JMX instrumentation the Java Management extension defines the architecture, design patterns, APIs, and services for application management and monitoring. JMX has been included in the Java SE platform since J2SE platform 5.0, and has been adopted by application server vendors in the development of their products.

Another important aspect of the APM tool is that it must be able to monitor across the entire stack, covering the network, server, OS, JVM, application server, application code and database in a single tool regardless of the operating system or deployment platform.
They must be able to monitor application performance against a timeline, storing the metrics in a database to enable the review of historical performance of the applications and environments. The ability to record and play back performance data is critical to better problem resolution, capacity planning, budgeting and application design.

Conclusion

Monitoring a variety of application metrics in production can help you understand the status of the components within an application server environment, from both a current and historical perspective. With careful planning and the right information at hand, proactive monitoring can help you quickly address performance related issues; if not help you avoid them altogether.

There are a number of APM products on the market ranging from open source offerings such as Hyperic HQ which provide monitoring capabilities to the more expensive commercially licensed products such as CA Wily APM and Dynatrace which also provide profiling capabilities across the whole application stack.