Thursday, April 6, 2017

Shibboleth SP - listener failed to initialize

I was trying to set up Shibboleth SP for a customer for POC.


And so I was playing around with configuration and then I tried to restart shibd process. I kept getting "listener failed to initialize".


Newbie to Shibboleth. Took me a while to find out that the process was killed, but the pid and .sock files are not removed.


Once both files are removed from /var/run/shibboleth directory, the shibd process is able to start successfully!


PS: By the way, the proper way to restart shibd process is:

[root@cdemo shibboleth]# /etc/init.d/shibd restart
Stopping shibd:                                            [  OK  ]
Starting shibd:                                            [  OK  ]

.

Thursday, March 23, 2017

OpenAM Login Page - Bad request error

I just started a migration for a customer who is still on OpenAM 10.2. Yes, my old-time customer who is still using the old JATO UI. :)

So, the deployment architecture is simply straight-forward. We have OpenAM 13.5 deployed on a Tomcat server and we have Apache HTTPd server acting as a reverse proxy. This is where we will tighten the rules for allowing/disallowing OpenAM endpoints from being exposed to the Internet.


Maybe I'm rusty, as I have been busy with other projects using other products. During setup, I kept hitting into issues - Bad request error and No values provided for the request parameter '_action'.






Anyway, after a long while investigation, then did I realized my reverse proxy setting on my Apache HTTPd server was configured wrongly! :)

Incorrect Setting


Correct Setting



So I forgot to add a slash to the URI.

ProxyPass /sso/ http://localhost:8080/sso/
ProxyPassReverse /sso/ http://localhost:8080/sso/


Silly me! :)


.

Wednesday, March 8, 2017

Integrate OpenAM 13.5 with Atlassian Jira 7.3 - Part 2

So I dumped OpenAM ClientSDK and decided to go the RESTful way. It turns out to be fairly easy.



References:

  1. Single Sign-on Integration with the Atlassian stack
  2. HTTP authentication with Seraph
  3. Sample code - OpenSsoAuthenticator.java 


Step 1: Extend OpenAMAuthenticator from JiraSeraphAuthenticator

I took reference from OpenSsoAuthenticator.java.

In public Principal getUser(HttpServletRequest request, HttpServletResponse response), there is this line that attempts to retrieve a user name.

String username = obtainUsername(request);


I removed all other methods in the class and replace the method obtainUsername(HttpServletRequest request) with the following:



Step 2: Copy JSON library (json-20090211.jar) to JIRA library directory
(As we are using RESTful calls to OpenAM to validate user's session, the response from OpenAM is in JSON format. Thus the need for the JSON library)

[azlabs@sg-jira ~]$ cp json-20090211.jar /appl/jira/jira/atlassian-jira/WEB-INF/lib/


Step 3: Extend log4j.properties
(If this is not configured, the logging will not be output to JIRA logging system - catalina.out)

[azlabs@sg-jira classes]$ vi log4j.properties
< # AZLABS
< log4j.logger.sg.azlabs.openam.jira.seraph.OpenAMAuthenticator = INFO, console, filelog
< log4j.additivity.sg.azlabs.openam.jira.seraph.OpenAMAuthenticator = false
< # EOF - AZLABS


Step 4: Edit seraph-config.xml to redirect to OpenAM Login/Logout pages

(This is where the iPlanetDirectoryPro cookie will be generated on user's browser after OpenAM Login authentication)

[azlabs@sg-jira ~]$ cd /appl/jira/jira/atlassian-jira/WEB-INF/classes
[azlabs@sg-jira classes]$ cp seraph-config.xml seraph-config.xml.20170308
[azlabs@sg-jira classes]$ vi seraph-config.xml














Step 5: Hide default Login gadget from JIRA login page
(The SSO with OpenAM only happens when a user clicks on the Login hyperlink. Keying in user name and password via the Login gadget should be removed to avoid confusion)

[azlabs@sg-jira ~]$ cd /appl/jira/jira-home
[azlabs@sg-jira jira-home]$ touch jira-config.properties
jira.disable.login.gadget=true

Step 6: Restart JIRA


We are done!


.





Monday, March 6, 2017

Integrate OpenAM 13.5 with Atlassian Jira 7.3 - Part 1


There is this very old wiki from ForgeRock that talks about how to integrate OpenAM with JIRA.

It used to work for us when we were using the older version of OpenAM Client SDK and JIRA. When I follow the same steps now with OpenAM Client SDK 13.5 and JIRA7.3, nothing works.

Some of the errors I encountered are listed below:

1) Loader constraint violation

Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/apache/catalina/loader/ParallelWebappClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of java/net/URLClassLoader) for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature

I needed to override the existing jar files in JIRA lib directory (/jira/atlassian-jira-software-7.3.0-standalone/lib) with slf4j-1.7.5.

[azlabs@sg-jira lib]$ cp /home/azlabs/openam/slf4j/slf4j-1.7.5/jul-to-slf4j-1.7.5.jar .
[azlabs@sg-jira lib]$ cp /home/azlabs/openam/slf4j/slf4j-1.7.5/slf4j-api-1.7.5.jar .
[azlabs@sg-jira lib]$ cp /home/azlabs/openam/slf4j/slf4j-1.7.5/slf4j-log4j12-1.7.5.jar .
[azlabs@sg-jira lib]$ cp /home/azlabs/openam/slf4j/slf4j-1.7.5/jcl-over-slf4j-1.7.5.jar


Still not working. In the end, I removed the SLF4J classes in ClientSDK-13.5.0.jar.



[azlabs@sg-jira tmp]$ rm -fr org/slf4j
[azlabs@sg-jira tmp]$ jar cvf ClientSDK-13.5.0.jar *



2) Different JODA versions

017-02-13 21:11:26,243 JIRA-Bootstrap WARN      [o.twdata.pkgscanner.ExportPackageListBuilder] Package Scanner found duplicates for package 'org.joda.time.tz.data.Africa' with different versions. Files: joda-time-2.8.2.jar and ClientSDK-13.5.0.jar.
      '/appl/jira/atlassian-jira-software-7.3.0-standalone/atlassian-jira/WEB-INF/lib/joda-time-2.8.2.jar'
      '/appl/jira/atlassian-jira-software-7.3.0-standalone/atlassian-jira/WEB-INF/lib/ClientSDK-13.5.0.jar'


Same thing: Removed JODA classes from Client SDK and re-jar again.

[azlabs@sg-jira tmp]$ rm -fr org/joda
[azlabs@sg-jira tmp]$ jar cvf ClientSDK-13.5.0.jar *



3) java.lang.ClassNotFoundException: com.iplanet.dpro.session.service.cluster.ClusterMonitor

Read in detail - OPENAM-9800.

Setting com.iplanet.am.serverMode=false did not helped at all. I went into extreme!!



I downloaded the OpenAM Core and copied to JIRA lib directory.

[azlabs@sg-jira tmp]$ cp openam-core-13.5.0.jar /home/azlabs/appl/jira/jira/atlassian-jira/WEB-INF/lib/


4) '/debugconfig.properties' isn't valid

This error message kept popping up. Quite annoying. To fix it is fairly simple.

[azlabs@sg-jira ]$ cd ../jira/jira/atlassian-jira/WEB-INF/classes
[azlabs@sg-jira classes]$ touch debugconfig.properties
[azlabs@sg-jira classes]$ vi debugconfig.properties

org.forgerock.openam.debug.prefix=
org.forgerock.openam.debug.suffix=
org.forgerock.openam.debug.rotation=


Overall, it was a painful experience. The worst part was when every "seen-able" errors were fixed, I was still not able to successfully redirected to JIRA home page after OpenAM Login Page authentication.

This was when I dumped OpenAM Client SDK totally and rewrote the codes using OpenAM REST APIs (See Part 2). The decision was made after reading OPENAM-9800 in detail.



Seems like Client SDK will become legacy pretty soon.. and I personally find it not too convenient to work with.


.



Tuesday, February 28, 2017

Gartner Magic Quadrant - IGA 2017

I woke this morning and received an email from SailPoint. It maintains as the leader in Identity Governance & Administration (IGA) market as named by Gartner for Q1, 2017.




Not a surprise for me to see SailPoint up there in the chart. 

What really surprised me is how RSA has been dropped from Challengers quadrant to Niche Players quadrant after being merged with Dell Technologies. As far as I know, there is no change to the product line. 

Another surprise is CA Technologies has managed to move from Visionaries quadrant to Leaders quadrant. This is largely due to 2 changes, from our own experience.


1) CA Identity Portal

This is a product developed by a company SIGMA recently bought over by CA. With this Identity Portal in place, the user experience has improved drastically.



The old UI looks similar to the one shown below. Sucks big time!



2) CA Identity Suite Virtual Appliance

The Virtual Appliance is a full-featured deployment of CA Identity Suite, pre-installed and pre-configured in a virtual machine image format. Installation is no longer needed.

If you have experience installing Oracle and CA products, you will know what I meant by "pain-in-the-xxx" during installation. Due to the complexity in the various components within the same product, installation takes forever and this eats into the professional service man-days. And overall, your total pricing will not be attractive!

The Virtual Appliance supports a variety of deployment options and is available from CA Identity Suite 12.6.8 CR1 onwards.


Note: I have not read the report in detail yet and have no idea how the evaluation was made. Above is my own personal experience using the 2 products. 

.



Friday, January 27, 2017

You don't have permission to access /openam/naming service

We have just migrated to the latest version of JIRA and I was trying to integrate OpenAM with it the other day via Openam Client SDK.

No issue with setup.

[azlabs@sg-jira openam]$ ./scripts/setup.sh
Debug directory (make sure this directory exists): /appl/jira/jira/logs
Application user (e.g. URLAccessAgent) password: XXXX
Protocol of the server: https
Host name of the server: XXX.azlabs.sg
Port of the server: 443
Server's deployment URI: openam
Naming URL (hit enter to accept default value, https://XXX.azlabs.sg:443/openam/namingservice):


However, when I tried to verify if the configuration was done properly by using the Login.sh script, my log-in was unsuccessful! I saw the following error in the debug log. This is the Client SDK debug log.

I received HTTP response code 403.



How can that be? Our OpenAM is in production and has been running for months with no down time. How can the namingservice be unavailable?

After a while, then I recalled that our Apache Reverse Proxy server was hardened to restrict certain OpenAM Service URLs from exposing to the Internet.


Oh well, I was the one who configured it back then and I couldn't remember. Ha!

After the new IP address was added, the Login.sh ran successfully.



It's a best practice to restrict access to URIs that you do not use, and prevent internal endpoints from being reachable over the Internet.. Have you done so in your deployment? If not, there's a section in OpenAM Administration Documentation - Secure OpenAM. Head over there for a read.


.

Wednesday, January 18, 2017

OpenDJ and OpenAM compatibility

Recently, due to the strict PDPA requirement from the PDPC (Personal Data Protection Commission Singapore), we are to ensure the user profiles stored in OpenDJ are kept totally safe. I blogged before that one of my customers was exploring Data at Rest Encryption Solutions from Gemalto. That was almost a year ago.

I met customer a month ago. I told him that OpenDJ Data Confidentiality feature can be enabled on a per database backend basis to encrypt LDAP entries before being stored to disk in OpenDJ 3.x. There's a blog by Ludo that explains the feature in detail.

However, customer is still on OpenAM 11.0.3. There might be compatibility issue.

Lucky am I. I just saw an article in ForgeRock Backstage.


Embedded OpenDJ



External OpenDJ



In short, customer cannot proceed to integrate OpenAM 11.0.3 with OpenDJ 3.5.


By the way, saw that last line? "It is strongly recommended that you always upgrade to the latest maintenance releases for whichever versions of OpenAM and OpenDJ you have deployed."


Yes, easier said than done. There is always a tech-refresh cycle and a cost attached to each refresh. It's really not as simple as upgrade to the latest release as and when it's available.


.