Hi Werner,
I was only planning to use the JSR 375 Experts Google Group as a
convenient way to assign edit permissions to Google docs for the EG. I
think we should continuing using the java.net mailing lists.
I will send out invites to the EG to join the Google Group.
Thanks,
Alex
On 3/12/15 5:46 AM, Werner Keil wrote:
> 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 <http://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 <mailto: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
> <https://groups.google.com/forum/#%21forum/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 <mailto:arjan.tijms_at_gmail.com>> wrote:
>>
>> Hi,
>>
>> On Wed, Mar 11, 2015 at 8:18 PM, Les Hazlewood
>> <les_at_stormpath.com <mailto: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 <mailto:werner.keil_at_gmail.com>> wrote:
>> >>
>> >> Maybe some sort of "Glossary". That is something a Wiki
>> even the one on
>> >> java.net <http://java.net> seems well suited;-)
>> >>
>> >> On Tue, Mar 10, 2015 at 2:55 PM, arjan tijms
>> <arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On Tue, Mar 10, 2015 at 2:19 PM, Alex Kosowski
>> <alex.kosowski_at_oracle.com <mailto: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 <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
>> >>
>> >>
>> >
>>
>>
>