On 1/30/13 11:44 PM, David Blevins wrote:
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.
Hi David,
Thanks for the quick response and your willingness to consider support
for JASPIC.
To your question about existing auth modules, and configuration
providers; one area where we have been
working to develop and publish such examples is in the Nobis Open source
project; which is the reference
implementation for JSR 351, the Identity Api. The Identity Api addresses
use cases where an authentication
agent binds access to the identity attributes of the user; thus the
present of jsr 196 agents within the java.net
project of the RI.
http://java.net/projects/nobis
http://java.net/projects/identity-api-spec
Nobis has various components, and the JSR 196 related components are
available under
http://java.net/projects/nobis/sources/git/show/Nobis/authentication
where you can find
http://java.net/projects/nobis/sources/git/show/Nobis/authentication/facebook-relying-party?rev=c7ef9b46801f968564b56076ce6cd5784447c5c0
http://java.net/projects/nobis/sources/git/show/Nobis/authentication/saml-relying-party?rev=c7ef9b46801f968564b56076ce6cd5784447c5c0
In their current form I would characterize both of the above as "proof
of concept", although we fully expect them to be refined such that they
can be widely adopted.
Nobis also includes some utilities and base classes to facilitate the
development of auth modules, and we have also developed a
portable AuthConfigFactory and JAAS based AuthConfigProvider which we
will also be submitted to Nobis. We will also be adding
more documentation to describe the use and configuration of the factory,
the JAAS config provider, and of each of the auth modules.
As Markus has shown, there are also various other places where auth
modules are being developed and made available.
I like you idea of a litmus test for inclusion in the web profile. I
look at it this way. The current required to be supported Servlet
authentication
mechanisms are mostly inadequate, if not completely inappropriate. One
problem they share, is that they all place the
Servlet container on the path between the user and the password
validation service, such that whenever a user is required to authenticate
with a web app, the user must pass its password through the Servlet
container on to the password validation service or realm; which
means that every app that requires us to authenticate, represents a site
where a uer password can be exposed, or misappropriated.
Conversely, its not like we can just add to the list of required to be
supported mechanisms, since fixing this problem mostly amounts
to there being 3rd party identity services that our users can expect our
application servers to accept as authentication authorities, and
the landscape of authentication authorities and the authentication
dialogs that they require is an evolving landscape. In this context,
what the platform needs is an ability to integrate agents of such
identity services (e.g., authentication modules); which is what the Servlet
Profile of JSR 196 makes possible (in a manner that is fully integrated
with Servlet's declarative authorization model).
Ron
-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.
