Hi,
On Tue, Jul 12, 2016 at 4:39 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
>
> Sorry, I meant ServletContainerInitializer, and my point was that
> containers "appear" to also be required to support
> the loading of an Initializer that is not bundled in a JAR file inside the
> WEB-INF/lib directory of an application, and that
> will be applied to all apps. which I think presents the same problem as
> we are facing with the placement and
> loading of a jacc provider.
>
Interesting, I haven't seen that usage before for a
ServletContainerInitializer, but if that's indeed required it would present
the same problem. There are various other artefacts that have this same
problem for sure though; JASPIC SAMs, JDBC drivers and DataSources for
instance.
> fwiw, you *may/should* be able to call the jacc PolicyConfiguration api
> from your context listener;
>
That's a good suggestion, and for Guillermo's specific case may be worth
trying indeed. Thanks!
> 1. the api does not provide routines to let you see what constraints have
> already been defined in
> a PolicyContext
>
Indeed, so this is perhaps a similar discussion as we had for JASPIC.
Should JACC be extended with convenience methods/utilities, or should JACC
mostly stay as it is (small and focussed), and let JSR 375 add some higher
level conveniences?
In the latter case, JSR 375 could define a more specialised
PolicyConfiguration that is very specific about how the constraints are
stored.
E.g. a little bit like what we do in OmniFaces (were we parse web.xml
manually instead of using JACC). See
https://github.com/omnifaces/omnifaces/blob/2.4/src/main/java/org/omnifaces/config/WebXml.java#L368
For JACC itself that maybe wouldn't be such a good idea since JACC is much
more universal applicable and abstract.
> 2. the spec should probably explicitly define that you can do this, and
> prescribe what calls can and must be made.
>
That by itself certainly wouldn't hurt either.
Kind regards,
Arjan Tijms
>
>
> Ron
>
>
> 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>
>> 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>
>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>