Restricting/Validating Attribute Values
Hi,
I am trying to understand my options for defining a validation list for possible values for a multi-valued attribute.
I'd like to be able to create a list of allowed values, which in any combination/order could be found in a multi-valued attribute on a user account object.
Any attempt to write a value to the multi-valued attribute not found in the list of allowed values should be rejected by the ldap.
Is a custom plug-in the only option? Is there something easier to implement based on native functionality?
[547 byte] By [
acnroopa] at [2007-11-26 20:41:35]
# 1
I think the easiest way would be value-based ACIs, you can set allowed values there. How big is this list? How dynamic is it, i.e. how often do you expect changes in the set of values?
# 2
The list will initially have approximately 250 Entries. I that each year about 25 -30 entries may be added and about 15-25 old entries may be removed or modified.
How exactly do the value-based ACI's work? Would there be an individual entry for each allowed value?
Ideally, I'll "reconcile" this information into a an IdM tool so that when needed "access" can be granted to the individual by adding an auxiliary object class and individual "groups/roles" can be assigned by adding another allowed value to the multi-valued attribute that comes with the auxiliary object class used to denote gross level access.
So I'll want to make the list that is used accessible for both updates by LDAP adminsitrators and also readable by an agent or process used to bring "group/role" information into the IdM tool for provisioning.
Thank you for the help! I really appreciate this.
# 3
Please look in the section "Targeting Attribute Values Using LDAP Filters" in the DS5.2 Admin Guide. It should be possible to define the list in 1 ACI - but not sure if there are limits for ACI string size, or how this would affect server performance.
# 4
Thanks Ewiron.I'm going to have to try this out and see how it affects performance. Right now we have a situation where groupofnames objects are growing to include well over 20,000 entries all the way on up to 50,000 entries. This has caused severe performance impacts during add/removal of rights from users, or better stated when adding or removing a user's dn from the long list of entries in the groupof names objects.
The proposal was to simplify it this way. Hopefully, the ACI will prove to be less of a drain.
# 5
Question if the string for the ACI is limited in length, can two (or more) ACIs be combined to create the effect of having one composite entry?
If the filters are set up as follows (assuming a very short limit)
Filter1: (|(membergroup=group1)(membergroup=group2))
Filter2: (|(membergroup=group3)(membergroup=group4))
Can the ACIs be made to treat this as if one ACI was produced (instead of 2 for the filters above) whose composite setup would be?:
Combined Filter: (|(membergroup=group1)(membergroup=group2)(membergroup=group1)(membergroup=grou p2))
Thanks in advance!
# 6
I think it doesn't make a difference, but I don't have experience with value based ACIs. But shouldn't be hard to test that.
Btw, I guess the filter should look like this:
(targattrfilters="add=membergroup:(membergroup=group1) &&
membergroup:(membergroup=group2) &&
membergroup:(membergroup=group3) &&
membergroup:(membergroup=group4)")
