Hi,
On Tue, Jul 12, 2016 at 3:52 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
> 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.
>
A ServetContextInitializer can conveniently be loaded from a .jar inside
WEB-INF/lib of a .war, so that's perhaps a bit of a different situation. It
uses the jar service loader mechanism if I'm not mistaken.
> 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.
>
Maybe I'm totally mistaken, but I thought that one only applied to Servlets
that have been dynamically added to begin with, not for Servlets that were
already statically defined (e.g. in web.xml or using the @WebServlet
annotation). I could be wrong here though. Guillermo, I seem to remember
you tried somewhere there, was it that method?
Kind regards,
Arjan Tijms
> 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>
> 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>
>> 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>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>
>>>> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorization-jacc-revisited.html
>>>> [2] <https://java.net/jira/browse/SERVLET_SPEC-157>
>>>> https://java.net/jira/browse/SERVLET_SPEC-157
>>>>
>>>
>>>
>>>
>>
>>
>
>