Archive for the ‘Audit’ Category

Auditing SiteMinder Policy server connections to LDAP backend stores (policy+user)

Friday, October 15th, 2010

I’ve seen it time and time again from the number of organizations that we’ve worked with in the past – security auditing is treated with low priority – specifically firewalls between intermediary components and devices and in some extreme cases data encryption between those same devices. So it goes without saying that any component accessing the corporate directory, i.e. LDAP, should be treated the same as any user accessing directory information. As a standard practice in ANY of our SiteMinder deployments, we generally follow the same access and security policy that accesses (search, create, delete) to the underlying store must be done using a named account (i.e. uid=ssoadmin,ou=people rather than using  a generic account or using the native LDAP superuser account “cn=Directory Manager”) for audit and security purposes.

By configuring the above, this will provide:

1. Additional audit information and data from the underlying component.
2. From a troubleshooting standpoint this enables the directory administrators to quickly narrow down and locate potentially “erroneous” connections originating from the policy server.

Questions?  Shoot us a line over at IDMWorks.

Recently for an Oracle Identity Manager project, I was given what most would consider a “simple” requirement. The requirement was to add a field to the out of the box OIM Self Registration Form. The field was to be used to confirm the users email address entered, similar to how currently there is a password confirm field on the form which forces the user to enter their password twice to mitigate typos. Oracle’s documentation is pretty straight forward for modifying the OOTB Registration form. If you want to add a field, just edit the FormMetaData.xml file. Simple enough, but the problem comes in when you want to add logic to the form to have the Email confirm field match the Email field.