Hi,
My name is Arjan Tijms (pronounce aprox. as "times") and I'm here
representing zeef.com. We're based in Amsterdam, The Netherlands.
(Central European Time Zone, UTC+01:00)
I'm a long time Java EE user and in the past I've contributed a number
of ideas to Java EE (specifically for JSF, JASPIC, JPA, JMS, and EJB),
some of which indeed got incorporated into the spec. I'm currently a
member of the JSF 2.3 EG as well.
Some of you may know me from the OmniFaces project, which is a JSF
utility library that I started with friend and zeef.com co-worker
Bauke Scholtz, and perhaps from my blog at
http://arjan-tijms.omnifaces.org. The blog is generally Java EE
themed, but security articles play an above average role.
I developed a set of tests for JASPIC, which I later donated to the EE
7 samples project
(
https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic)
and which were/are used by the GlassFish, WLS and JBoss/WildFly teams
to improve some aspects of their JASPIC implementations. I'd like to
take the opportunity here to thank all those teams again for their
outstanding openness and cooperation in getting the issues fixed ;)
All in all I'm really excited that the security JSR has finally
started, as it's something I've been lobbying for for quite a while.
My central philosophy for improving security in Java EE is that what's
currently there is a quite powerful foundation really, but riddled
with tiny basic problems. Some of these problems are about PR, some
are technical, some are just about terminology.
It's too broad a topic to fully discuss in this introductory thread of
course, but if you take authentication some of the problems I
identified are:
* JASPIC exists, but documentation too rarely covers it. It's not in
the EE tutorial and vendors often explain proprietary mechanisms first
or only
* JASPIC has an extremely small TCK lacking critical tests (such as;
does it *actually* authenticate), culminating in stub
implementations being able to get certified
* JASPIC is only available in the full EE profile
* JASPIC has a very small, bare bones, no nonsense API, that is
however just a bit too low-level for application user's taste
* CDI is not universally available in auth modules. JBoss/Undertow for
instance calls ServletRequestListeners -before- invoking auth modules,
some other servers invoke them -after-. ServletRequestListeners are
often the mechanism used to initialize CDI.
* Servlet defines 4 standard "auth mechanisms" that essentially
translate to "auth modules". The mechanism how to specify those and
their implementation is not aligned at all with standardized auth
modules. For stacking and general interoperability it would be great
if they did.
* Servlet makes a distinction between the "auth mechanism" (which is
something that interacts with the user, e.g. FORM) and a repository,
realm, login module, ... that actually authenticates (e.g.
DBLoginModule). This latter thing is often taken to be referring to
"standard" JAAS LoginModules, but the Servlet spec is neither
referring to JAAS, nor is there (surprisingly unknown to many) such a
thing as a standard JAAS LoginModule.
There's a similar list for authorization, which I will not bore you
with at this moment to not make this post longer that it already is.
It's my firm belief though that most of the issues I identified above
are relatively simple to solve. Indeed, as a number of people have
already suggested here, just making CDI available in auth modules will
open a world of options with regard to installing, throwing events,
life-cycle management and what have you.
Hope to be working with you guys on addressing these issues.
Kind regards,
Arjan Tijms
On Thu, Mar 5, 2015 at 1:43 PM, Matt Konda <mkonda_at_jemurai.com> wrote:
> Hi there,
>
> Matt from Chicago. I build apps in Java EE and also spend a lot of time
> breaking them, professionally. This is my first EG but I am on the board of
> OWASP and active in building bridges between security and developer
> communities.
>
> Like many of you, I've rolled my own fine grain domain and instance
> sensitive authorization solutions as part of large projects. In the context
> of doing security code reviews, I've also seen people do all kinds of things
> with Spring Security (from Acegi days), Apache Shiro, CAS, SAML, OAuth,
> OpenID, Jasypt, etc.
>
> I have some ideas of how things should be but I expect to be learning a lot
> along the way too. I'm excited to help.
>
> Nice to meet you all!
> Matt
>
> On Thu, Mar 5, 2015 at 5:54 AM, Rudy De Busscher <rdebusscher_at_gmail.com>
> wrote:
>>
>> Hi All,
>>
>> I'm Rudy and live in Belgium. As a consultant I have developed various
>> Java EE web/Rest applications where security was important, like handling
>> medical and personal data.
>>
>> I would like to help in the area where it becomes easier to define some
>> security related aspects like custom realms, login modules authorization
>> retrieval and so on.
>>
>> Don’t know if it is possible from this group (because it relates to other
>> frameworks as well like JAX-RS, JSF, Servlets, ..) to uniform a few things,
>> like Injecting the principal, using @ServletSecurity (or alike) on Rest
>> controllers, …
>>
>> Another key point for me is the usage of permissions and voters (classes
>> who decides if you are authorised for a certain action) in the authorization
>> part. This allows a much more fine-grained approach which is stable in case
>> of changes.
>>
>> If have combined a lot of the code around security, that I have build up
>> during the last years, in the Octopus framework. A declarative security
>> framework for JSF and JAX-RS around the permission concept with strong CDI
>> integration (built on top of Apache Shiro)
>>
>>
>> Looking forward to working with you all.
>>
>>
>> Best regards
>>
>> Rudy
>>
>>
>> On 5 March 2015 at 10:00, Werner Keil <werner.keil_at_gmail.com> wrote:
>>>
>>> Alex/all,
>>> Allow me to introduce myself as well to those who may not know me
>>> already.
>>> My name is Werner, I'm the only Individual JCP EC Member outside the US
>>> (after a year of being the only one globally) a reasonable up to date bio is
>>> therefore on the EC page: https://jcp.org/en/press/news/ec-feature#keil
>>>
>>> I am Apache and Eclipse Committer and EG member of a couple of active
>>> JSRs. Beside "value based" ones like 354 or 363 (where I'm also one of the
>>> Spec Leads) most others are related to Java ME as well as EE and CDI. I was
>>> in the Java EE EG since EE 6. I was the first person to ever publicly
>>> associate the term "ESSO" with Single Sign-On during a talk at the first
>>> (and AFAIK only) ApacheCon Asia in Sri Lanka 9 years ago. I worked in many
>>> SSO, SAML, OpenID or other security related projects for major companies and
>>> sites around the world. I'm on the EG of JSR 351 (Identity Management) which
>>> for certain aspects may offer synergies to this JSR.
>>> Together with now CDI Co-Spec Lead Antoine I proposed JSR 357 which after
>>> it was voted down here resulted in the creation of Agorava.org. Several
>>> aspects especially CDI events for authorization and authentication exist in
>>> Agorava, somewhat naturally given its co-founder and project lead Antoine is
>>> also heavily involved in CDI.
>>>
>>> Looking forward to working with you here,
>>>
>>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
>>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer | AdBoard
>>> Member, Java Track Chair, DWX '15
>>>
>>> Twitter @wernerkeil | @UnitAPI | @JSR377 | @JSR354 | @AgoravaProj |
>>> #EclipseUOMo | #DeviceMap | #DevOps
>>>
>>> Skype werner.keil | Google+ gplus.to/wernerkeil
>>>
>>> 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
>>>> >
>>>>
>>>
>>
>
>
>
> --
> Matt Konda
> Founder, Principal Jemurai, LLC
> Security for Software Developers
> http://www.jemurai.com
> mkonda_at_jemurai.com
> 312 545 3012
> Twitter: @mkonda
> LinkedIn: http://www.linkedin.com/in/matthewkonda