Password Meter

We have been in the Security & Identity business for a long time. Recently, we have been engaged in a number of Identity Management projects in the Asia region.

In some projects, we build our own Access Request Portal on top of Identity Management products out there in the market.

Reason is simple - To Increase User experience!

From our observation, some IDM products are just too complex, too heavy; some IDM products lack features required by customers.

And since more and more IDM products are exposed by REST, it makes it compelling to build our own Access Request Portal.

We build a Access Request Portal that is lean and fast. No unnecessary features just to make Gartner happy. (You don't agree? Ha! )


In one of our projects, the CIO took a look at the User Profile tab and explore how we build the Password module. He didn't like what we have built. He has a strong view on what is a Strong Password. He even sent my team this to read up - Science Can Help You Choose a Better Password. Complexity isn't as important as you think.

So we stripped the original Password module and incorporated Password Meter.

Password Meter is pretty cool. It will "score" your password quality as you type in and give you advice immediately.

My team did it better! As Password Meter is open-source and published in GitHub, we enhanced it to support multi-languages.  

What's next is for the team to tidy up the sources and offer them back to the community.

That's the beauty of open-source! Some just don't get it. Money is never enough. 

.

One Identity Manager - Access Request History

Having implemented numerous IDM projects and seen multiple IDM products, all will provide a Access Request History view in a table format.

Besides providing the default table format, One Identity Manager provides a timeline view. 

Important feature? No. Wow feature? Yes, indeed. I like it a lot personally.

. 

Tyk API Designer

I was playing around with Tyk API Designer the other day and I noticed there are 2 ways to edit an API - API Designer or Raw API Definition.

  

API Designer View

Raw API Definition View

I'm not too sure you belong to which camp. I have team members who belong to both camps. The juniors will definitely prefer the API Designer view, while the seniors will go for the Raw API Definition view.

When we go to customers' sites, it's quite obvious. Customers will prefer API Designer view, while my team will most likely configure using the Raw API Definition view, especially when there are a lot of APIs to configure.


That's cool!

.

Data-model driven API - Good or Bad?

I came across this blog from Tyk - Your data model is not an API, while I was lying on my bed ready to sleep. 

To me, this is taking a dig at CA Live API Creator. :)

Very insightful article, indeed. This is coming from API consumers' (Customers) perspective, rather than from API developers.

Sometimes, we keep forgetting who our pay-masters are. This is why I keep reminding my team - they have to make our customers happy, not me.


I totally agree with the conclusion:

• Your API consumers want an API that is familiar to them, not to your implementation team 
• Your API consumers want an API that is fast to integrate for them, not for your internal team to implement 
• Your API consumers want an API that is flexible by offering capabilities to get things done, without creating lots of HTTP calls and stitching data together to achieve their desired outcomes 

Finally, it is important to remember that 5 hours saved by your team may cost 10s to 100s of hours by your API consumers. ... A great API design makes it easy for API consumers by hiding internal implementation details, leading to faster integration and happy developers.

It is definitely not easy to design an API.

From our experience with a large insurer in Singapore, we know it could take weeks to design a useful API. Sometimes, we could end up having heated arguments with our customer's application teams, because we do not agree with certain design methodology. But the end result is great! There's nothing wrong with disagreements, as long as it's for the good of the project.


.

Kong CE 0.13.0 - Services and Routes

Kong CE 0.13.0 has a new feature - Services and Routes.

The introduction of Services and Routes as new core entities. Those entities replace the “API” entity and simplify the setup of non-naive use-cases. They provide better separation of concerns and allow for plugins to be applied to specific endpoints.

With the introduction of Services and Routes, duplicates plugin definition can be avoided.

This is much cleaner and leaner in operation, especially if we are talking about tons of APIs in the micro-services world. Detailed read here.



.

PAM ranking in Kuppercole

During meet-up with customers, when we introduce One Identity PAM (either the older TPAM or the newer SafeGuard), we'll more than likely be directed to this following ranking. The one below is from Kuppercole. Some customers use Gartner.

In any case, One Identity ranking for PAM is not fantastic, especially for SafeGuard as it is a total rewrite. It is primarily due to the fact that the product line for TPAM is aging. With SafeGuard, you can add in REST, Analytics and more importantly, sexy UI. (Have you used TPAM before? Oh man, the UI is shitty! But honestly, it works like a charm!)

Interestingly, One Identity bought Balabit (https://www.balabit.com/) few months ago. The session recording feature in SafeGuard is OEM from Balabit. With Balabit under the umbrella of One Identity, more features from Balabit will be added to SafeGuard. The most exciting one will be Privileged Account Analytics.

Let's see how will the ranking be in a year's time! :)

.

APIs Design, Development & Management

I have forgotten where I have captured this diagram, but it really reflects the truth on the ground.

90% of APIs rely on developers to code! Of which, 60% rely on developers to create and manage their own APIs. Only a tiny 23% did developers use a proper API Management tool to create and manage their APIs.

There is still a big market for API Management tools.  :)


.