Hi,
Thanks for your responses. Looks like Darran did not check in, but I
will follow up. Thanks especially to those providing historical
perspective, to explain "how we got here".
It seems we are in general agreement about the goals of this JSR, and I
see some really cool ideas, and no surprises regarding issues we should
address.
I think the next steps should be to decide what issues we should address
first, and how to accomplish that. I see later in the mailing list,
discussions about EG Logistics. I will respond on the other threads.
Thanks,
Alex
On 3/8/15 4:38 PM, arjan tijms wrote:
> Hi,
>
> On Sat, Mar 7, 2015 at 1:03 AM, Pedro Igor Silva <psilva_at_redhat.com
> <mailto: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
> <mailto:alex.kosowski_at_oracle.com>>
> > To: jsr375-experts_at_javaee-security-spec.java.net
> <mailto: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 <http://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 <http://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