users@javaee-spec.java.net

[javaee-spec users] Re: CDI support in JASPIC

From: Ron Monzillo <ron.monzillo_at_oracle.com>
Date: Fri, 01 Feb 2013 16:34:47 -0500

On 1/31/13 6:10 PM, arjan tijms wrote:
> Hi,
>
> On Thu, Jan 31, 2013 at 9:50 PM, Ron Monzillo <ron.monzillo_at_oracle.com
> <mailto:ron.monzillo_at_oracle.com>> wrote:
>
> Arjun is also correct that another core value proposition of the
> spi is that it provides for the integration of authentication
> agents within the servlet constraint processing and programming
> model; in a fashion analogous to the native
> required to be supported authentication mechanisms.
>
>
> It's maybe a slightly different topic, but since these native
> authentication mechanisms came up: what about requiring compliant Java
> EE implementations in the future to implement these native mechanisms
> via JASPIC?
>
> In that scenario, JASPIC would automatically be fully used, instead of
> being a somewhat alternative API. These SAMs would not be portable of
> course, since their implementation would still be vendor specific, but
> it would mean users could work with them in the same way as custom
> JASPIC SAMs. If additionally the class names of those SAMs would be
> standardized, users could even stack or decorate them in a portable way.
>
Hi Arjan,

Sorry for the delay in responding. I tend to think the benefit provided
by JASPIC is in making
new mechanisms, or new implementations of old mechanisms possible. I
think it best to
leave it up to container vendors to decide whether they want to
transition their existing authenticators.
Maybe that will change; especially if vendors start adopting the
suggestion you have made.
>
> You can certainly bundle a SAM in you application, in which case,
> I think you would need to register an authconfigprovider for your
> app, and configure it with the auth module contained in your app,
> and I think you will need to do so, at the point where you
> application embedded sam is available for loading, and your
> application has not yet been initialized
> to receive requests.
>
>
> Yes, this is exactly how I did this earlier. I blogged about it and
> some of the issues I encountered here:
> arjan-tijms.blogspot.com/2012/11/implementing-container-authentication.html
> <http://arjan-tijms.blogspot.com/2012/11/implementing-container-authentication.html>
>
> A big problem was which "appContext" identifier to use for the
> registration. Maybe I'm missing something, but I couldn't find how to
> portably compute this ID at the time of registration. From my article:
>
yes, I am aware of that problem. and fwiw, in Glassfish we use a
proprietary api to obtain the virtual server name
at runtime (iow, it is not hardwired to "server"; its just that in the
default glassfish config the default virtual server
happens to be named server). I can see how this complicates things
during authconfigprovider registration, and had
hoped that this could be resolved using the portable servlet api, but I
don't yet see how to do so with the existing
servlet apis. one solution might be to allow a simpler formation of the
appcontext id, which does not include
the virtual host, while allowing the virtual host to be specified when
it is known. Perhaps the runtime could then
do the authconfigprovider lookup first with the id containing he virtual
server, and if that returns nothing, it could
repeat the lookup with the simpler form. I'll have to think about this
so more.

> - start quote
> Another hurdle is that the initial factory used for registering the
> factory-factory requires an "appContext" identifier. This identifier
> is specified to be either null, or be composed of the pattern
> [hostname] [space] [context path]. When the identifier is null, the
> registration is for all (web) applications, otherwise it's only for a
> specific one. Clearly when an application registers its own internal
> authentication module the latter form is needed. The problem is that
> this "hostname" part is not that easy to guess when doing programmatic
> registration at startup time. It's further defined as being a "logical
> host", but how does an app knows what its own logical host is? The
> situation is further complicated by the fact that all servers except
> JBoss EAP just use a constant here, which is simply "server". JBoss
> EAP however uses ServletRequest#getLocalName
> <http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getLocalName%28%29> here,
> which is a value that's only available during request processing and
> not during startup time. It seems likely that if internal application
> server code is doing both the registration and the subsequent lookups,
> this is not really a problem. The AS itself knows which key it used
> for registration and can easily use the same one for lookups later.
> But when user code needs to do a registration independent of the
> application server that later on does the lookup, this becomes a
> problem. Maybe JBoss has interpreted the spec wrongly and the logical
> host should really be the constant "server", but then the spec needs
> to be clarified here. If it really should be a logical host of some
> kind, then there also needs to be a way to express that the
> application doesn't care about this (for example by specifying "*" as
> a kind of bind-all). As it stands, the situation is highly confusing.
> - end quote
>
>
> I think we should take a closer look at why the configuration has
> been difficult. In the JAAS based auth config provider that I
> mentioned. All one needs to do is
> add a config entry to a jaas config file, a default can be defined
> to cover all other apps. And jsr 196 also provides the ability to
> say that for some apps, the jaas config
> and its default do not apply.
>
>
> Which JAAS based auth config provider is that exactly? If this config
> provider is by default available in a Java EE implementation and the
> mentioned config file can be embedded in the application archive, then
> it might indeed sound like a solution.
>
glassfish bundles the jaas authconfig provider (and factory) in a
(maven) security module called
JSR-196 Provider Framework Reference Implementation with artifact id
jaspic.provider.framework
This provider will also be made available from the Nobis project (we are
working to ensure it is portable)

> The difficulty in the traditional vendor specific approach is mostly
> that when a (new) user has to do this, he or she can't just read a
> Java EE text book and apply that knowledge step by step. At some point
> a switch is needed to some vendor specific documentation, which
> typically means wading through several documents. For experienced
> users this might no be so big of a deal (though it's often still a
> tedious job to find the right info for an AS you aren't acquainted
> with), but it's a quite intimidating step for new users.
>
> As for the Java EE 7 JASPIC MR issues (which came up at the JBoss
> site), I hope the following would be possible:
>
I am working on the MR and will look into all of the following
> - Clarify that HttpServletRequest#login is not supported by JASPIC for
> the moment. An exception should be thrown instead of an invocation of
> some default unrelated login module. If it would be possible to
> specify how JASPIC can really handle HttpServletRequest#login then
> this would be even better.
>
I think the exception approach sounds like a good one
> - Clarify what should happen for HttpServletRequest#authenticate.
> JASPIC implementations all seem to do the right thing already, but
> it's not in the spec.
>
in progress
> - An API or perhaps just a clarification for the appContext
> identifier, so an application can portably register an
> AuthConfigProvider just for itself.
>
I am not sure what can be done in this regard (I offered one suggestion
above)
> - Perhaps be more explicit about the fact that an application can
> register such an AuthConfigProvider for itself, and then if it does it
> should run in the same class loader as the application that registered
> it (most servers already do this).
>
I'll see what I can do
> - Specify more clearly what the AS for the Servlet profile should or
> should not 'remember' after a successful authentication between http
> request. Various servers that I looked at behaved quite differently
> here (see the above referenced blog).
>
this is on my list
> Things that might be too big for a MR, but would all be great:
>
I won't be able to do the following at this time, but would be happy to
work with you to see how they might be done.
of this group my priority would be upgrading the api to use more current
features of the java language.
> - A portable way to programmatically just register a SAM. Now
> application code has to go through an
> AuthConfigProvider, ServerAuthConfig and ServerAuthContext just to
> register a ServerAuthModule. The current way is doable and gives the
> user great flexibility, but sometimes all that's needed is to register
> that SAM, and then this is perhaps all a bit too much.
>
> - A declarative standardized way to register just a SAM; for the
> Servlet Profile, web.xml and optionally an annotation (like
> @DataSourceDefinition) would be most suitable.
>
> - Update of all APIs to use at least Java 5 syntax. Just using
> generics for the various maps in the SPI would be a great start.
one additional item that I am working on is fixing the erroneous throws
descriptions in the javadoc of some of the AuthConfigFactory
methods.
> Thanks again for looking into this!

thanks for all your help with this,

Ron
>
> Kind regards,
> Arjan Tijms
>
>
>