(Sending again as it failed this morning ...)
Hi all,
Jean-Louis Monteiro, also Java EE lover. Been involved in some open source
projects and EJB 3.2 JSR. I've been working over the last 10 years in
banking, insurance and secured environments like PCI (Paiement Card
Industry) or even stronger.
All over the years, I tried using the standard JSR 250 annotations and Java
EE Security, but there was always something missing, not accurate or not
extensible. It resulted most of the time in using open source software like
Spring Security, Apache Shiro or even CAS, Jasypt, Apache Fediz. This was
in best cases of course cause I've also seen many in-house user management
or security frameworks.
I have some pretty good skills in cryptography I learned over the years.
I'd like to first start modernizing the current API and yes, as David said,
CDI is definitely a great tool for callbacks or to give more freedom to
applications, to let them add some business rules or add dynamic
constraints. JASPIC (especially since version 1.1) definitely provided with
some answers on the authentication part. Let's try to do the same with
authorization and accounting part to get the AAA complete. And I would say
that even JASPIC could benefit from CDI Events.
I'd like also to see more discussions to get the security API more
integrated and usable with other specifications. For instance, how could we
get a bit of security in JPA? Having hashed passwords in DB is very common
and even add some common cryptographic functions in JPQL and why not
support 2-way ciphered data.
Same for JAX RS. The current specification defines a pretty great
integration with Java Servlet specification, but servlet security (simple
url pattern matching + http verb) is not enough and again results in
proprietary solutions.
WS Security could be another example.
I'm also thinking about opening the doors to internet standards like
OpenID, SAML, or OAuth, to name a few.
Finally, some very trivial things like supporting ciphered passwords in
configuration files is not covered.
This has not direct relationship with the current specification, but we
could think about extension points to let other specifications interface
with this Java EE Security API.
Looking forward to learn more about you guys and have fun and interesting
discussions.
Kind regards,
Jean-Louis
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, Mar 5, 2015 at 7:58 AM, David Blevins <dblevins_at_tomitribe.com>
wrote:
> Hi Alex and all!
>
> David Blevins, general Java EE enthusiast. Helped create OpenEJB,
> Geronimo, TomEE. Survived the J2EE 1.4 TCK and onward.
>
> I couldn't put a finger on one tweak or single action that would fix Java
> EE Security. All I can say is that we've seem to historically gotten it
> wrong time and time again standardizing the wrong things in great detail
> while simultaneously leaving other huge gaps completely undefined.
>
> A big example of that is never having had a standard way to add users,
> resulting in still being tied to your provider and shallow benefit to any
> abstractions. Add to that the extremely elaborate nature of things like
> JACC which drives up the implementation overhead and severely reduces
> performance. Top it off with the fact that once we create these
> abstractions for plugging in security providers, the diverse market of
> implementations we designed for never show up.
>
> After years of that, I'd have to say I'm keen on seeing what we can do to
> put more security in the user's hands. Let the app play a role in
> authentication and authorization. I think if developers are empowered be
> providers of the underlying authentication & authorization and can do it
> right in their webapp, they'll create and share far more implementations
> than all us vendors have in the last 15 years combined.
>
> I think CDI Events could be the breakthrough we've been waiting for in
> that regard.
>
> If you take JAAS, for example. Yank out the "plugging in" part (CDI
> Extensions cover that), then yank out initialization and shutdown
> (@PostConstruct, @PreDestroy cover that), you don't have much left but
> overly generic "callback" classes. CDI Events offers the ability for
> callbacks, but no need for a fixed and one-size-fits-all method signature.
>
> I think some things we tried to do early in Java EE failed because we
> didn't have the right tools. As of 2015 we don't have a single security
> API where the provider side uses annotations.
>
> Happy to see User Management on the list. If we can do that right,
> fantastic. It's certainly been near the top of my wish list for years.
>
> No concrete ideas yet, but I'm slightly curious what we could do with Java
> 8 and functional style. In the past we've affixed methods with meta-data
> that said what the security requirements were. Methods are now mobile.
>
> We could theoretically pass them into something that would execute them
> with specific constraints or requirements. Things like @RunAs could be
> done by passing method into a container-implemented "runner" rather than
> annotating the method with the current container-implemented @RunAs.
>
> Anyway, excited to see this opportunity. Hope we crack this nut.
>
> Very much look forward to working with you all!
>
>
> -David
>
> On Mar 4, 2015, at 8:26 PM, Alex Kosowski <alex.kosowski_at_oracle.com>
> wrote:
>
> > 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
> >
>
>