Where to store Password Policy?

Any Single Sign-On product in the market will need to talk to a back-end User Store for authentication purpose. A User Store can be a traditional LDAP server or a modern Microsoft Active Directory Server.

Now, the SSO product fronts the end-users and this is where Password Policy is enforced. (Of course, if a corporate environment is using Microsoft platform, then password policy can be enforced during the Windows logon process)

Today, I talked to a Product Pre-Sales engineer and was pretty pissed off. She knew my team is managing the SSO product, as well as the LDAP server for a customer. We have a migration exercise going on at the moment.

My customer wants us to make use of the out-of-the-box features from the SSO product as much as possible - to the extend of making sure the Password Policy implemented on the LDAP server can be seamlessly integrated with this SSO product.

We spent a few days reading up and setting up a POC in our labs. We confirmed that this SSO product is not able to "interact" with any underlying LDAP server with regard to Password Policy management. It is only able to implement its own password policy.

She insisted that the RIGHT WAY of doing thing is for the SSO product to enforce password policy for the corporate.

This is "vendor-lock-in" strategy. You think customer is stupid?

I have implemented many SSO projects. In Sun's days, when the old Sun Access Manager and OpenSSO server could not integrate seamlessly with Microsoft Active Directory, we did not tell our customers that was the wrong way of enforcing password policy and they should use Sun AM/OpenSSO built-in password policy instead.

We stripped the codes and implemented custom authentication module for our customers.

User Store (LDAP server or Microsoft Active Directory Server) should be the authoritative password policy enforcer.

Wake up, lady!

.