Hi,
Thanks for the reply!
On Fri, Aug 19, 2016 at 3:52 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
>
>
> As for API changes I think only the following 4 methods would have to be
> added:
>
> PolicyConfigurationFactory#setPolicyConfiguration(String contextID,
> PolicyConfiguration policyConfiguration)
> PolicyConfigurationFactory#getPolicyConfiguration(String contextID)
>
> PolicyConfigurationFactory#setPolicy(String contextID, Policy policy)
> PolicyConfigurationFactory#getPolicy(String contextID)
>
> The JACC spec would then have to be updated to take the above into account.
>
> Thoughts?
>
> While I may not fully understand the changes you are proposing, it seems
> like the proposal
> seeks to decouple the factory from the config and policy subsystems.
>
Indeed, for the standard/default JACC provider and the application specific
policy configuration and policy implementation there's a certain amount of
decoupling.
> So I am wondering why you can't begin by changing the PCF implementation,
> with one that looks in some factory specific repo of deployed
> policy configs (and perhaps policy impls), that captures info about all
> deployed apps, including those for e.g., in which some CDI mechanism
> takes the policy impl out of the app (perhaps with the help of a
> ServletContainrInitializer).
>
> Wouldn't that obviate the need for the new set methods that you are
> proposing?
>
That would not fully obviate the need, but more like move the need to
somewhere else (which wouldn't have to be a bad thing).
The ServletContainerInitializer would need some (standard) way to insert
the application policy configuration and policy implementation in this
factory specific repo. As my POC proves, this can be done today with a
custom JACC provider (which indeed uses CDI). But I was now looking for
something that could be added to the spec. That way applications can take
advantage of JACC without requiring a custom JACC provider to be installed
in a server specific way.
To that end, there has to be a setPolicyConfiguration(String contextID,
PolicyConfiguration policyConfiguration) somewhere. It may be on the
PolicyConfigurationFactory, or it may be elsewhere, but it has to exist
somewhere.
In other words the "factory specific repo of deployed policy configs (and
perhaps policy impls)" has to be standardized ;)
> I guess the point is that you can't standardize the application embedded
> deployment model you are advocating such that it works on all jacc
> providers,
> unless you require that all jacc providers work with arbitrary/application
> specific policy impls (and perhaps policy configs).
>
With "all jacc providers", the idea is that it would hold for all *default*
JACC providers. If the user installs a custom JACC provider, then that
custom provider can do whatever it wants and does not have to delegate.
As a code example (leaving out the PolicyConfigurationFactory for brevity):
public class PolicyRegistrationInstaller implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
PolicyConfigurationFactory.getPolicyConfiguration(PolicyContext.getContextID(),
new MyPolicy());
}
}
// This Policy implementation is installed by a Java EE product by default
public class DefaultPolicy extends Policy {
@Override
public boolean implies(ProtectionDomain domain, Permission permission) {
Policy appPolicy
= PolicyConfigurationFactory.getPolicyConfiguration(PolicyContext.getContextID());
if (appPolicy != null) {
return appPolicy.implies(domain, permission);
}
// ... normal code
}
}
Hope that makes it more clear. I'll take a look if I can make another POC
that more clearly demonstrates the above with real code.
>
> Ron
>
> ps: how would PolicyConfigurationFactory#getPolicyConfiguration(String
> contextID)
>
Was there some text missing here perhaps?
Kind regards,
Arjan Tijms
>
> btw, I will be unavailable again until next Tuesday
>
>
> Kind regards,
> Arjan Tijm
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 13, 2016 at 12:37 AM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> On Tue, Jul 12, 2016 at 8:52 PM, Guillermo González de Agüero <
>> z06.guillermo_at_gmail.com> wrote:
>>
>>> I suppose that's what Mojarra does with its ServletContainerInitializer
>>> that maps Faces Servlet to "*.jsf" if any JSF annotation is present, right?
>>> I could do some tests, but I think they simply work the same way as any
>>> user provided library.
>>>
>>
>> I wonder if this usage is what Ron was referring to. In that case it's
>> "just" the regular jar service loader mechanism that is invoked for every
>> container jar that's activated by the application server for a deployed
>> application. It indeed works the same way as when put into a jar inside
>> WEB-INF/lib. CDI extensions, which are also present in container jars, also
>> work in the exact same way.
>>
>>
>> Low level APIs are and will be the the base for future frameworks and
>>> specs. IMHO, we should try to make them as developer friendly as possible,
>>> without losing focus.
>>>
>>
>> Indeed, so that would get us into the realm of software architecture ;)
>> Which responsibilities need to be put where.
>>
>> If you look at JSF and Servlet (just to take 2 examples), you clearly
>> don't want to put everything JSF does into Servlet. JSF is a much higher
>> level and much more specialised web framework than Servlet is. Yet, a
>> couple of things that were initially put into JSF were later deemed
>> low-level enough to be pushed down to Servlet (the so-called mapping API in
>> Servlet 4 is an example).
>>
>> Likewise here, there are quite a number of things that are best fixed in
>> JACC and JASPIC respectively. Hence the request for both a JACC and JASPIC
>> MR ;)
>>
>> Other things are clearly better at home in JSR 375. E.g. something really
>> applied like the LDAP Identity store is something you most likely don't
>> want in an SPI like JASPIC, but fits perfectly within JSR 375.
>>
>> Some things are at the intersection, and those are the most difficult
>> ones.
>>
>> But just like JASPIC, getting JACC to work flawlessly everywhere is big
>> prerequisite for even thinking to build upon it. For JASPIC it's now nearly
>> 4 years that I've been building the JASPIC tests and reporting failures to
>> the various vendors (it's amazing how time flies).
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>>
>>>> In the latter case, JSR 375 could define a more specialised
>>>> PolicyConfiguration that is very specific about how the constraints are
>>>> stored.
>>>>
>>>> E.g. a little bit like what we do in OmniFaces (were we parse web.xml
>>>> manually instead of using JACC). See
>>>> <https://github.com/omnifaces/omnifaces/blob/2.4/src/main/java/org/omnifaces/config/WebXml.java#L368>
>>>> https://github.com/omnifaces/omnifaces/blob/2.4/src/
>>>> main/java/org/omnifaces/config/WebXml.java#L368
>>>>
>>>> For JACC itself that maybe wouldn't be such a good idea since JACC is
>>>> much more universal applicable and abstract.
>>>>
>>>>
>>>>
>>>>> 2. the spec should probably explicitly define that you can do this,
>>>>> and prescribe what calls can and must be made.
>>>>>
>>>>
>>>> That by itself certainly wouldn't hurt either.
>>>>
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> 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>
>>>>>> https://docs.jboss.org/author/display/WFLY10/Java+Authorizat
>>>>>> ion+Contract+for+Containers+%28JACC%29
>>>>>> [2]
>>>>>> <https://github.com/ggam/Payara-Server-Documentation/blob/eec7c0582444acf5b52c30e18832d4e6213f1ba8/documentation/core-documentation/jacc.md>
>>>>>> https://github.com/ggam/Payara-Server-Documentation/blob/eec
>>>>>> 7c0582444acf5b52c30e18832d4e6213f1ba8/documentation/core-doc
>>>>>> umentation/jacc.md
>>>>>> [3] <https://java.net/jira/browse/SERVLET_SPEC-157>
>>>>>> https://java.net/jira/browse/SERVLET_SPEC-157
>>>>>> [4]
>>>>>> <http://arjan-tijms.omnifaces.org/2015/03/java-ee-authorization-jacc-revisited.html>
>>>>>> http://arjan-tijms.omnifaces.org/2015/03/java-ee-authorizati
>>>>>> on-jacc-revisited.html
>>>>>> [5]
>>>>>> <http://arjan-tijms.omnifaces.org/2014/02/jaas-in-java-ee-is-not-universal.html>
>>>>>> 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>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>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/myp
>>>>>>> rovider.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>
>>>>>>>> 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>
>>>>>>>>> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorizati
>>>>>>>>> on-jacc-revisited.html
>>>>>>>>> [2] <https://java.net/jira/browse/SERVLET_SPEC-157>
>>>>>>>>> https://java.net/jira/browse/SERVLET_SPEC-157
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>