Hi,
No objection, at JSR 363 we have a good experience with Google Groups.
There's also Spam but you rarely see it since it's either automatically
filtered or the Spec Lead (Group Moderator) has to confirm suspicious
messages.
With java.net mailing lists especially "attractive" topics (like
"JavaMoney;-)" we often see spam reaching everybody. JSR 354 has a more
open list, similar to that of JSR 363 (with 2 streams one for "dev" the
other for "users") so maybe this mailing list is less affected.
I saw it's by invitation only. Will we get those in the EG? And what is the
scope of the Google Group (aside from being more forum-like and a bit more
user-friendly when it comes to browsing threads) compared to this mailing
list?
Thanks,
Werner
On Thu, Mar 12, 2015 at 5:13 AM, Alex Kosowski <alex.kosowski_at_oracle.com>
wrote:
> Hi,
>
> It seems we are in general agreement that terms should be clarified.
>
> I guess we would add a "Terminology" or "Definition of Terms, Acronyms and
> Abbreviations" section to the spec.
>
> I suggest using a collaborative tool like Google docs to develop the
> table, within which we may add comments.
>
> I have already created a Google Group for the EG [1]. I will subscribe all
> of you tomorrow (it is late in New Jersey), unless there are strong
> objections to using Google Docs.
>
> Thanks,
> Alex
>
> [1] https://groups.google.com/forum/#!forum/jsr375-experts
>
>
> On 3/11/15 5:46 PM, Les Hazlewood wrote:
>
> 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
>> >>
>> >>
>> >
>>
>
>