| Re: [jacc-dev] Are servers required to provide a default JACC provider? |
(Please forward to jacc-dev if necessary; I'm not subscribed.)
I asked Ron Monzillo (JACC Spec Lead) about this and got this response:
the gist of the spec and its requirements may be summarized as follows:
Every compatible Servlet or EJB container must conform to the 3 subcontracts of JACC.
1. The Provider Configuration Contract
defines how a container must support pluggability of the implementation of its access control system
2. The Policy Configuration Contract
defines how a container deployment system must communicate the declarative and annotation based access control policy of the app to the pluggable access control system
3. The Policy Enforcement Contact
defines how a container must perform its access control decisions by checking permissions via the interfaces (Policy, SecurityManager, or the AccessControler) of the pluggable access control system.
iow, every JACC compatible servlet (or EJB container) is required to always use JACC for the 2nd, and 3rd subcontracts, and to support pluggability via the first. Thus Guillermo is correct that (JACC compatible) Java EE application servers are or at least were thus required to bundle and use a JACC provider.
We had discussed softening this requirement to allow containers to provide the required application-visible behavior in the absence of a custom JACC provider without actually using a JACC provider to do so, but to my knowledge the spec was never changed in that way. The Jakarta EE spec project should decide whether to loosen the spec in this way or to make the existing requirement more explicit.
Guillermo González de Agüero wrote on 10/ 1/18 09:18 AM:
Hi,
We recently had a discussion on the OpenLiberty mailing list [] whether Java EE application servers are required to bundle a default JACC provider.
My reading of Section 2.5 of the spec [2] is that application servers must provide an implementation of the PolicyConfigurationFactory and the PolicyConfiguration components, which effectively would mean that a JACC provider is present on the classpath: "Each JRE of an application server must be provided with classes that implement the PolicyConfigurationFactory class and PolicyConfiguration interface. These classes must be compatible with the Policy implementation class installed for use by the JRE."
If we look at the recently open sourced TCK, there's a test for that assertion [3][4], but from what I can see, it is broken: it installs the PolicyConfigurationFactory and PolicyConfiguration implementations before checking they were already there, always passing.
The spec uses a somewhat cumbersome language and there's no clear hint that such default provider is required to be enabled. The JACC mailing list archives are available only from 2013 [5] but the spec haven't received much development after that time.
So my question is, was any public clarification made on what the spec actually meant? Did the EG reach a consensus on it?
Regards,
Guillermo González de Agüero