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. 

.

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. 

.