Contents


Authorisation using SSL client certificates with IBM Integration Bus V9

Comments

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


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

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