Authorisation using SSL client certificates with IBM Integration Bus V9

IBM Integration Bus supports SSL authentication, but often a check is required to determine if the client is authorised to access the requested resource. This article shows you how to authorise clients using a supplied SSL client certificate and LDAP.

Share:

Philip Norton (nortonp@uk.ibm.com), Software Engineer, IBM

Philip NortonPhilip Norton is a Software Engineer on the IBM Integration Bus Development Team at the IBM Software Lab in Hursley Park, United Kingdom. His expertise includes IBM Integration Bus, WebSphere ESB, Java, and JMS for WebSphere MQ. He is a certified Java Programmer and has a degree in Computer Science from Canterbury University. You can contact Philip at nortonp@uk.ibm.com.



10 July 2013

Also available in Chinese

Introduction

IBM® Integration Bus V9 introduces the ability to propagate client SSL certificate information into a message flow. This article shows you how you can use information stored in an SSL certificate to perform authorisation checks on a client, so that you can allow authenticated clients to access a specific subset of message flows. Topics covered include:

  • Enabling client certificate propagation
  • Accessing certificate information from within a message flow
  • Using certificate information for LDAP authorisation

Enabling client certificate propagation

To ensure that clients provide a certificate when they create an inbound connection, client authentication must be enforced. When using an HTTPInput node, the nodewide listener is used by default. It must have client authentication enabled, which you can do using this command:

mqsichangeproperties <node_name> -b httplistener -o HTTPSConnector -n clientAuth -v true

For SOAPInput nodes, the embedded listener is used by default. To enable client authentication, use this command:

mqsichangeproperties <node_name> -e <server_name> -o HTTPSConnector -n clientAuth -v true

To enable this property, the correct SSL key store and trust store configuration must be available to IBM Integration Bus. For details on how to configure SSL, see the article Setting up SSL configuration in WebSphere Message Broker.

To ensure that the client certificate is propagated into the message flow, the security profile set on the SOAPInput or HTTPInput node must have propagation enabled. To enable propagation on an existing Security Profile, use this command:

mqsichangeproperties <node_name> -c SecurityProfiles -o <profile_name> 
    -n propagation -v TRUE

If the SOAPInput or HTTPInput node does not have a security profile configured, then the IBM-supplied Default Propagation security profile should be selected. You can do this configuration from the BAR editor in the Integration Toolkit, as shown in Figure 1:

Figure 1. Default propagation security profile
Default propagation security profile

Accessing certificate information from within a message flow

The certificate information is stored in LocalEnvironment and can be accessed from LocalEnvironment.SOAP.Input.TransportSecurity.ClientAuth.Certificate or from LocalEnvironment.HTTP.Input.TransportSecurity.ClientAuth.Certificate. The full structure is shown in Figure 2:

Figure 2. Client certificate access from local environment
Client certificate access from local environment

You can access the information and manipulate it into the form required by the authorisation mechanism by using a transformation node such as a Mapping, Compute, or JavaCompute node. Listing 1 shows you how to access the certificate subject field and remove the attribute names to determine the user:

Listing 1. Java code to access client certificate
//LocalEnvironment/SOAP/Input/TransportSecurity/ClientAuth/Certificate/Subject
//or
//LocalEnvironment/HTTP/Input/TransportSecurity/ClientAuth/Certificate/Subject
String nodeType = 
    localEnv.getFirstElementByPath("Destination").getFirstChild().getName();

MbElement transportSecurityElement = 
    localEnv.getFirstElementByPath(nodeType+"/Input/TransportSecurity");

if (transportSecurityElement != null) {
  MbElement clientAuthElement = transportSecurityElement.getFirstChild();

  if (clientAuthElement != null) {
    MbElement certificateElement = clientAuthElement.getFirstChild();

    if (certificateElement != null && 
        "Certificate".equals(certificateElement.getName())){
      MbElement subjectElement = 
        clientAuthElement.getFirstChild().getFirstChild().getNextSibling(); 
      String subject = subjectElement.getValueAsString();

      if (subject.indexOf(",") != -1) {
        //Assume the subject is of the form CN=Philip Norton,OU=...... 
        //(as set in the X509 certificate)
        identity = 
          subject.substring(subject.indexOf("CN=")+3, subject.indexOf(","));
      } else {
        //Assume the subject is of the form CN=Philip Norton 
        //(as set in the X509 certificate)
        identity = 
          subject.substring(subject.indexOf("CN=")+3);
      }
    }
  }
}
//Store the manipulated identity in a new field in the LocalEnvironment
localEnv.createElementAsFirstChild(MbElement.TYPE_NAME_VALUE, 
    "IdentityToAuthorise", identity);

The example in Listing 1 stores the Common Name (CN) attribute from the full Distinguished Name (DN) defined in the client certificate into a new LocalEnvironment field called IdentityToAuthorise.

Using certificate information for LDAP authorisation

Once the required identity has been extracted from the client certificate, it can be used by a SecurityPEP node to perform authorisation. Add a new SecurityPEP node to the message flow, and then in the Properties view, set the Identity token type to Username and the Identity token location to an XPath that resolves to the location of the extracted identity, as shown in Figure 3:

Figure 3. Security token location on a SecurityPEP node
Security token location on a SecurityPEP node

The SecurityPEP node requires a configured Security Profile, which you can set using the BAR Editor, to enable the specified identity to be authorized using a directory service. You can configure the Security Profile to authorize against an LDAP server using either the mqsicreateconfigurableservice command, as shown below, or the IBM Integration Bus Explorer, as shown in Figure 4 below:

mqsicreateconfigurableservice <node_name> -c SecurityProfiles -o BluepagesProfile -n   
authorization,authorizationConfig,propagation -v 
"LDAP,\"ldap://bluepages.ibm.com:389/cn=UK,ou=memberlist,ou=ibmgroups,
o=ibm.com?uniquemember??x-userBaseDN=ou=bluepages%2co=ibm.com,x-uid_attr=cn\",TRUE"

This example uses LDAP to find a client by Common Name, and authorises them if they are a member of the group whose Common Name is UK. For more information about configuring LDAP and configuring Integration Bus security, see the article Implementing message flow security in WebSphere Message Broker V7.

Figure 4. Configuring the Security Profile to authorize against an LDAP server using IBM Integration Bus Explorer
Configuring the Security Profile to authorize against an LDAP server using IBM Integration Bus Explorer

If the user is successfully authorised, then the input message will be propagated to the out terminal of the SecurityPEP node. If authorisation fails, then the failure terminal will be fired.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=937268
ArticleTitle=Authorisation using SSL client certificates with IBM Integration Bus V9
publish-date=07102013