Goodbye Postini

We have been using Postini Message Security way before Google bought Postini over. It has been a long ride.

Comes Jun 2013, it's time to say goodbye. We are not keen to transit over to Google Apps Platform, so are our customers.

Hello, SpamHero. We have been running trial for 2 months. So far, we are satisfied with the services provided. Well, except that it is not able to filter ADV messages that well. (Postini has this feature where it can aggressively filter off any message that contains advertisement. I like that feature! Just me.)

.

Agent Session Idle Timeout

By default, OpenAM Policy Agent has an non-expiring token after it first authenticated with OpenAM server.

How do we change this value?

com.iplanet.am.session.agentSessionIdleTime


Nice.


. 

Changing Bind DN/Password in Directory Configuration

I blogged twice on how to port the embedded OpenDJ in OpenAM to an external OpenDJ. Meanwhile, I also discovered something weird when changing the Bind DN/Password in Directory Configuration.

Let's say you ignore the porting of the embedded OpenDJ to an external one. Let's only assume you want to only change the Bind DN and Password of the default "cn=Directory Manager" for security reason.

Ludo has a good article on how to create Multiple Directory Administrators. Of course, you can create a more restrictive proxy administrator for OpenAM. 



Now, if you are on OpenAM 10.0.1, then no problem. You simply change the default "cn=Directory Manager" and its corresponding password to one which you have newly created.

A restart of OpenAM will modify the bootstrap file to reflect the new Bind DN. (Of course, I still do not know when OpenAM will auto-magically modify the bootstrap file as-and-when changes are made via the OpenAM console; and when it will require a restart in order for the bootstrap file to be modified)

And now, we are done! That's OpenAM 10.0.1.


However, if you are on OpenAM 10.0.0, then no luck. Sorry. No matter how you change the Bind DN/Password via the OpenAM console, a restart of OpenAM will flush away the entries and replaced with the original ones. The bootstrap file is also not modified with the new pair of Bind DN/Password.


Why? I spent some time trying to figure out. In the end, I found out that the problem was with the LDAP update when entries are modified on OpenAM console.

I opened OpenDJ control panel and observed ou=com-sun-identity-servers, ou=default, ou=GlobalConfig, ou=1.0, ou=iPlanetAMPlatformService, ou=Services, ....

When I was modifying the entries in OpenAM 10.0.1, I did managed to see that the DirDN was changed from "cn=Directory Manager" to "cn=Admin2, dc=cdemo, dc=sg" when I clicked SAVE on OpenAM console.


Before

After

The same was not happening when I did the experiment on OpenAM 10.0.0. Do you have a clue? I dun.


.

Multi-Site Deployment Issue

When I attended the Open Identity Summit, I took away with me a great tip for OpenAM when Steve Ferris presented his OpenAM Survival Tips.

In Production environment for large deployment, sometimes we have to configure multi-sites for customers. (Multiple sites => multiple login URLs)

If I could illustrate with a diagram, the following is the recommended deployment architecture for multi-sites. Each site will point to its own pair of MQ servers. 

The reasons are clearly documented:

Multiple-Site configuration 

In a multiple-site configuration, two or more OpenSSO Enterprise servers are configured in each site. A multiple-site configuration is useful when you need to centrally manage OpenSSO Enterprise servers located in distant geographical locations. Multiple-site configuration is usually used in WAN environments, or where sites are managed as separate operational units within a LAN environment. Each site can have one or more load balancers. 

While system failover can be configured among all sites in the deployment, session failover is possible only within each site. WAN environments are subject to speed, network latency, firewall, and bandwidth issues. 

For these reasons, OpenSSO Enterprise session failover is not supported across multiple sites within a LAN or WAN environment. 

The following are typical reasons to use a multiple-site configuration: 

• Close proximity of OpenSSO Enterprise servers in a LAN environment 
• Underlying network infrastructure limitations exist. 
• Operational domains are managed as independent units. 
• OpenSSO Enterprise servers span across network boundaries as in the case of a WAN environment.

Why is it so? What's the problem technically?

It is due to the way Database URL list is keyed in for a site.

The following diagrams show what is happening behind the scene. All OpenAM instances will attempt to connect to the 1st MQ server in the Database URL list. If an OpenAM instance happens to be in another data-center from the 1st MQ server, no luck! It will still attempt to connect to it via WAN.

This, of course, causes latency and subsequently performance degradation. As such, session failover across WAN is never supported, even if you have a subscription from Oracle.


Well, not if you have a valid ForgeRock subscription. There is now an AM patch available for ForgeRock customers.

And thus, the following architecture is now made possible!

Just in time for one of my customers' multi-sites deployment.

.

Scheduled release dates for OpenAM, OpenIdM and OpenDJ

• OpenAM 10.2 Q3/2013
• OpenIDM 2.2 Q4 2013 
• OpenDJ 2.6.0 End of June 2013
• OpenDJ 3.0 Early 2014, withProxy services

Download link here.

.

OpenAM Mobile Application

Late last year, I blogged about Oracle Mobile Access and Social Management. I stated clearly why I think Cloud, Mobile, Social is the way going forward.

I'm glad OpenAM now has a solution for mobile application access. It is made possible by the latest release of OAuth2 Provider feature in OpenAM.

With the OAuth2 Provider in OpenAM, we also need to aware that OpenAM has REST endpoints exposed to its Core engine.

The REST endpoints are very important here. They make mobile integrations clean, without having to deploy custom APIs into the mobile applications.

Below is the sequence diagram for a OpenAM mobile application demo:

Pretty cool. Isn't it?


.

New Paradigm for the Modern Web

In the ForgeRock Open Identity Summit which was concluded last week, there was a common theme which was frequently brought up - New Paradigm for the Modern Web.

What is it all about?

• Mobile
• Social
• Cloud
• Enterprise
• Things

And the whole company in ForgeRock is aligned to this new paradigm, which is glad to know. The Strategic Roadmap for ForgeRock going forward is clearly defined.

It's getting RESTless in ForgeRock! :)


.

OpenDJ is getting RESTless!

A very exciting feature of OpenDJ will be released fairly soon. In fact, end of this month with the version 2.6 release.

In OpenDJ 2.6, REST endpoints will be exposed for end-users.

So besides the traditional way of connecting to a directory server via LDAP/LDAPS protocol, one can now connect to OpenDJ via the RESTful interface.


The REST endpoints with the REST2LDAP web application is shipped bundled with OpenDJ server.
By default, it is not enabled. A simple toggle in the configuration will enable the REST endpoints. As simple as that!

If we need to scale the REST2LDAP web application (well, it behaves just like any other web application) to handle high load, the REST2LDAP web application can be deployed in a different node. And of course, multiple REST2LDAP can be deployed pointing back to the same OpenDJ servers. 

This is an exciting feature, especially targeted at the modern developers of today who are more REST/JASON savvy.

In addition, when one query for a user in OpenAM, OpenIdM and OpenDJ, there is now a standard way of calling. All REST endpoints in these 3 products from ForgeRock are going to be more or less standardized, which makes development really easy. Oh man, I can finally throw away opendj-ldap-sdk-x.x.0-SNAPSHOT.jar.


You can view the presentation slides from here. And if you can't wait, you can always download the OpenDJ nightly build to try it out!

.

Open Identity Bridge

During the Open Identity Summit, we were presented a pre-release version of the upcoming Open Identity Bridge from ForgeRock (due to be released later half of this year).

To me, this is a very cool product. Technically, it is nothing too complicated. It is actually "lego"-ly built from ForgeRock OpenIDM/OpenICF (for Sync/Recon) and OpenAM (for Single Sign-On).

Who is the target customer?

Any corporate enterprise that has a Microsoft Active Directory where all their staff information are stored. In addition, the typical business applications are all cloud-based (e.g. Salesforce for CRM, Google Apps for emails).

PS: Of course, the directory need not be a Microsoft Active Directory. (But, yes, typically 80-90% of the enterprises are using AD)

How to use Identity Bridge?

Instead of deploying a standalone OpenIDM to provision users and then deploying another standalone OpenAM to establish federations among the various cloud applications, Identity Bridge is installed and configured to do the same job, within minutes. 

The installation and configuration is so simple and the software itself is so light-weight. The intuitive UI is the winner, IMHO.

I hope I can show you more of the Identity Bridge, but I only have the following login screen to show for now. :) 

But, believe me, it's very cool!

.

What is Federation?

So, I just came back from ForgeRock Open Identity Summit. Along the way, completed my 2nd half-marathon last Sunday by taking part in The Wipro San Francisco Marathon.

During one of the presentations by Victor Ake, the product manager for OpenAM, I was enlightened by his simple illustration of what Federation is all about.

Hanseatic League (Hansa) Trade Confederation Centuries 13th – 17th

• Trading outside the walls
• Secure
• Membership agreement
• Follow protocol

And this is what Federation is all about. Simple, isn't it?

.

How to upgrade CA SiteMinder deployment?

By now, everyone should know that I am a "diagram" guy. I do not like to read words after words, if a simple diagram can do the job. That's just me. :)

So, how do we go about upgrading CA SiteMinder to the latest r12.5?

The strategy is simple:

0. Do not touch the Policy/Key Store

1. Start with Policy Server upgrade

2. Proceed with Web Agent upgrade (Note: This new agent must talk to the new Policy Server)

3. Repeat until all components are upgraded

4. We are now ready to replace the Policy/Key Store

That's it! Simple.

.

CA SiteMinder Profiler - something to learn from

This is another tool I like about CA SiteMinder - Profiler.

What's this actually? Nothing fanciful.. A log capturer and presenter - to say it in layman term.

But is it useful? Yes, pretty much.

Have you ever tried debugging from OpenAM debug logs? You'll know what I mean. :)


.

Changing the password of amAdmin - Part II

I posted this topic a while back. So I thought it was a fairly simple change.

But my friend Peter has another insight view which we should take note of. I copied shamelessly from his reply in OpenAM mailing list. 

Changing amadmin password is not straightforward at all, there are many things to be aware of: 
* amadmin password is used to set up replication with embedded DJ, i.e. the admin password for replication 
* it's also used as the password for the internal dsameuser 
* it's also the password for the embedded opendj's directory manager 
* it's also stored in the bootstrap file in encrypted format (well it's the dsameuser password, but dsameuser has the same password as amadmin..) and hell knows what else So basically even if you change the amadmin password, you can run into other problems, and as far as I remember ampassword changes the password for the dsameuser, not for amadmin... 

At the moment I think there is no clear process around handling all these different passwords or even managing them without breaking OpenAM a couple of times during the process. 

If you only want to change the password for amAdmin, then look for: ou=amAdmin,ou=users,ou=default,ou=GlobalConfig,ou=1.0,ou=sunIdentityRepositoryService,ou=services,ROOT_SUFFIX the user password, the password is generated like this: http://sources.forgerock.org/browse/openam/trunk/openam/openam-core/src/main/java/com/sun/identity/idm/plugins/internal/SpecialRepo.java?r=4170 

and I think the workaround in the ticket description (not the comment!) can work for you to generate the password in the correct format for the directory: 

https://bugster.forgerock.org/jira/browse/OPENAM-1224

.

ForgeRock Strategic Roadmap

Live post from Open Identity Submit.

SiteMinder Test Tool

This is a very cool test tool from CA SiteMinder. How I hope we can have one for OpenAM!

Yes, I'm hoping. No harm having a hope right? Maybe, some days it'll materialise. :)


.

CA SiteMinder r12.5 supports CA Directory as Session Store

Yes, it's true - CA Directory configured as Session Store from r12.5 onwards is FOC!

CA SiteMinder r12.5 introduced support of CA Directory as a Session Store. Customers can take advantage of CA Directory free of charge as a repository for Session Data, Policy Data, and/or encryption Keys Data (commonly referred to as Session Store, Policy Store, and/or Key Store respectively). This provides a great opportunity for CA SiteMinder customers to take advantage of the unparalleled performance and scalability of CA Directory for these critical repository needs.

isProtected, isAuthenticated, isAuthorized

This is how most Policy Agent works, be it CA SiteMinder or ForgeRock OpenAM.

Policy Agent always go through these 3 processes:
1. isProtected?
2. isAuthenticated?
3. isAuthorized?

Simple.

.