[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openejb-development
Subject:    Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in TomEE
From:       Ron Monzillo <ron.monzillo () oracle ! com>
Date:       2013-01-31 20:24:59
Message-ID: 510AD31B.7070201 () oracle ! com
[Download RAW message or body]

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"<david.blevins@gmail.com>  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<ron.monzillo@oracle.com>  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.
>>

[prev in list] [next in list] [prev in thread] [next in thread]