Maybe some sort of "Glossary". That is something a Wiki even the one on
java.net seems well suited;-)
On Tue, Mar 10, 2015 at 2:55 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Tue, Mar 10, 2015 at 2:19 PM, Alex Kosowski <alex.kosowski_at_oracle.com>
> wrote:
> > I think the next steps should be to decide what issues we should address
> > first, and how to accomplish that.
>
> I'd really hope we can get some agreements on terminology first, so
> that at least it's more clear what we're talking about.
>
> E.g. if you talk about a security provider and I talk about an auth
> module, and someone else talks about a login module, are we all
> talking about the same thing or not?
>
> Kind regards,
> Arjan Tijms
>
>
> 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>
> 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
>