Hi,
On Sat, Mar 7, 2015 at 1:03 AM, Pedro Igor Silva <psilva_at_redhat.com> wrote
> Seems like a general consensus that JEE security is missing features and
a more developer/application oriented way to do security. Being JEE
strongly based on container's services, security is something that must be
flexible and easy enough to be used by devs and apps, otherwise people will
just prefer some framework in order to support their requirements.
In general though, having "things" (mostly resources like datasources, JMS
destinations, thread pools, but also security modules) provided by the
container vs embedded within the application is an ongoing discussion.
Indeed, there's a group of people who strongly believe all those "things"
should be provided by the container exclusively and applications should be
totally unaware of the actual instances. One of the reasons not rarely
stated is that developers aren't trained well enough to configure these
things correctly, and its the task of the operations teams to take care of
those.
Others however argue that there's not always a separate developers and
operations team to begin with. For instance, in home automation I may use
Java EE on a Raspberry Pi, and then there's only me. I don't need Java EE
to mandatorily protected me from uhh, me. For cloud deployments its a
similar thing.
I do think it's a good idea to support *both* cases though; the ability to
configure secure either from within the app or at the container's side and
as much as possible have the ability to transparently move between those.
Here's something JASPIC did quite right. The very same auth module can be
installed from within the app or at the container side.
JACC however did this wrong. A JACC provider unfortunately can *only* be
installed at the JVM level.
> REST security is another interesting topic for this JSR. Today we have a
huge demand for REST-based APIs where JAX-RS plays an important role when
using JEE. And that brings some important requirements such as path-based
authc and authz, CORS, security tokens and stateless authentication, etc.
A while back I did a proof of concept for stateless authentication using
tokens, specifically intended for JAX-RS. It looks as follows:
public class TokenAuthModule extends HttpServerAuthModule {
private final static Pattern tokenPattern =
compile("OmniLogin\\s+auth\\s*=\\s*(.*)");
@Override
public AuthStatus validateHttpRequest(HttpServletRequest request,
HttpServletResponse response, HttpMsgContext httpMsgContext) throws
AuthException {
String token = getToken(request);
if (!isEmpty(token)) {
// If a token is present, authenticate with it whether this is
strictly required or not.
TokenAuthenticator tokenAuthenticator =
getReferenceOrNull(TokenAuthenticator.class);
if (tokenAuthenticator != null) {
if (tokenAuthenticator.authenticate(token)) {
return
httpMsgContext.notifyContainerAboutLogin(tokenAuthenticator.getUserName(),
tokenAuthenticator.getApplicationRoles());
}
}
}
if (httpMsgContext.isProtected()) {
return httpMsgContext.responseNotFound();
}
return httpMsgContext.doNothing();
}
private String getToken(HttpServletRequest request) {
String authorizationHeader = request.getHeader("Authorization");
if (!isEmpty(authorizationHeader)) {
Matcher tokenMatcher =
tokenPattern.matcher(authorizationHeader);
if (tokenMatcher.matches()) {
return tokenMatcher.group(1);
}
}
return null;
}
}
This is basically JASPIC, but uses a convenience base class and some small
utility methods to (IMHO) make it much more useable.
This auth module is installed as follows:
@WebListener
public class SamRegistrationListener extends BaseServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
Jaspic.registerServerAuthModule(new TokenAuthModule(),
sce.getServletContext());
}
}
This is again using the JASPIC APIs, but the very verbose code JASPIC
requires out of the box has been abstracted into a small and easy to use
utility method.
See
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
for some more details.
Kind regards,
Arjan Tijms
>
> I think JEE should also allow to plug different
authentication/authorization protocols easier, such as OpenID Connect,
oAuth2, SAML, etc. I think JASPIC tries to provide that, but like was said
before there are some issues that make hard to use it.
>
> Looking forward to working with you all. I'm very excited about the
initial scope of this JSR !
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Alex Kosowski" <alex.kosowski_at_oracle.com>
> To: jsr375-experts_at_javaee-security-spec.java.net
> Sent: Thursday, March 5, 2015 1:26:08 AM
> Subject: [jsr375-experts] Welcome to the JSR 375 EE Security API Expert
Group!
>
> Hi Experts,
>
> Welcome to the EE Security API (JSR 375) expert group!
>
> Thanks again for offering to participate. The expert group includes
> experts from seven companies and includes individuals. The current
> members are:
>
> Adam Bien
> David Blevins (Tomitribe)
> Rudy De Busscher
> Ivar Grimstad
> Les Hazlewood (Stormpath, Inc.)
> Will Hopkins (Oracle)
> Werner Keil
> Matt Konda (Jemurai)
> Darran Lofthouse (RedHat)
> Jean-Louis Monteiro (Tomitribe)
> Pedro Igor Silva (RedHat)
> Arjan Tijms (ZEEF)
> [pending participant from IBM]
>
> I am Alex, the spec lead from Oracle.
>
> The current members of the expert group and their contact information
> are listed on the expert group home page at jcp.org,
> "https://jcp.org/en/eg/view?id=375". We still have one pending
> participant from IBM, and I expect they will monitor the user's mailing
> list while the JCP processes the nomination.
>
> I expect most discussions will be ongoing using this Expert Group
> mailing list, and (automatically) CCed to the user's mailing list. If
> practical, I would also like to have occasional Web Conferences. I will
> have an introductory web conference soon. Timezone wise, we are
> currently spread from California to Western Europe, so perhaps meeting
> at Noon (12 PM) US Eastern Standard Time may be a good compromise.
>
> We will generally decide on issues by consensus of the Expert Group.
> However, should polling be needed, each JCP member will get one vote. So
> JCP members on the Expert Group with multiple representatives would
> still only get one vote.
>
> =====
>
> Okay, now that we got that admin stuff out of the way...
>
> The Java EE Security API needs a lot of work from an application
> developer's perspective. JSR 375 is proposing to improve EE security API
> portability and simplicity, and to modernize it.
>
> Here are some proposed improvements to consider...
>
> Portability:
> - User Management
> - Password Aliasing
> - Role Mapping
>
> Simplicity:
> - Add conveniences to simplify authentication, e.g. JASPIC
>
> Modernization:
> - Authentication CDI Events
> - Authorization CDI Events
> - Authorization CDI Interceptors
> - EL Authorization Rules
>
>
> The original proposal is available here:
> "https://jcp.org/en/jsr/detail?id=375#orig".
>
>
> I would like to start our discussions with: standardizing an API for
> User Management. This would allow an application to
> add/update/remove/query users in a repository within the scope of an
> application. Since the focus here is simplicity, lets consider an API
> similar to PicketLink or Shiro. However, something like JSR 351 Java
> Identity API may be too complex for the typical application developer.
> What do you think? Let's discuss!
>
> =====
>
> Finally, so that I know that the expert group mailing list on java.net
> is working correctly, would you please reply to the mailing list?
> Briefly introduce yourself to the group and let us know in which
> particular areas of this JSR you yourself are most interested in
> contributing.
>
> I am looking forward to working with all of you!
>
> Thanks,
> Alex