Came across a very interesting/fascinating puzzle today. I got to blog about it. A searchscope does not have a ComputedMember attribute bound to it, so you can’t really query the “membership” of a searchscope. Its kind of like a View table in SQL, its virtual. At least in SQL you can query a View table contents but not a searchscope. Now, I want to find out if a user belongs to searchscope X. Lets look at a scenario
- I want requestors to select for a particular field in a form, a user from searchscope X.
- The filter for searchscope X is /Person[EmployeeType=’Contractor’]
- If the requestor selects a user, I want to validate that they followed instructions and selected from searchscope X only.
Solution
Well the answer is really simpler than you would think. Take the filter of the searchscope and test if the user fulfills that requirement. So for the selected user check if the EmployeeType field is equal “Contractor”.
You can use the “verify request” feature of the MIM WAL to check the request after submission and deny or allow the request to go through for processing. Now that’s where it becomes more interesting. The FIM WAL verify request tool has a resource uniqueness tool where you can write an XPath (to query FIM to see if you are duplicating an object), so another way to check if UserX has EmployeeType = “Contractor” is
/Person[ObjectID=[//Delta/userX] and EmployeeType != ‘Contractor’]
So if UserX’s EmployeeType = “Full-Time Employee”, the query result will return an Object (UserX) and the request will be denied. If UserX’s EmployeeType is “Contractor” then UserX should be in searchscope X and there will be not uniqueness conflict because the query result will be null, so it will go through for processing.
tlktechidentitythoughts 