Re: [higgins-dev] PDPs for context providers

["Tom Doman" <tdoman@xxxxxxxxxx>]

David,

Indeed, I meant to say that as well, namely, MAY.  And that is an unqualified
MAY and that's where I went with my description to Raj.  That is, like the PDP
interfaces but want a different implementation for a different policy language?
Awesome, but you'll have to write yourself.  Like the PDP interfaces but want
to add more decision points?  Great, let's at least discuss them but, ultimately,
it's open source and each CP can create, pick, and choose which PDPs to support
(notice that there are PDPs I didn't support directly in the JNDI CP that ARE
supported in the JScriptPolicy CP which is basically a "wrapper\mapper" CP).
Or, don't like those interfaces at all?  No problem, the CP implementor may
choose a different way to solve those requirements.  It's all good!

Though, yeah, we thought those interfaces might be helpful to other CP
implementors as long term solution but even if only for bootstrapping
until they could implement some other preferred solution.  My druthers?
We work together on defining PDP interfaces for mapping\transformations
and implement them in the policy languages we like the best.  In work
that predates Higgins, we had done some XACML PDPs but we didn't have
a nice way for consumers to edit those policies and, wow, flexible?  Sure.
Complex?  Unbelievably when you're editing the XACML manually.  So, in
Higgins we thought we'd start with JavaScript because it's much easier to
work with.

There's a nice long answer to a short question.  :)

Tom
 
>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 04/30/08 3:16 PM >>> 
Tom, 

I work with Raj (we are on different timezones, so we are tag- teaming the 
post). Thanks for the implementation. I assumed that the PDP interfaces in 
org.eclipse.higgins.util.idas.cp are not required to be implemented by an 
IdAS CP. The idas.util.cp PDP interfaces and jscript implementation *may* 
be used by a CP.  Or is it that a CP *must* use the idas.util.cp PDP 
interfaces for attribute mapping and transformation? 

Thanks, 

David 

David Kuehr- McLaren 
IBM Tivoli
919.224.1960 




"Tom Doman" <tdoman@xxxxxxxxxx> 
Sent by: higgins- dev- bounces@xxxxxxxxxxx
04/30/2008 11:34 AM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" 
<higgins- dev@xxxxxxxxxxx>


To
<higgins- dev@xxxxxxxxxxx>
cc

Subject
Re: [higgins- dev] PDPs for context providers






One more thing I should add, as Jim was saying yesterday, some of IdAS
is being refactored and so that will effect this code as well (ie. 
Metadata
is changing to regular attributes).  So, you may want to wait to get into
this stuff too deeply.

Tom
 
>>> "Tom Doman" <tdoman@xxxxxxxxxx> 04/30/08 9:03 AM >>> 
Raj,

Yes, there is.  I don't know how you discovered the IAttributePDPs 
interface
but the JNDI CP code has example usages of all of the PDPs we've defined 
in
the Higgins project so far.  Note that those PDPs are implemented only 
with
JavaScript implementations so far.  In other words, no other policy 
languages
have yet been implemented.  We'll also want to create additional PDPs in 
the
future as well but the basic set you'd need are there as exampled in the 
JNDI
CP as long as you're happy to define your CPs policies in JavaScript.

Tom
 
>>> Rajalakshmi S Iyer <iyer_rajalakshmi@xxxxxxxxxx> 04/30/08 4:39 AM >>> 

Hello,

I am in the process of defining a context provider and need some guidance
with respect to mapping between the provider (my context) and consumer
(IdAS based context provider) IDs, types etc. I have come up with an
ontology for this context provider that derives from the base Higgins
ontology.

As I understand, I will need to implement the IAttributePDPs interface for
my context provider which will do the conversion for attribute names, 
types
and their values between provider and the consumer.

However, conversion is also required between provider and consumer entity
IDs and entity types. For e.g. a 'Person' in the context provider ontology
could mean an 'ePerson' in the context's schema. Is there an interface to
cover this kind of entity-   level policy decisions? If not, is it 
worthwhile
coming up with one?

Thanks in advance,
Best regards,
Rajalakshmi Iyer

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


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

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