Hi,
On Fri, Mar 27, 2015 at 8:15 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
> Thanks for looking into the vendor specific details of provider
> configuration. It's really great.
>
Thanks :)
>
> 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.
>
Indeed it isn't. And it actually led to an interesting observation. As you
remember some people like to embed everything in an application archive,
while some other people think managed/secured resources should be installed
at the container.
Now recently I found out that in at least *some* cases people who claim
that they want to embed in an application archive only do so for
development purposes and because it's so hard to install something at the
container. They don't actually have a need for say a SAM to be packaged
together with their code.
In one occasion someone even deployed two separate wars to a server (no
ear); one with a SAM embedded (and using the "null" argument when
registering it with the factory), and the other containing the application.
This somewhat peculiar scheme was only done to simplify development and
deployment.
> Is that something that the EE spec already does or should define for
> common use (such as by JACC, JASPIC, etc.)?
>
I'm not a big expert when it comes to JCA and rar archives, but to me it
looks like this is one case where the Java EE spec already does this. There
are a few occasions where there's a similar spec gap, such as the need to
install a JDBC driver jar that's global for the entire server.
> Are you discussing this issue in JSR 375?
>
Not yet. At the moment there's no discussion about anything that could be
installed at the container side.
However, the EG has expressed its wish to standardize "authentication
stores" ("things" that just retrieve a username/role from a certain
store/repository, such as LDAP or a DB). Despite the EG being very focussed
on things that can be embedded inside the application archive at the
moment, I think these "authentication stores" should likely be able to be
installed at the container side as well.
> 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.
>
I'm just thinking out loud, but perhaps the global VM Policy can first
delegate to a per-application Policy implementation. Currently in JACC the
Policy can already use the context ID to obtain a PolicyConfiguration
instance that is of course application specific, so there's an application
specific element already.
The idea would then be:
GlobalJaccPolicy#implies --- calls ---> ApplicationJaccPolicy#implies
Kind regards,
Arjan Tijms
> 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
>
>
>
>
>
>