Thursday, March 23, 2006
Substitution Syntax in Search Base and Attribute Access Control
Have you ever got confused when using substitution syntax in COREid search base and attribute access control settings? They natural thing to get backwards since they are backwards (from each other that is). Question is, which one is which? Does the logged in user go in the left hand side ot the right hand side? Does the substitution go in the left or right? Well, that one at least is easy; the substitution attribute $attributename$ always goes on the left, errr, I mean right. I just can never remember which one it belongs to: logged in user or objects being searched/viewed/edited/notified?
Well, this is how it works:
Search Base gets set up so that the logged in user's information goes on the right side of the equation, the substitution side. For instance, the substitution might look like this...
org=$myorg$
This basiccally says that the search is restricted to all of the objects that have an org that is the same as $myorg$, where $myorg$ is an attribute in my profile and org is an attribute on another object.
Well, is that is how search base works then AAC must be the opposite.
Attribute Access Control gets set up so that the logged in user's information goes on the left side of the equation, the non-substituion side. For instance, the substitution might look like this for a rule that allows a manager permission to a particular attribute and right...
distinguishedname=$manager$
This essentially says give me (distinguishedname - MS centric example) permission to do this (right) for this attribute where I am the manager. Although I do not know why you would do this explicit thing since COREid already supplies a role for DN based attributes (like manager) that accomplishes the same thing.
Well, this is how it works:
Search Base gets set up so that the logged in user's information goes on the right side of the equation, the substitution side. For instance, the substitution might look like this...
org=$myorg$
This basiccally says that the search is restricted to all of the objects that have an org that is the same as $myorg$, where $myorg$ is an attribute in my profile and org is an attribute on another object.
Well, is that is how search base works then AAC must be the opposite.
Attribute Access Control gets set up so that the logged in user's information goes on the left side of the equation, the non-substituion side. For instance, the substitution might look like this for a rule that allows a manager permission to a particular attribute and right...
distinguishedname=$manager$
This essentially says give me (distinguishedname - MS centric example) permission to do this (right) for this attribute where I am the manager. Although I do not know why you would do this explicit thing since COREid already supplies a role for DN based attributes (like manager) that accomplishes the same thing.
Permalink posted by Dave Bennett @ 11:17 a.m. 
Comments:
<< Home
I noticed that you used the AD attribute distinguishedName in one of your examples. I am curious to hear more on how you exposed this? I am aware of the config XML exclusion files where you should delete/comment out the relevant attribute, but Oracle has told us, and I quote:
"The customer should not exclude the 'distinguishedName' from the ad_exclude_attrs.xml file, since it would be a mis-configuration.
In fact, Developmen had decided that this was not a Bug. The product worked 'as designed'." (end quote)
While I don't agree with their assessment I am interested in hearing how you did it. Our problem is that excluding distinguishedName from the file above breaks the workflow engine, ie you can not create or modify workflows. Have you come across this problem at all?
"The customer should not exclude the 'distinguishedName' from the ad_exclude_attrs.xml file, since it would be a mis-configuration.
In fact, Developmen had decided that this was not a Bug. The product worked 'as designed'." (end quote)
While I don't agree with their assessment I am interested in hearing how you did it. Our problem is that excluding distinguishedName from the file above breaks the workflow engine, ie you can not create or modify workflows. Have you come across this problem at all?
# posted by 
: 7:54 a.m.
: 7:54 a.m.
I should point out that this was on AD/AM and not AD. Although the example was not specific to something I did it is similar. With the AD/AM install though I did not have to tinker with exclusion files to get it to work. However, I never tried to configure the attribute (distinguishedname) it in the UI. I just keyed it into the filters and it worked - the same may work for you as well. I suppose if it had not have worked right away I would have had tinker in the XML exclusion files, but I always thought the files were to simply affect what shows up as configurable.
I did use the
distinguishedname=$distinguishename$ (along with a series of other attributes in the filter) in the domain of a workflow and then jsut use self as a participant. I had tried to do it all in the participants section of the wowrkflow, but the filter builder UI did not allow it - probably because it was not a UI configured attribute. I thought about adjusting the WF policy entry in the DS but then thought better of it and changed the domain instead.
Good luck! I will try on AD when I get a chance.
I did use the
distinguishedname=$distinguishename$ (along with a series of other attributes in the filter) in the domain of a workflow and then jsut use self as a participant. I had tried to do it all in the participants section of the wowrkflow, but the filter builder UI did not allow it - probably because it was not a UI configured attribute. I thought about adjusting the WF policy entry in the DS but then thought better of it and changed the domain instead.
Good luck! I will try on AD when I get a chance.
Thanks Dave, looking forward to hearing more.
The reason I want to get at distinguishedName is this:
When you perform a Common Search (over IdXML) you get back only the attributes you ask for. You don't get back, or at least I don't know how to get back, the DN of the objects that match your criteria. While I can search for user objects with eg title=manager and get their names and other attributes, I don't really know what user objects I have found - I don't know their DN. The attribute distinguishedName seemed like a convenient AD shortcut, though the plans are now on hold pending the COREid dev team mulling it over.
How do you and your team normally tackle the issue of getting the DN of an object that you find with Common Search? Doesn't have to be AD, the problem should be similar with other directories AFAIK.
Post a Comment
The reason I want to get at distinguishedName is this:
When you perform a Common Search (over IdXML) you get back only the attributes you ask for. You don't get back, or at least I don't know how to get back, the DN of the objects that match your criteria. While I can search for user objects with eg title=manager and get their names and other attributes, I don't really know what user objects I have found - I don't know their DN. The attribute distinguishedName seemed like a convenient AD shortcut, though the plans are now on hold pending the COREid dev team mulling it over.
How do you and your team normally tackle the issue of getting the DN of an object that you find with Common Search? Doesn't have to be AD, the problem should be similar with other directories AFAIK.
# posted by : 12:57 a.m.
: 12:57 a.m. << Home
