IBM Security Verify

With basic user, if you set a custom policy like max concurrent web sessions, TOD, expiration, etc. the user has to be imported into the ISVA registry.

Is there a way to get around this?

We have ISVA setup in a blue/green environment.  Because the registry of one install of ISVA cannot share the registry location of another, due to the UUIDs in the registry needing to match the PD DB, we have two different containers in the LDAP with the registries of each deployment.  We keep these in sync using an external sync process.

This presents two major pain points.  The first is the need for the registry in the first place.  If I have to rebuild the environment from scratch (full reinstall from license to production) the user policies have to be compensated for.  The second is the sync process we have doesn't always work 100%, and it's one more dependency to maintain.

If the custom policy data could be saved on the inetorgperson (or whatever objectclass is used) user object as an attribute, then none of this would be an issue.

Is there any way to do this, and break free of the heavy chains of the PD registry objects?  Groups are no issue, I know about all groups in the environment, they are maintained in our code repo with the junction (and respective ACL) config.  It's the secUser objects and hence respective secPolicy that are the huge headache.

Would it be possible to use LUA to update these policies when the user is loaded from LDAP?  For example, what I'm wondering is if there would be some way to store these policy values as JSON or delimited key=value pairs on the user objects in the LDAP.  Then, query that attribute using an LDAP call from a LUA transform, parse it, and set the appropriate policies before the user continues on.  If not LUA, could I do this with an EAI using an InfoMap run on the RTSS?

Thanks for any input!

With basic user, if you set a custom policy like max concurrent web sessions, TOD, expiration, etc. the user has to be imported into the ISVA registry.

Is there a way to get around this?

We have ISVA setup in a blue/green environment.  Because the registry of one install of ISVA cannot share the registry location of another, due to the UUIDs in the registry needing to match the PD DB, we have two different containers in the LDAP with the registries of each deployment.  We keep these in sync using an external sync process.

This presents two major pain points.  The first is the need for the registry in the first place.  If I have to rebuild the environment from scratch (full reinstall from license to production) the user policies have to be compensated for.  The second is the sync process we have doesn't always work 100%, and it's one more dependency to maintain.

If the custom policy data could be saved on the inetorgperson (or whatever objectclass is used) user object as an attribute, then none of this would be an issue.

Is there any way to do this, and break free of the heavy chains of the PD registry objects?  Groups are no issue, I know about all groups in the environment, they are maintained in our code repo with the junction (and respective ACL) config.  It's the secUser objects and hence respective secPolicy that are the huge headache.

Would it be possible to use LUA to update these policies when the user is loaded from LDAP?  For example, what I'm wondering is if there would be some way to store these policy values as JSON or delimited key=value pairs on the user objects in the LDAP.  Then, query that attribute using an LDAP call from a LUA transform, parse it, and set the appropriate policies before the user continues on.  If not LUA, could I do this with an EAI using an InfoMap run on the RTSS?

Thanks for any input!

@Scott Exton, maximum concurrent web sessions is the highest priority on my list.  Time of day is also one.  Maybe account expiry date.

I recall LUA having the LDAP module, so I am certain I could get the information from the user object.  To your point, what do I do with it?

Today we primarily use user cert mapping for mTLS authentication (cert required) and some username/password (cert optional and prompt as needed).  At some point in the future we will be doing FIDO so I'll likely have to account for it as well.

Time of day and account expiry date I could see being able to do in an EAI or maybe even LUA.  Concurrent web sessions is probably my biggest mystery, when does it decide to start telling a user no and when/where is that value queried from?  I assume when a user authenticates each session, it queries the secPolicy object for the max session value and then makes a decision based on the session being created.  So it seems if I could alter that value before it gets to the decision point of "is this new session one to many sessions for this user" then I could use data from another point (i.e. LUA or EAI).

Thanks Scott,

Matt

With basic user, if you set a custom policy like max concurrent web sessions, TOD, expiration, etc. the user has to be imported into the ISVA registry.

Is there a way to get around this?

We have ISVA setup in a blue/green environment.  Because the registry of one install of ISVA cannot share the registry location of another, due to the UUIDs in the registry needing to match the PD DB, we have two different containers in the LDAP with the registries of each deployment.  We keep these in sync using an external sync process.

This presents two major pain points.  The first is the need for the registry in the first place.  If I have to rebuild the environment from scratch (full reinstall from license to production) the user policies have to be compensated for.  The second is the sync process we have doesn't always work 100%, and it's one more dependency to maintain.

If the custom policy data could be saved on the inetorgperson (or whatever objectclass is used) user object as an attribute, then none of this would be an issue.

Is there any way to do this, and break free of the heavy chains of the PD registry objects?  Groups are no issue, I know about all groups in the environment, they are maintained in our code repo with the junction (and respective ACL) config.  It's the secUser objects and hence respective secPolicy that are the huge headache.

Would it be possible to use LUA to update these policies when the user is loaded from LDAP?  For example, what I'm wondering is if there would be some way to store these policy values as JSON or delimited key=value pairs on the user objects in the LDAP.  Then, query that attribute using an LDAP call from a LUA transform, parse it, and set the appropriate policies before the user continues on.  If not LUA, could I do this with an EAI using an InfoMap run on the RTSS?

Thanks for any input!