Hi,
On Fri, Jul 8, 2016 at 5:01 PM, Ron Monzillo <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...
>
I see that as the best solution for bundling within the application. The
contract for the default JACC provider that is already mandated could be
changed in order to delegate to a specific application provider... and
maybe even a new simplified interface could be proposed for this
application bundled provider? Note that what people is (usuarlly) really
trying to achieve is not changing the provider itself, but to achieve a
behaviour that couldn't be done any other way. If changing the JACC
provider from an application is a problem, just creating a simplified hook
could do the trick for most cases. And anyway, a standarized way to change
the app server provider should be done.
On Sat, Jul 9, 2016 at 12:30 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> * 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
>
I don't think that's a good idea because of modular servers that use
separated class loaders. In JBoss for example, the JACC provider is loaded
as a module that is loaded from a separate class loader, and only have the
dependencies you specify. In my case, my dependency was in fact the Java EE
API.
* 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)
>
I think this is the way to standarize the registration system. A module
should be able to be deployed and then, maybe a system property could still
be used to determine one of the deployed providers should be used
(considering the restriction that only was could be active at any given
time).
> * Define a factory that applications can use to register the JACC
> provider, just like applications can do for a JASPIC SAM
>
Or, if the provider has to be JRE scoped, just define an SPI to modify hook
into a "Delegator JACC module". But in that case, we'd need to make sure a
proper delegator provider is available, which can't be taken for granted if
only one provider can be enabled and the user is able to change it. Anyway,
I see this as a complement to an standarized way to deploy providers, not
as a replacement for the current system.
Regards,
Guillermo González de Agüero.
On Sat, Jul 9, 2016 at 12:30 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi Ron,
>
> Great hearing from you!
>
> On Fri, Jul 8, 2016 at 5:01 PM, Ron Monzillo <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> 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
>>>
>>
>>
>>
>