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