Hi Arjan,
Thanks for looking into the vendor specific details of provider
configuration. It's really great.
I am forwarding directly to the Geronimo and WLS Security architects to
ensure that they don't miss this msg and the link to your blog.
I am not an expert in class loading; which is why I only referred to the
server's class path.
I agree that its not always easy to figure out where to put a jar
(containing a JACC or JASPIC provider)
such that it will be found and loaded by the server.
Is that something that the EE spec already does or should define for
common use (such as by JACC, JASPIC, etc.)?
If a class path based solution is not appropriate, I agree as suggested
by your reference to JCA and deployment
archives, that it would be best to apply or extend an existing EE
configuration or deployment mechanism.
Are you discussing this issue in JSR 375?
AYK, JACC providers are expected to replace the VM Policy system;
whereas JASPIC providers often are bound to
specific applications; which suggests that JASPIC providers and their
configuration properties could be deployed within
application archives. For JACC and systems like JACC; it is less clear
how deployment within an application archive could work,
but that is also worth considering.
Is this a case of the JACC and JASPIC specs not being up to dae, wrt to
their use and alignment with requirements
(for loading system level modules) that are already defined in the EE
platform spec?
Ron
ps: regarding role mapper configuration, perhaps that can be seen as a
case of some providers
needing standard interfaces to access and used the container's native
role mapping system. There
may be other cases where the intent is to provide an alternative role
mapper for use by the container;
in which case there would need to be some way (perhaps within a JACC or
JASPIC provider) of providing the/a
role mapper.
On 3/27/15 1:47 PM, arjan tijms wrote:
> Hi,
>
> Both JACC and JASPIC ask that jars containing the implementation of a
> JACC provider resp. authentication module are placed on the server's
> classpath.
>
> Specifically JACC has specified 2 VM level properties for that purpose:
>
> -Djavax.security.jacc.policy.provider=test.TestPolicy
> -Djavax.security.jacc.PolicyConfigurationFactory.provider=test.TestPolicyConfigurationFactory
>
> Unfortunately, an increasing number of servers use modular
> classloaders, and *the* server classpath barely exists. In such
> servers it's nearly impossible to get the server to use a custom JACC
> provider.
>
> In some occasions, seemingly the only way to get your own JACC classes
> into the server is to inject them into an existing server jar file,
> which is nothing short but a terrible hack.
>
> I described the process for GlassFish, WebLogic and Geronimo here:
> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorization-jacc-revisited.html
>
> Additionally for development purposes, even if the JACC provider can
> be relatively easy integrated with the server, the current situation
> is not ideal.
>
> Now something like JCA has defined the concept of a resource archive
> (.rar) which can be used to integrate a connector into a server by
> either embedding the resource archive within an ear, or by deploying
> it standalone just like one would deploy a .war.
>
> I wonder, would it make sense to define something like that for both
> JACC and JASPIC? (for JACC this would be more important, since it
> doesn't have the programmatic registration option from within an
> application archive that JASPIC does have).
>
> Kind regards,
> Arjan Tijms
>
>
>
>