On 3/27/15 5:33 PM, arjan tijms wrote:
> Hi,
>
> On Fri, Mar 27, 2015 at 8:15 PM, Ron Monzillo <ron.monzillo_at_oracle.com
> <mailto: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.
>
I have also seen this. the registration factory is a global resource, so
it sort of makes sense.
I should admit that I routinely do the inverse of this, iow, I use a
debugging app to dump out all
the authconfig provider registrations on the system.
>
> 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.
>
If it is not already easy, it should be easy to know where to put the
jars containing these classes. In Servlet, there are siilar cases, where
you need
to know where to put jars if you want them to be scanned (for example).
It seems to me that part of this could be fixed by
requiring some documentation... but, at least for jaspic, there would
remain the problem of where to convey module specific configuration
data, and
obtained by the AuthConfig and passed through to the SAM. As i mentioned
previously, it seems like JASPIC should define an interface for
module initialization properties, which could be implemented and
included in various places (such as within an application archive).
>
> 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
>
yes, but to make that work, the top level provider would be required to
support internal configuration of per app provider implementations
which may rarely be necessary. PolicyConfig objects are per app, because
they come to encapulate per app policy; but I don't think we
intended to make it so that every top level Policy Provider could
delegate to a different type of Policy Provider per app.
> 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?
>
I am still nor sure what the answer is here. I'll send another msg to
the EE spec leads to see what they think; or if you want to
please raise this issue with them.
Ron
>
>
> 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
>>
>>
>>
>>
>
>