> The sun-xacml is a joy to work with as is the sun-xacml team. I am
> discovering the plugable architecture of FinderModules and really liking it.
Thanks Farrukh. I'm glad to hear that the code is providing what you need.
One of the future tasks is to include some configuration system so you
can include finder modules, etc. without having to hardcode them, which
should make this system even more usable.
> The problem is that the impl of the findAttribute method of my
> RegistryAttributeFinderModule needs access to one or more application
> specific objects. How do I do that?
Can you be more specific about what "application specific objects" are? For
instance, are these specific to your PDP, or to your reg/rep system?
> I see that findAttribute method gets an EvaluationCtx which internally
> has the RequestCtx that I pass to PDP.evaluate. So it seems that I need
> a way to pass one or more java.lang.Objects in RequestCtx when I call
> PDP.evaluate. Is there an existing way to do that? If not what do you
> think of changing the impl so RequestCtx supports a HasMap with methods
Right now the code supports only the standard datatypes. This is by design,
since we want to support interoperable systems. In order to pass your java
object into the Request you'd either need to define a new datatype, or
you could serialize the object and pass that as a string into the Request.
In either case, you could then retrieve it in the findAtttribute method.
As for your second question...
> The resulting code would like:
> //Following code would be new under proposal
> HashMap userObjects = xacmlReq.getUserObjects();
> userObjects.put("AppSpecificRequest", myRequest);
I think that what you're suggesting is a way to seed a Request with things
that aren't XACML Attributes so you can pass in extra stuff. The problem
is that the Request is supposed to represent an XACML RequestCtx and as
such must be encodable and can be passed from a PEP to a PDP. What you're
proposing would break those rules. If you want to get values into a Request
they need to be Attributes. If you want to seed your finder, or if you
want some app-specific way to get values, then you need to write this.
Basically, I see two interesting questions here:
1. What about support for standard Java types in the Request?
2. What about ways to get app-specific stuff into my finders?
These are both good questions, and deserve some thought. The first might be
answered by some new package that has support for non-standard datatypes.
The second is a little trickier, but I can think of a few things. Hrm.
> PS: As an aside please consider replacing abbreviated named like xxCtx
> with xxContext in a future release.
Is there a reason you want this? I'm loathe to change names on such a wide
scale as that, since people are using these interfaces on a regular basis,
but if there's a compelling reason to make that change we could consider