Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in TomEE

Thu, 31 Jan 2013 12:25:39 -0800 

On 1/31/13 1:14 AM, Romain Manni-Bucau wrote:

Hi,

Personally i find it a bit too complicated compared to some not javaee
alternative to be a choice for the future.

Today something based on CDI sounds really more reasonable.


Hi Romain,
I agree that there is some complexity in the spi; however, most of that is carried 
by parties other than the auth module developer.

For example the spi supports 3 dimensions of pluggability.
The AuthConfigFactory - the mapping of layer and applications to configuration providers; when no such mapping exists for an app (at a layer), jsr 196 is not configured for the app at that layer. All web containers can use a common portable AuthConfigFactory, but most containers prefer to provide their own factory that is well integrated with their proprietary configuration systems. In any event development of an AuthConfigFactory when done represents complexity that the 
container developer chooses to take on and takes responsability for.
The AuthConfigProvider- provided configuration objects that define the auth module configurations for an app at a layer. Depending on the AuthConfigProvider, it may define different auth module configurations for different requests to the app at the layer. Web Containers have typically developed proprietary AuthCOnfigProviders that interpret module configuration attributes in proprietary deployment descriptors. Portable AuthConfigProviders such as the JASS AuthConfigProvider, I mentioned previously are also available. Once developed these providers can be registered in any AuthConfigFactory, where that enable the use of the widely known jass configuration syntax to 
configure authentication modules for web applications.
The AuthModule - this is the component that embodies the authentication mechanism implementation; and should be the only thing that the authentication mechanism developer needs to focus on. FWIW, the feedback that we have received in this regard, is that implementing an authentication module is relatively straight forward (and in most case much simpler than other alternatives). In Most cases, this amounts to implementing 2 methods, init, and validateRequest.
On the side of the container runtime, there is also some work to do; and that basically amounts to 2 tasks.
1. put the calls to the spi in the container runtime (as shown in my prior message) 2. develop a callback handler that can handle the callbacks required to be supported by the profile. 

Ron


My 2cts...
Le 31 janv. 2013 05:45, "David Blevins"<[email protected]>  a écrit :


Hi Ron,

I saw the note on the Java EE 7 EG and haven't had the bandwidth to
investigate and respond.  Your note is fantastic, especially the code
snippet.

You mention Facebook Connect, which is interesting.  Is there a Facebook
Connect JASPIC Provider?  If so, where is the code for that?  If you have
links on where to get other providers, that helps too.

My hesitation for immediately and blindly saying "yes" to its inclusion in
the Web Profile is simply because Java EE is full of incomplete security
APIs few people use and for which there are even fewer to no providers.  I
don't know if this describes JASPIC, but it has been out there for a major
spec revision and it's not immediately clear if it has that "can't live
without" quality I expect in a Web Profile spec.

Cc'ing Markus as he was the one who brought it up on JavaEE 7.  I suspect
he might have some thoughts on what makes it a good candidate for the Web
Profile.

Certainly, we can support it in TomEE+ at some point.


-David

On Jan 30, 2013, at 4:03 PM, Ron Monzillo<[email protected]>  wrote:


TomEE Experts,

The Servlet Profile of JSR 196 defines the use of the JASPIC SPI in

support of the portable integration

of new and/or custom authentication mechanisms in compatible Servlet

containers.

The Profile is a required component of all Full Platform EE Web

Containers, and we are receiving requests

for the profile to become a required component of the EE web profile. To

that end, we are contacting

standalone and EE web profile Servlet containers to determine if there

is interest in adopting the profile.

For those unfamiliar with JASPIC, the SPI is a general purpose facility

that applies the concepts of pluggable

authentication as defined by PAM and JAAS to the realm of message

authentication. The Servlet profile applies

the SPI to the realm of HttpServletRequest message authentication in the

context of servlet security constraint

processing. The SPI was defined to support complex challenge response

authentication protocols, and has

been shown to be an effective means to integrate portable

implementations of new internet authentication

mechanisms (e.g. Facebook Connect, and SAML WEB SSO) in compatible

Servlet containers.

Does the TomEE community support the inclusion of the Servlet profile of

JSR 196 in the EE web Profile?

thanks,

Ron Monzillo

------
More details:

The requirements of the profile are spelled out in chapter 3 of the

JASPIC specification:

http://download.oracle.com/otndocs/jcp/jaspic-1.0-mrel-eval-oth-JSpec/

and use of the SPI is described in high level terms in the javadoc:

which can be accessed at:



http://docs.oracle.com/javaee/6/api/javax/security/auth/message/config/package-frame.html

Support for the profile by a servlet container mostly amounts to making

a few calls to the spi in the

context of the processing of servlet requests. The pattern is basically

as follows:

// determine if a pluggable auth module is configured for the current

application

AuthConfigProvider provider =

AuthConfigFactory.getFactory().getConfigProvider("HttpServlet",appID,listener);

if (provider != null) {
   /if yes, get the server side configuration provider that applies to

the application

    ServerAuthConfig config =

provider.getServerAuthConfig("HttpServlet",appID,cbh);

    // for each request to the application
    // get the configuration of authentication modules that applies to

the request

    messageInfo.setRequestMessage(httpServletRequest);
    messageInfo.setResponseMessage(httpServletResponse);
    String authContextID = config.getAuthContextID(messageInfo);
    ServerAuthContext context =

config.getAuthContext(authContextID,serviceSubject,properties);

    // invoke validateRequest on the module configuration; which will

invoke the configured auth modules

    AuthStatus status =

context.validateRequest(messageInfo,clientSubject,serviceSubject);

    if (status == AuthStatus.SUCCESS) {
        // Use the proprietary interfaces of the container to set the

userPrincipal on the request

        // proceed to authorize and invoke the servlet request as

appropriate

    } else {
        // extract the response from messageInfo and return (it may be a

challenge or an error message,

        // and will have been established by the auth module
    }
} else {
   // do what the container would do in the absense of jsr 196
}

------

I noticed that TomEE includes support for connector, A related use of

the JASPIC spi is in connector, where

the connector inflow contract requires the use of the JASPIC

CallerPrincipalCallback by the resource adapter

to set an authentication identity of the inflow.

Reply via email to