Lol, that is definitely one we deal with ad nauseum at Stormpath and on the
Shiro mailing lists. Also that of a 'user' (nebulous at times as well).
I'll chime in via discussion threads on this stuff so as to not derail this
one.
Les
On Wed, Mar 11, 2015 at 2:35 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Wed, Mar 11, 2015 at 8:18 PM, Les Hazlewood <les_at_stormpath.com> wrote:
> > This is a great (and I believe necessary) idea. I still constantly have
> to
> > explain what a Principal is on a regular basis, and I'd bet that my
> > definition differs from others :)
>
> If you think Principal is bad, try explaining Group vs Role ;) Very
> few people I found intuitively guess what the difference is. Everyone
> dreams up their own "intuitive" meaning of Group, and it's never the
> meaning Java EE gives it.
>
> There are two additional JIRA issues that cover terminology here:
>
> User: https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-2
> Roles: https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-3
>
> Kind regards,
> Arjan Tijms
>
>
> >
> >
> > Les
> >
> > On Tue, Mar 10, 2015 at 7:05 AM, Werner Keil <werner.keil_at_gmail.com>
> wrote:
> >>
> >> 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
> >>
> >>
> >
>