Hi Arjan and Guillermo,
Regrading an MR, hopefully that will be feasible as part of the Java EE
8 plans.
I agree there is a problem with the 1st subcontract of the JACC spec,
i.e., the Provider Configuration Contract, as it
does not describe how the Provider implementation classes are made
available to the class loading system.
We had expected that the location from which provider jars could be
loaded would be defined by the Platform spec.
Note that the jacc replacement mechanism is per JRE, not per
application, so I don't think this is a case where bundling
the provider within an application would be appropriate. 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...but I view the problem at hand,
as being where to put the replacement for the default java Policy
implementation class. 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).
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, 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.
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
>
>