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>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
>>
>
>
>