| Re: [higgins-dev] Mapping at what level? |
|
Personally I prefer to let the individual CPs do what they do best and not try to force all of them to do mapping ie option #1. This keeps CPs as simple and clean and dependancy free as possible, and encourages developers and deplopyers to use standard tools to do mapping rather than have every provider implement it's own style of mapping and therefore it's own style of mapping configuration.
On Options #2 & #3, it is possible, but then we are setting the precedent that All CPs will do mapping and transformation which is contrary to why I like Option #1.
If we do select #2 or #3 then I structured the JSPolicyCP such that much of the functionality is in a toolkit format like that proposed by Tom in his option #4.
Minor clarification, the transformation of Schema in is not fully implemented.
Duane
>>>
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 _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |