Just a reminder ...

In today's news, 77th Street has announced that it will end its business. Its last shop will close by end of July. 

Founded in 1988, 77th Street was popular among youngsters for its range of streetwear and accessories. Its first outlet was a small shop at Far East Plaza. At its peak, the streetwear chain had 16 stores across Singapore.

"Well, you know, the dream during that time was to open up to 24 or 30 outlets all around Singapore. The rental was then affordable. But as the rental became higher and higher and higher, we find that we're just working for the landlord to pay off the rental,” said the founder.

On the other hand, a convenience shop that sells bargain products near my house has also just decided to call it a day.

It's a timely reminder for my team - Azimuth Labs is .com, but not .org. We are not a charitable organization.

We usually avoid getting into a price war.

Some customers, especially those in this region, have no perception of what they should pay for getting specialist services. They compare us with generic coders/developers that can be found everywhere. The further they source, the cheaper they get.

Some even behave like what they'll do when they go to a wet market.

Sometimes, when I quoted a Change Request for 5 MD (we do not practice putting in buffer in our quotations), they'll negotiate for 3 MD. Other times, when I told them a Change Request is required for certain configuration change which is not quoted in the signed-off SOW, they'll argue that there shouldn't be any additional charge because "no code change what. only configuration change. click, click, click only".

My usual response will be: "Oh, then you do it yourself."

I always illustrate this to my team with "General Practitioner (GP) vs Heart/Eye Specialist". What you pay is what you get. If you are strong enough to not go to a specialist due to the high cost involved, so be it. It's your health. Do not complain if your health deteriorates. But if you do decide to pay a visit to a specialist, you need to pay him/her what he/she is worth.

As simple as that.

PS: In this region, even when I hold my head high up telling people "I am a specialist". They will laugh it off. People who are into IT are not well respected here. This is life. :)




 .

Connectors for Identity Provisioning

We have an intern working for us before he reports for National Service next month. So we gave him some exploration tasks, one of it being to automate our onboarding process using OpenIDM.

New staff on boarding procedures for our office:
1. Create an AD Account
2. Create Zimbra Email Account
3. Create VPN Account
4. Create SVN Account
5. Create Helpscout Account
6. Create Slack Account
7. Create JIRA User
8. Add user to Google calendar

Simple task. Should be able to finish within a month.

No.

Tasks like creating a Zimbra email account, VPN account and SVN account are command-lines operations, thus we need a SSH connector. Took a quick look at https://forgerock.org/openicf/docs/connectors/. Happy! We thought we can workaround with the Solaris Connector.

But no again... the link was broken.

Raised a ticket with Support and was told a new SSH Connector is going to be released soon for OpenIDM 4.0.

Before that happens, what can we do? Generate a flat file using CSV Connector; Run a script to execute the commands on target systems. Less than ideal.

So sometimes, things like this do happen. When you look back the design after implementation, you would like : "OMG! What the hell? Who did that?" Mostly not asking what was the limitation when a design decision was made.

Side track a bit... So we were looking deep into RSA Via Lifecycle & Governance. One thing we like about their architecture was a Mulesoft engine was embedded, which provides the connectivity to external systems. Mulesoft has tons of connectors out there (https://www.mulesoft.com/exchange#!/?types=connector). Ok, not all are Mulesoft-certified, but I would think if one is certified, it would also mean the cost will be different. :)

So, one of my Identity Specialist went crazy and wanted to integrate OpenIDM with Mulesoft. It has what we want - SSH, Slack, JIRA.

Will try. :)

.

Token for Application Access

When dealing with CA API Gateway (aka Layer 7) and CA Single Sign-On (aka SiteMinder), especially how to gain access to the backed protected applications, one has to differentiate the types of token required.

CA API Gateway accepts OAuth2 tokens, while CA SiteMinder traditionally accepts SM Session cookies.


In the mobile world, if there is a hybrid app that needs to communicate with an API-enabled application behind CA API Gateway and with a web application behind CA SiteMinder, it would be easier if both PEP (Policy Enforcement Point) "talk" OAuth2.

It saves the application developers time to handle SM Session cookies.

Is this achievable? Yes, a bit painful.

1) Need a new authentication scheme on SiteMinder to act as OAuth2 client.
2) This OAuth2 client needs to communicate with an OAuth2 Provider, which is the CA API Gateway

* Note: CA SiteMinder cannot act as OAuth2 Provider. Mobile deployment aside, if one has a pure web deployment and requires OAuth2 integration, CA SiteMinder is not able to fulfill the requirement singly. It has to integrate with some other OAuth2 Providers out there.

If customers choose to have everything under the same family, CA API Gateway will satisfy the need. However, it would be a real white elephant if there is no API Management requirement. :)

By the way, my team tested. CA SiteMinder OAuth2 authentication scheme is able to integrate with OpenAM whereby OpenAM acts as the OAuth2 Provider. Works like a charm!

.

Expired CTS Token not cleaned up in OpenDJ

Just came back from a short holiday to Perth. Winter time, so weather was super good!

During the trip, good news come one after another. Today, the greatest good news arrived! The 2nd half of this year will be super busy! :)

Anyway, back to the topic ....

In a clean-up exercise which happened prior to my holiday, we realized expired CTS tokens were not cleaned up in OpenDJ for one of our customers' deployment. OpenAM 11.0.2 was deployed.

From the graph above, it is very obvious that whenever OpenAM is restarted, expired CTS tokens will be cleared up nicely by a Java class in OpenAM - CTS Reaper. However, there is an issue with this class and thus subsequently, expired CTS tokens keeps building up.

I raised a support ticket with ForgeRock and received a prompt response:

I think the more likely culprit for this could be: OPENAM-3283 If so, upgrading to 11.0.3 will resolve this. .... You could diagnose this further by looking at the Session debug log, and also at the CTS Reaper behaviour in your OpenDJ access logs. If you're seeing OPENAM-3283, you would see the CTS Reaper searches (by default once per minute) stop occurring in the access logs. You may also see an exception in the Session log. With full message level debug logging you would be able to see that the CTS Reaper is no longer waking up.

Once I patched OpenAM to 11.0.3, the graph becomes "stable" for the past few days. And it will be for subsequent days to come. :)

PS: Support ticket was raised on 17th May. Response and resolution were given within 2 hours. The graph was for production which I was not given the green light to patch until 11th June.

Personally, I have deal with Support teams from various product principles. Most will route you to a Call Center (some are even outsourced). So the original tickets will then be routed to backend Engineering. This takes forever to resolve an issue. And by the way, before they route you to Engineering, they'll read the product documentation first to determine if your configuration is supported at all. OMG!

ForgeRock Support never fails my high expectation. These guys are awesomely technical. Thank you!