Hi,
On Fri, Mar 27, 2015 at 11:02 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
> If it is not already easy, it should be easy to know where to put the jars
> containing these classes. In Servlet, there are siilar cases, where you need
> to know where to put jars if you want them to be scanned (for example). It
> seems to me that part of this could be fixed by
> requiring some documentation... but, at least for jaspic, there would
> remain the problem of where to convey module specific configuration data,
> and
> obtained by the AuthConfig and passed through to the SAM. As i mentioned
> previously, it seems like JASPIC should define an interface for
> module initialization properties, which could be implemented and included
> in various places (such as within an application archive).
>
Something to think about for sure. The default mechanism where the options
map is passed to the initialize method works for when the SAM is placed at
the container side and configured there, or when it's embedded in the
application and configured there. It indeed doesn't really work so well
when the SAM is container side, but the configuration is per application
and at the application side.
>
> The idea would then be:
>
> GlobalJaccPolicy#implies --- calls ---> ApplicationJaccPolicy#implies
>
> yes, but to make that work, the top level provider would be required
> to support internal configuration of per app provider implementations
> which may rarely be necessary.
>
Well, the idea was that the PolicyConfiguration would be delegated to as
well, but I tried to keep the example brief ;)
So more complete it would be:
GlobalJaccPolicyConfiguration#addToUncheckedPolicy --- calls -->
ApplicationJaccPolicyConfiguration#addToUncheckedPolicy
[...]
GlobalJaccPolicy#implies --- calls ---> ApplicationJaccPolicy#implies
This would just be the default. The top-level/global default
implementations check if there's an application provided one and if so they
use this, otherwise they follow the standard process. Here it would be an
error if the application provided a Policy but not a Configuration and the
other way around.
Optionally, as a simplification, the top level default PolicyProvider could
just collect Permission instances in 3 collections (one for excluded,
unchecked and per-role) and make these available for injection into a
simplified ApplicationJaccPolicy. Of course it would only need to do this
if it detected earlier that the application indeed provided such a Jacc
Policy.
Just an initial sketch, but then the application policy could look a little
like this:
@JaccPolicy
@ApplicationScoped
public class TestPolicy extends SimplePolicy {
@Inject @GlobalJaccPolicy
SimplePolicy globalPolicy;
@Inject @ExcludedPermissions
List<Permissions> excludedPermissions;
@PostConstruct
public void myCommit() {
// transform permissions here as needed
}
@Override
public boolean implies(List<Principals> principals, Permission
permission) {
// Do custom authorization checks here
// if needed, delegate back to global policy
return globalPolicy.implies(principals, permission);
}
// few other methods here
}
Note that it's really 2 ideas here:
1. An almost regular PolicyConfiguration and Policy, but provided by the
application
2. A simplified CDI based SimplePolicy, optionally provided by the
application
Kind regards,
Arjan Tijms
> PolicyConfig objects are per app, because they come to encapulate per app
> policy; but I don't think we
> intended to make it so that every top level Policy Provider could delegate
> to a different type of Policy Provider per app.
>
> Kind regards,
> Arjan Tijms
>
>
>
> Is this a case of the JACC and JASPIC specs not being up to dae, wrt to
> their use and alignment with requirements
> (for loading system level modules) that are already defined in the EE
> platform spec?
>
> I am still nor sure what the answer is here. I'll send another msg to
> the EE spec leads to see what they think; or if you want to
> please raise this issue with them.
>
> Ron
>
>
>
>
>
> Ron
>
> ps: regarding role mapper configuration, perhaps that can be seen as a
> case of some providers
> needing standard interfaces to access and used the container's native role
> mapping system. There
> may be other cases where the intent is to provide an alternative role
> mapper for use by the container;
> in which case there would need to be some way (perhaps within a JACC or
> JASPIC provider) of providing the/a
> role mapper.
>
>
> On 3/27/15 1:47 PM, arjan tijms wrote:
>
> Hi,
>
> Both JACC and JASPIC ask that jars containing the implementation of a
> JACC provider resp. authentication module are placed on the server's
> classpath.
>
> Specifically JACC has specified 2 VM level properties for that purpose:
>
> -Djavax.security.jacc.policy.provider=test.TestPolicy
>
> -Djavax.security.jacc.PolicyConfigurationFactory.provider=test.TestPolicyConfigurationFactory
>
> Unfortunately, an increasing number of servers use modular classloaders,
> and *the* server classpath barely exists. In such servers it's nearly
> impossible to get the server to use a custom JACC provider.
>
> In some occasions, seemingly the only way to get your own JACC classes
> into the server is to inject them into an existing server jar file, which
> is nothing short but a terrible hack.
>
> I described the process for GlassFish, WebLogic and Geronimo here:
> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorization-jacc-revisited.html
>
> Additionally for development purposes, even if the JACC provider can be
> relatively easy integrated with the server, the current situation is not
> ideal.
>
> Now something like JCA has defined the concept of a resource archive
> (.rar) which can be used to integrate a connector into a server by either
> embedding the resource archive within an ear, or by deploying it standalone
> just like one would deploy a .war.
>
> I wonder, would it make sense to define something like that for both
> JACC and JASPIC? (for JACC this would be more important, since it doesn't
> have the programmatic registration option from within an application
> archive that JASPIC does have).
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>