Guys,
Just a couple of quick comments, as it may be a couple of days, before I
can comment further on this.
Regrading the class loading issue, I think it would be best if this
could be handled as a
Platform layer requirement. That's why I suggested the extension loading
mechanism. We
should probably ask for the advice of the Platform EG, especially to see
if this may be something
for which there is a common need. For example, I would think that this
same problem applies
to the placement of a ServetContextInitializer; maybe we can learn from
how that is done, or
maybe there is a common problem that needs to be resolved.
Regarding programmatic configuration of web security constraints, are
you aware of
https://docs.oracle.com/javaee/7/api/javax/servlet/ServletRegistration.Dynamic.html#setServletSecurity-javax.servlet.ServletSecurityElement-
You should b able to programmatically define security constraints during
the initialization of a web application.
Its been some time since I tried this sort of thing, but you should be
able to do this from a ServletContainerListener.
You can see some mention of this in the JACC spec.
Ron
On 7/12/16 9:01 AM, Guillermo González de Agüero wrote:
> Hi,
>
> Modern Application Servers use complex class loading mechanism so I
> don't think the situation can be simplified to defining a custom path.
> Doing that implies that all required classes are available in the
> classpath and probably that all the internal classes of the JAR are
> also exposed to deployed applications.
>
> After seeing JBoss[1] and GlassFish/Payara[2] registration methods, I
> propose something along these lines: "the Application Server MUST
> support a system property named XX, which specifies the
> JAR/module/whatever term the server uses, from which the classes are
> to be loaded. The Application Server can opt to ignore this value ONLY
> if location can be unambiguously determined (e.g. it uses a flat class
> loader)".
>
> Not the more end developer friendly solution for the problem, but
> maybe that's as far as we can get now. It wouldn't interfere in
> implementors class loading mechanisms, while still the user would get
> a clearer way to install it.
>
> Regarding use cases: what I was originally trying to achieve was to
> dynamically define security constraints[3] from a Web Application. As
> it is now, the only way to do that is to install a custom JACC
> Provider. Yet it comes with the price that you have to reimplement all
> the server's provider logic, but it's the only option I found.
>
> If deploying custom per application providers doesn't fill in the Java
> Security Model, or if there's simply not the needed quorum to make
> that kind of decisions, what I think we could do is:
> - Mandate a new property to specificy where to load the classes from,
> leaving thecnical details to implementors (thus not requiring a
> specific folder/path to be created).
> - Provide some hooks for dynamic configuration: something like
> add/removePermission(WebRoleRefPermission), getAllRoles(Subject), etc.
> - Provide a base implementation that users can use. Arjan's example
> implementation would be a good starting point.
> - Standarize caller/principal and role/principal anrepresentation.
> Again, Arjan's proposal on CallerPrincipal and GroupPrincipal[5]
> sounds pretty good.
> - Improve TCK
>
> If JSR 375 could mandate servers to provide a JACC that implements
> some methods even in a propietary way, I'd personally be happy with
> that as a starting point. What do you think of that?
>
>
> [1]
> https://docs.jboss.org/author/display/WFLY10/Java+Authorization+Contract+for+Containers+%28JACC%29
> [2]
> https://github.com/ggam/Payara-Server-Documentation/blob/eec7c0582444acf5b52c30e18832d4e6213f1ba8/documentation/core-documentation/jacc.md
> [3] https://java.net/jira/browse/SERVLET_SPEC-157
> [4]
> http://arjan-tijms.omnifaces.org/2015/03/java-ee-authorization-jacc-revisited.html
> [5]
> http://arjan-tijms.omnifaces.org/2014/02/jaas-in-java-ee-is-not-universal.html
>
> On Mon, Jul 11, 2016 at 9:09 PM, Ron Monzillo <ron.monzillo_at_oracle.com
> <mailto:ron.monzillo_at_oracle.com>> wrote:
>
> Arjan and Guillermo,
>
> Thanks for the taxonomy of possible solutions. FWIW, the first three
> seem most compatible with the JACC SPI and policy enforcement model.
>
> Regarding the 1st, please note that I was not advocating that JACC
> make it mandatory for JACC providers
> to be loaded via the extension mechanism, but I would be
> interested in investigating whether
> it would be reasonable to recommend that the extension mechanism
> be used as a universally
> supported provder loading mechanism.
>
> As I understand the platform spec, all compatible containers are
> required to support the
> extension loading mechanism. If so, that existing requirement
> should be sufficient to bootstrap
> JACC in a common way on all application servers and then, within a
> specific JACC provider
> you could bootstrap the per application policy environment you
> are seeking (I presume as part of JSR 375).
>
> If the extension mechanism is not suitable for use by JACC, then I
> think we should consider requiring support
> (in JACC) for an approach like the other 2 of your first three.
>
> That said, if JSR 375 were to use JACC in this fashion, it would
> likely interfere
> with the existing use of JACC by the container...; which suggests
> that what you are looking for
> would require fundamental changes to JACC or its use model; as
> suggested by your reference to the
> JASPIC factory (as precedent for per application policy enforcement).
>
> The JACC model is basically a common policy enforcement engine
> applied to per application policy; in
> which any application context required to enforce application
> specific policy is made available to the
> policy enforcement engine via a combination of callbacks and
> interceptors.
>
> It looks like you are looking for per application policy
> engines/logic, and I guess I'd like to
> get a better handle on your use cases, before I am convinced that
> it would be useful to
> standardize per application Policy providers as part of JACC.
>
> It would also help if you can clarify what you are looking for
> from JACC.
> JACC will cause the container to convey the policy rules (obtained
> from DD's and annotations)
> to your provider via the policy configuration interface. JAcCC
> will also cause the container to invoke
> your provider to make pre-dispatch and programmatic access checks.
>
> Ron
>
>
> On 7/8/16 6:30 PM, arjan tijms wrote:
>> Hi Ron,
>>
>> Great hearing from you!
>>
>> On Fri, Jul 8, 2016 at 5:01 PM, Ron Monzillo
>> <ron.monzillo_at_oracle.com <mailto:ron.monzillo_at_oracle.com>> wrote:
>>
>> Note that does NOT rule out the possibility of replacing the
>> JRE scoped
>> Policy provider, with a provider that loads and delegates to
>> application specific providers...
>>
>>
>> That would ultimately be what's needed. With that JSR 375 can
>> install it's own provider for a single web app, just like it
>> currently installs its own JASPIC SAM and then builds on top of that.
>>
>> JSR 375 could then provide its own API to provide access to the
>> (in-memory) collection of permissions (like WebResourcePermission).
>>
>>
>> but I view the problem at hand,
>> as being where to put the replacement for the default java
>> Policy implementation class.
>>
>>
>> Indeed, that's problem number 1. As you may remember, I faced
>> enormous difficulties installing this replacement on servers like
>> Geronimo and JBoss.
>>
>> Closely related to that, it may be worth it to look into the
>> possibility of defining a standard JACC factory anyway to install
>> a global JACC provider from within a web app. After all, JASPIC
>> also allows one to set a global SAM (by proving a null for the
>> app context id).
>>
>> It might also be feasible to change JACC
>> such that it uses an application scoped Policy object that is
>> distinct from that used by the rest of the JRE, but at least
>> on the surface
>> that seems like a new version of JACC (or perhaps thats what
>> JSR 375 is).
>>
>>
>> JSR 375 definitely does not try to be JACC (or JASPIC for that
>> matter). At least, that's what I (and Alex back then) are trying
>> hard to avoid. What JSR 375 does attempt is first and foremost
>> providing a higher level, ease of use, abstraction/wrapper on top
>> of JASPIC and hopefully JACC.
>>
>> But as it stands, JSR 375 has a hard time "connecting" to JACC.
>> At most JSR 375 could provide a JACC provider that loads and
>> delegates to application specific providers, and then mandates
>> that IFF JSR 375 is used and IFF "some kind" of configuration is
>> encountered in the application, then the application server
>> vendor must make sure this JSR 375 provided JACC provider is
>> installed.
>>
>> But I'm not sure if this is really allowed, and if it's allowed I
>> think it puts a great burden on the application server vendor who
>> somehow has to make sure it works.
>>
>> I'd much rather use a portable API/SPI instead of demanding
>> something in the spec text and then hope it turns out well in
>> practice.
>>
>>
>> Also, since JACC requires compatibility with the JRE
>> security Policy replacement mechanism, so it may be feasible
>> to adopt
>> a uniform replacement strategy that is based on loading the
>> classes from within the extension or lib area of the JRE. I
>> am not sure
>> if that would be acceptable
>>
>>
>> JRE would be the absolute last resort. Java EE developers already
>> dislike modifying the application server for a single
>> application, but modifying the JRE is often a no go. The JRE on a
>> developer's desktop often runs many different application servers
>> and thus many different apps.
>>
>> Still, I tried putting the jar with the JACC provider there, and
>> Geronimo and JBoss specifically still would not find it :(
>>
>> and am interested in hearing of any other ideas you may have
>> as to defining where such (JRE-wide)
>> provider jars could be loaded from.
>>
>>
>> For Java EE this remains a difficult thing, as it typically tries
>> to avoid going into product details. So stating that the server
>> must provide a directory where it scans for the jar file is
>> difficult I think, as is requiring that there's a product
>> specific CLI or admin console function available that accepts a
>> jar containing a JACC provider.
>>
>> That said any of the following would be an improvement:
>>
>> * Mandating JACC providers be loaded from the JRE's extension folder
>> * Define a directory in the server, e.g. [glassfish home]/extensions
>> * Define an extra system property that contains the path to jar.
>> E.g.
>> -Djavax.security.jacc.policy.provider.location=/opt/myprovider.jar
>> * Define a new archive containing the JACC provider that can be
>> deployed standalone or as part of an ear, just like .rar archives
>> for JCA
>> * Work with the EG for the new Java EE Management API to have
>> them support the deployments of archives containing a JACC
>> provider (but this EG is rather quiet at the moment)
>> * Define a factory that applications can use to register the JACC
>> provider, just like applications can do for a JASPIC SAM.
>>
>> I somewhat ordered the list where latter items would IMHO be more
>> desirable solutions.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>> Ron
>>
>>
>> On 7/2/16 4:04 PM, arjan tijms wrote:
>>> Hi
>>>
>>> Thanks for starting this discussion. The current way to
>>> register a JACC provider is indeed too difficult . This was
>>> discussed a while ago as well, see
>>> https://java.net/projects/jacc-spec/lists/users/archive/2015-03/message/0
>>>
>>> In the current climate, a MR is not the easiest thing,
>>> unfortunately. Ron, what do you think?
>>>
>>> Alternatively, JSR 375 could provide a standard compliant
>>> JACC provider and then *demand* Java EE implementations to
>>> have this install by default. I don't know if this is
>>> feasible. Again a question to Ron; would you think this is
>>> reasonable or even allowed for a JSR to do?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jul 2, 2016 at 8:25 PM, Guillermo González de Agüero
>>> <z06.guillermo_at_gmail.com <mailto:z06.guillermo_at_gmail.com>>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I need to register my own JACC provider to change the
>>> default security behaviour of my application. Problem
>>> there's no standard mecanism to register a custom
>>> provider, and moreover, vendor specific mechanisms are
>>> incredibly difficult to use[1].
>>>
>>> I would like to have an option to register a custom JACC
>>> provider from a web module, just like we can already
>>> register a SAM. This could be a workaround for [2] and
>>> would facilitate JSR375 Security Spec to provide a more
>>> integrated solution.
>>>
>>> This change should be done in a MR and included in Java
>>> EE 8.
>>>
>>>
>>> Regards,
>>>
>>> Guillermo González de Agüero.
>>>
>>> [1]
>>> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorization-jacc-revisited.html
>>> [2] https://java.net/jira/browse/SERVLET_SPEC-157
>>>
>>>
>>
>>
>
>