[higgins-dev] Mapping at what level?

["Tom Doman" <TDoman@xxxxxxxxxx>]

All,

Now that we have the JavaScript Policy Context Provider, we can do a variety of different mappings through Policy Decision Points (PDPs) it defines.

Here's a list of some of the PDPs it defines:
	1. Mapping of the Subject ID in and out.
	2. Mapping of the Subject Type in and out.
	3. Mapping of Attribute Types in and out.
	4. Mapping of Attribute Values in and out.
	5. Mapping of Schema in and out.

The JavaScript Policy CP can wrap any other CP and perform these mappings via JavaScript specified in it's configuration file.  This provides any CP the ability to leave the specified mappings to be done at a higher level.  The question is, should any given CP rely on a mapping CP to do this and thus not stand alone?  Or should any given CP do all of it's own mappings?  Or perhaps something in between?

For the JNDI CP, we've considered all of these and each has it's own pros and cons.

1. The simplest approach would be leave all the mappings up to the JavaScript Policy CP but would make the JNDI CP not as abstracted as is desirable.  For example, Subject ID would be the javax.naming style hierarchical IDs.  The subject type and  attribute names would be ... well, the simplest thing would could come up with that was a legal URI (is the string "inetOrgPerson" a legal URI, I'll have to look that up but in this approach, it'd be preferable to leave the names unchanged from LDAP).
2. The next approach would be to do SOME of the mappings in the JNDI CP.  I could leverage some of the JavaScript Policy code in our utilities package (the same code the JavaScript Policy CP is using) and implement some of the PDPs listed above and allow them to be configured in the JNDI CP configuration just how they are in the JavaScript Policy CP.  The question becomes which ones and why?  We've talked about doing #3 only so that we have Higgins OWL types in both the attribute types and the schema access code that is also configurable.  Then we could leave the rest up to the JavaScript Policy CP.  But that doesn't really make the JNDI CP completely usable stand-alone because the Subject IDs are javax.naming style hierachical IDs which may be undesirable but if we implement #1 to handle that, we also need to implement #4 to make sure that these names are mapped inside attribute values that contain them.
3. This leads to the last approach which is to implement 1-5 entirely within the JNDI CP but that seems to thwart the existence of the JavaScript Policy CP in the first place.  If every CP has to write code to handle all of those PDPs then the JavaScript Policy CP is only good for is another level of mapping.
4. Today, I'll discuss an approach with Duane where maybe we could derive the JNDI CP (or any CP) from the JavaScript Policy CP or, if not, instead, create a toolkit that all CPs could use so we all don't have to rewrite the same code.

Any other approaches?  Any suggestions as to the best practices or what is to be expected with respect to mapping from each CP?

Thanks,
Tom