NetIQ CloudAccess – How to create Authentication Filter in Java and use HTTPS

NetIQ CloudAccess (or NCA) is a neat service offered by NetIQ in a form of ready to deploy appliance that helps users securely access web applications. It is much less complex then any full blown Access Management solution and intended for SaaS applications but works as well with all SSO enabled applications talking SAML or OAuth. Taking NetIQ Access Management solution reputation into consideration this product is definitely worth looking at for a less complex SSO scenario.

One of the features offered by NCA is an Authentication Filter Tool. For me the name isn’t self-explanatory. At first, after just glancing at the documentation, I had an idea this functionality is intended for forwarding authentication from NCA to other, more knowledgeable, system. This system would then make authentication decision and tell NCA to authenticate user or not. Later I was required to provide a solution for enriching user identity information with data from other database then Identity Source and then use this additional attributes in assertions. Thankfully I was pointed to Authentication Filter functionality by NetIQ experts and now I would like to share my findings.

To clarify things: Authentication Filter tool is executed during the authentication process and allows you to apply extended functions to add, remove, or manage user’s identity information for the NCA session.

Authentication Filter Tool is described in very detail in NetIQ documentation found here. With this post I would like to extend this description with ready to use example of Authentication Filter implementation in Java.


The use case

NetIQ CloudAccess
The use case

Figure 1 Description of desired scenario

The diagram above depicts desired scenario for the middleware Authentication Filter. To illustrate Authentication Filter possibilities I decided to make it query LDAP database for additional user data and add it to xCustom1 attribute in NCA. This attribute will be then used in SAML assertion.

The whole demo environment will exist of following components:

  • NCA as the Identity Provider (IdP) for SAML based SSO,
  • SimpleSAMLphp as the Service Provider (SP) for SAML based SSO,
  • Tomcat application server running Authentication Filter servlet,
  • OpenLDAP serving additional user data.

I will not cover steps necessary to configure NCA, SimpleSAMLphp or OpenLDAP components in detail. This article will only cover Authentication Filter part.


The solution

NCA communicates with Authentication Filter using JSON messages over HTTP, this is why I decided to deploy it as a Servlet running on Tomcat. This servlet listens for POST HTTP messages. I found out that NCA sends two types of requests:

  • health check – short POST message sent every 5 minutes containing a simple JSON {“API”:{“version”:”0″,”type”:”health”}};
  • user authentication request – POST message with details on the user being authenticated, sent every authentication;

therefore I had to prepare my application to respond properly to both of this types of requests. To parse and format JSON I decided to use json-simple.

After installing Tomcat 7 I configured my Eclipse IDE for hot deployment and developed my simple application. It consists of one class:

 

In above code I determine if this is authentication request (comment nr 2) not a health check by peeking into JSON request (comment nr 1) and looking for “UserName”. If this string can be found then I use information from request (comment nr 3) it in an LDAP query (comment nr 4) and save what I found in JSON response (comment nr 5), which is then sent back to the requester. In any other case (comment nr 7) servlet just responds with 200 OK, which is good enough for health check and testing purposes.

I went to my simpleSAMLphp authentication test which redirected me to NCA, logged in to NCA with my Identity Source’s username and password and voila, the AdditionalInfo representing XCustom1 attribute value was in the assertion. I was super happy.

mlk_20150813_2Figure 2 All attributes in their place

This all was easy to set up, but then I decided I want to use SSL. Also NetIQ documentation suggests: “Use HTTPS for secure SSL transfer of information. If you use an HTTP URL, information is not secure”. So I configured my Tomcat to use a self-signed certificate according to apache documentation … and my solution stopped working – I couldn’t login to NCA anymore. Helpful NCA log told me:

java.security.cert.CertificateException: Untrusted Certificate-chain

So I had to make NCA trust my certificate. Not so simple to do, when this is an appliance and I have no access to truststore database. I tried to find a solution for this problem in the documentation but failed. Thanks to helpful NetIQ support staff I was pointed to changing NCA certificates to certificates signed by the same CA as the one used by Authentication Filter servlet. This sounded promising so I went through the fuss of creating my own CA and two certificates – for Tomcat and NCA. Thankfully after applying both certificates the whole solution started working again, but now in a more secure manner.

Never miss an update by following us and subscribing to our monthly newsletter!

Summary
NetIQ CloudAccess - How to create Authentication Filter in Java and use HTTPS
Article Name
NetIQ CloudAccess - How to create Authentication Filter in Java and use HTTPS
Description
NetIQ CloudAccess (or NCA) is a neat service offered by NetIQ in a form of ready to deploy appliance that helps users securely access web applications.
Author
Publisher Name
Atos Consulting CH
Publisher Logo

One thought on “NetIQ CloudAccess – How to create Authentication Filter in Java and use HTTPS

  1. Pingback: SailPoint Partnership - Atos Consulting CH

Leave a Reply

Your email address will not be published. Required fields are marked *