On 3/27/15 1:47 PM, arjan tijms wrote:
> I described the process for GlassFish, WebLogic and Geronimo here:
> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorization-jacc-revisited.html
>
Hi Arjan,
In the excellent blog article you ciet below, you also covered how one
can go about acquiring the
container's role mapping facility. You may have already seen the work
that was done in the JACC
RI (i.e, Glassfish) to make the container's role mapper facility
available via a PolicyContextHandler.
The idea being that this could be done in any JACC compatible container
via the PolicyContext#registerHandler
method. For example, you could take some variant of the container
specific code you show in your blog,
and encapsulate it in the implementation of a PolicyContextHandler. This
container specific code would
then be registered via registerHandler, at the PolicyContext of the
container. Then your portable JACC
provider could use PolicyContext.getContext. to invoke the getContext
method of the handler; which would
return an implementation of a common, if not standard, principal to
mapping interface.
IIRC, this technique is demonstarted in the (simple) JACC policy
provider you referred to.
If a principal-2-role interface is standardized, then someone would need
to write and register a corresponding
handler in each of the container implementations. If the containers were
required to provided the handlers out of
the box, then access to the containers principal to role mapping
facility could be conveniently available.
That was the idea, back before CDI. Now, I suspect there is an interest
in being able to inject the appropriate
instance of some standard role mapper interface; which could be packaged
in the application archive.
Ron