Re: [higgins-dev] Mapping at what level?

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

What is the usecase to have a Policy CP as it seems out of place

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Tom Doman" <TDoman@xxxxxxxxxx>

"Tom Doman" <TDoman@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

03/13/2007 11:32 AM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc
Subject	[higgins-dev] Mapping at what level?

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


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev