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.


.