On 7/12/16 10:09 AM, arjan tijms wrote:
> Hi,
>
> On Tue, Jul 12, 2016 at 3:52 PM, Ron Monzillo <ron.monzillo_at_oracle.com
> <mailto: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.
>
>
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.
> 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?
yes, I guess that limits its applicability in your use case.
fwiw, you *may/should* be able to call the jacc PolicyConfiguration api
from your context listener; although
1. the api does not provide routines to let you see what constraints
have already been defined in
a PolicyContext
2. the spec should probably explicitly define that you can do this, and
prescribe what calls can and must be made.
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 <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
>>>>
>>>>
>>>
>>>
>>
>>
>
>