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! :)


.

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!


.

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.


.

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.


.

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.


.

This certificate has been revoked

Yesterday, I received a message from my customer. He told me that his users complained that they were not able to log-in to their system, which is protected by ForgeRock OpenAM. 

The error on the Login Page showed "This certificate has been revoked". 

I had my Systems Consultant take a look at the issue. There is this website that check the Revocation Lists (CRL) and the OCSP status of an (SSL) Certificate.   

One has to only key in https://certificate.revocationcheck.com/xxx.xxxx.com and the result will be shown.

We can also use openssl command line to find out more.

In short, nothing wrong with OpenAM. The issue was routed to their Network team instead. False alarm.

.

Long-lived access token from Facebook - Change in response format

I blogged about OpenAM : How to exchange for a long-lived access token from Facebook? some time back.

I had this implemented for a customer who is still on OpenAM 11 and integrating with Facebook via Graph API version 2.0. Facebook Graph API is already v2.8

Recently we re-configured OpenAM to update the Facebook Graph API to v2.8. I realized we can no longer retrieved long-lived access token from Facebook.

The codes used to look like:

              // Need to strip: 

              //    e.g. access_token=[LONG-LIVED-ACCESS-TOKEN]&expires=5148647
              longLivedToken = longLivedToken.substring(13,longLivedToken.indexOf("&"));

It was returned as a String.

In Facebook Graph API to v2.8, the response format has been changed to JSON.

.

Request not valid, perhaps a permission problem

It has been a while since I last blogged. So I took the family to Taiwan for a holiday the last 2 weeks of December. Never sick of Taiwan. :)

Took part in a half-marathon before flying out the same day. Awesome race!

Back to work ... I was trying to set up an environment similar to that of my customer to debug an issue. We needed Facebook authentication, so that's my 1st step in getting the environment up.

Customer is still on OpenAM 11, while Facebook Graph API is already v2.8. The old way of configuring Facebook authentication module in OpenAM no longer work. Change log here.

Today, I was not lucky. Hit into "Request not valid, perhaps a permission problem" right away.

The error message on the browser wasn't helpful at all!

 
I tried looking at the debug logs by setting to MESSAGE level. Saw "Parameters code or activation were not present in the request". Not helpful either!

After trying to figure out what was wrong for a while, I accidentally clicked on the address bar. Bingo! (Safari hid the whole URL with error message from facebook!!)

http://XXX.cdemo.sg:6080/amserver/oauth2c/OAuthProxy.jsp?error_code=100&error_message=Invalid+Scopes%3A+read_stream.+This+message+is+only+shown+to+developers.+Users+of+your+app+will+ignore+these+permissions+if+present.+Please+read+the+documentation+for+valid+permissions+at%3A+https%3A%2F%2Fdevelopers.facebook.com%2Fdocs%2Ffacebook-login%2Fpermissions#_=_


So read_stream scope has been deprecated. Removed it from OpenAM and I could proceed to my next step.


.

OpenAM Web Policy Agent 4.1 released!

Over the weekend, OpenAM Web Policy Agent 4.1 was released.

There are a number of new features in 4.1:

1. Improved Logging and Caching.
2. New JSON-Formatted Response Properties.
3. New Garbage Collector Statistics Log.
4. 32-bit and 64-bit Web Policy Agent Package for IIS.
5. Added Support for Windows built-in Secure Channel API.
6. Relative URL Support in Access Denied Property.
7. The agentadmin Command Now Returns Status Codes on Failure.
8. Added Support for PKCS#12/PFX Client Certificate Files

There are many more key fixes in 4.1. I just counted - a total of 78 key fixes. Do also note of the known issues in 4.1.


The behavior of Web Agent 3.x and 4.x is different, as what I have recently encountered in a customer's site. If one is to upgrade from version 3.x to 4.x, please do remember to test, test and test.

In our case, there is an edge case which was not tested in Devt. We had to rollback in Prod the day the new agents were deployed.


.

Authorization without Policy Agent

So I received an email from a customer today - "Are there any where to provide authentication and authorization without having to install Policy Agent?".

There is now a trend to deploy applications on the cloud. In such deployment, customer does not want to install Policy Agent there. As such, the question was raised.

My response:

Without Policy Agent, if the applications are customizable, they can utilize the OpenAM REST APIs. This is quite common these days. I have another customer that has zero Policy Agent installed in their environment.

https://backstage.forgerock.com/docs/openam/13/dev-guide#rest-api-ssotoken
https://backstage.forgerock.com/docs/openam/13/dev-guide#sec-rest-authz-policy

.

OpenAM Web Policy Agent 4.0.1

I was helping a customer to debug an issue with Web Policy Agent and I decided to download the latest WPA 4.0.1.

I observed some improvements.

1) Version message is clearer now.

It used to be:

2) Agent configuration directory has changed.

It used to be:
/home/azlabs/opt/web_agents/Agent_001/config/

Now, it is located at:
/home/azlabs/opt/web_agents/instances/agent_1/config/

3) Old properties files are removed with a single configuration file.

agent.conf now replaces

• OpenSSOAgentBootstrap.properties
• OpenSSOAgentConfiguration.properties 

See full Release Notes here. 

.

OpenAM Policy Agent Configuration (since v12.0.0)

If you are migrating policy agent configuration from a version earlier than 12.0.0, do take note that you need to fill in Realm and Application in Policy Client Service section.

The following is the release note from OpenAM 12.0.0. It applies to version 13.x.x.

Now, OpenAM 13.5 behaves a little different from 12. (I'm not too sure of v13.0 as I skip that version totally)

In OpenAM 13.5, there is this concept of Policy Set whereby you need to key in a Policy Set ID and Policy Set Name. Policy Set ID is hidden most of the times after initial setup.

However, when you configure Policy Agent and you need to fill in the Realm and Application, you need to be careful.

Application refers to Policy Set ID, not Policy Set Name.

Confusing isn't it, since Policy Set ID is hidden unless one clicks on the Details tab?

It's also a bit confusing that one section of the console keeps using Policy Set and Policies, while the other section keeps using Application, when they are supposed to mean the same thing.

Documentation might help a little, except they contradict slightly. 

Anyway, what will you observe if you hit into this issue?

On the frontend, this is what will be thrown:

This is especially not helpful. Reminds me of SiteMinder integration. :) One will be shown the same Internal Server Error for every possible error that can occur. Ha!

On the backend, this is what is being captured in the logs:

org.forgerock.audit.events.handlers.writers.RotatableWriter:08/23/2016 11:00:33:052 AM SGT: Thread[CsvHandler,5,main]: TransactionId[17960893-bd4e-4da2-ab8b-369a360d5a28-58]

Actually writing to file: "17960893-bd4e-4da2-ab8b-369a360d5a28-736","2016-08-23T03:00:33.051Z","AM-ACCESS-OUTCOME","17960893-bd4e-4da2-ab8b-369a360d5a28-734","id=oneaccess,ou=agent,dc=azlabs,dc=sg","[""9b54bd2abc7e586601""]","idp.azlabs.sg","443","192.168.XX.XX","41971","PLL","REQUEST_GET_RESOURCE_RESULTS",,"true","POST","https://XXX.XXX.sg/openam/policyservice","{}","{""accept"":[""text/xml""],""host"":[""XXX.XXX.sg""]}","{""amlbcookie"":""01""}",,"FAILED",,"{""reason"":""Evaluation error.\nUnable to retrieve application under realm /.\nUnable to retrieve application under realm /.""}","17","MILLISECONDS","Policy","/"

A little bit of getting used to. Otherwise, we're good to go for OpenAM 13.5! :)


.

OpenAM Security Advisories #201605

Just came back from Sydney last night. Attended ForgeRock Identity Summit, Unconference and 2 days of Partner Training. Over-loaded with new knowledge. :)

Not forgetting met up with old friends... Oh ya... and tons of beer! :>

Back to serious topic, ForgeRock announced security advisories middle of this week. The products impacted are OpenAM, OpenIG and OpenIDM.

The following is a summary of the issues found in OpenAM which I quickly sent out to my customers.

Details can be found as follows:

1. OpenAM
2. OpenIG
3. OpenIDM

Paid customers can download the patches from Backstage. Head over there quick!


.

OpenAM Console Legacy UI / XUI

So I have started playing with OpenAM 13.5 and I always have strong opinions on the UI as they undergo "progressive revamp". I do not personally like "progressive" changes as the user experience sucks... big time...


The legacy UI used to look like this...

The XUI now looks like this ...

Configure and Deployment in XUI are expanded from the Configuration in legacy UI.


Let's try navigating from left to right in OpenAM 13.5. (I would think 13 has the same UI experience)

1) Realms will bring you to the following screen. Looks pretty.

2) Configure allows you to modify Authentication, Global Services and Server Defaults. These used to be found in Configuration tab.

3) Deployment allows you to configure Servers and Sites. These used to be found in Configuration tab as well. Everything looks good so far.

4) Bomb! When you click on Federation, you'll be redirected to the legacy UI.

5) The same happens to Sessions.

Let's look further into what happens underneath Realms.

The following is from legacy UI.

In XUI, every sub-menu has been moved to the left. Looks clean!

Now, let's try to navigate from top (Dashboard) to bottom (Scripts), in sequential order.

This is one crappy user experience! The navigation journey sucks big time!

Now, maybe I'm just too picky... but what about this?

Let's say I'm right now at Dashboard in Top Level Realm.

I now want to go to configure Data Stores.. well, I'll be redirected to the legacy UI... ok .... so be it..

And let's say I'm done with configuring Data Stores, I'll want to go back to where I came from. From donkey years ago, I have been using "Back to Access Control", as this clearly implies to me that this is the way to navigate back.

Bomb!

Hello, I did not came from the screen above. I was inside Top Level Realm. I need to go back to this screen instead.

Enough? Not really ... I navigate to Deployment > Servers, as I know there is now UMA support in OpenAM. I want to know more about how it is being configured.

See anything interesting above? :)

Yes, Chinese language was shown in General, Security, Session, SDK and Directory Configuration. No issue with CTS, UMA and Advanced. 

I checked my browser language. EN-US. *strange*

This "weird" user experience will be here for a while... I do not know when the whole revamp will be completed. Meanwhile, what can you do? Nothing. 

.