Hi,
On Mon, Jul 11, 2016 at 9:09 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
> Thanks for the taxonomy of possible solutions. FWIW, the first three
> seem most compatible with the JACC SPI and policy enforcement model.
>
These first three would help most with using JACC in the traditional way,
which is something that can be currently quite a challenge.
Guillermo btw is doing a great job documenting how it's done for existing
servers. For JBoss adding a custom JACC provider was previously practically
impossible, but thanks to recent work done by Red Hat and Guillermo's
documentation it's now clear. See
https://docs.jboss.org/author/display/WFLY10/Java+Authorization+Contract+for+Containers+%28JACC%29
> 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).
>
For JSR 375 the goal is more or less:
"to have basic security working without the need of any kind of vendor
specific configuration, deployment descriptors, or whatever. ”
So therefor it's not really in the spirit of JSR 375 to have to ask the
user to take a jar that's already offered by the platform, and then copy
this to e.g. the JRE extension folder in order to activate some JSR 375
features.
The idea is that an application can be deployed to any unmodified Java EE
server in it's default configuration and work. Putting certain aspects of
security (JASPIC SAMs, identity stores, configuration, etc) outside the
application remains supported, of course, but things also have to work with
fully contained application archives.
> It looks like you are looking for per application policy engines/logic,
>
That's correct.
> 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.
>
In broad lines there are several goals.
The first one is to make JACC extensible by other frameworks. Although JSR
375 hasn't yet started to really look at the authorization epic, the fact
that JACC is an existing "hook" into the pre-dispatch check from the
(Servlet) container would open up many advanced possibilities. Without
standardised per application Policy providers, I wouldn't know how JSR 375
can really build on JACC in a standard way.
So the use case is framework extensibility here.
The second one is to make "authorization engines" accessible to developers.
As we've seen a lot of times, the overwhelming majority of developers sees
specs that they can't readily code agains and test from their .wars as
alien and "not something for them". As soon as developers can test code
from within their application archive, they suddenly see it as something
that's available to them.
So the use case is developer friendliness here.
The third one is providing a default JACC provider transparently. This may
also be solved by a more strict enforcement of the spec and/or TCK, but the
fact of the matter is that currently some servers don't ship with a default
JACC provider. They only allow you to install a custom JACC provider. This
means you can't ask the container a question like: "Will the current
authenticated identity have access to web resource /foo/bar", which is a
very valuable thing to be able to ask (web frameworks use it to e.g.
determine whether to omit rendering a link to such resource, or render it
in a special way).
So the use case is portability here.
> 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.
>
Practically what JSR 375 could add here is what Guillermo has been asking
for; add the policy rules that now come from the deployment descriptor or
annotations programmatically, via e.g. a similar kind of API that the
Servlet spec now uses to e.g. programmatically add a Servlet.
Another thing that JSR 375 could add is a strongly simplified
"authorization module", based on CDI likely, where the user basically could
only implement the commit() method of the PolicyConfiguration interface.
The state machine, and the methods used to collect permissions (like e.g.
addToExcludedPolicy) would all be defaulted and these default
implementations provided by JSR 375.
Likewise the Policy could be fully or partially defaulted as well, so that
the application programmer can quite simply add a few custom programmatic
rules (like e.g. role Manager has permissions X and Y, but only during
office hours), and then delegate the rest of the normal processing to the
default JACC provider. Currently if a programmer wishes to only add such
custom rule, an entire Policy implementation has to be provided, which is
relatively hard and a lot of work. (see e.g. TestPolicy here
http://arjan-tijms.omnifaces.org/2015/03/java-ee-authorization-jacc-revisited.html
)
Those custom rules would also need to be set per application, as e.g. "role
Manager has permissions X and Y, but only during office hours" is highly
specific to a single application.
For JSR 375 we were thinking to add some semi declarative options here
using a combination of annotations and expression language, perhaps
something like
@AuthorizationRule("role('Foo').valid(time > officehours.start and time <
officehours.end)")
I think JACC would be a perfect base for these use cases.
Ideally it would be something like:
* .war doesn't need custom authorization rules -> default JACC provider used
* .war needs custom rules -> JSR 375 app specific JACC provider installed
default JACC provider --- delegates to ---> JSR 375 provider
The JSR 375 provider would then be specified to have a default
implementation of the policy enforcement that has to adhere to the
requirements of a JACC default provider, but would be application scoped
and would have the extra features as mentioned above.
Hope this makes it more clear.
Kind regards,
Arjan Tijms
> 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>
> 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>
>> 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>
>>> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorization-jacc-revisited.html
>>> [2] <https://java.net/jira/browse/SERVLET_SPEC-157>
>>> https://java.net/jira/browse/SERVLET_SPEC-157
>>>
>>
>>
>>
>
>