Hey Everybody,
Pedro Igor, from Brazil. I've been involved in some security-wise opensource projects like PicketLink and Keycloak. This is my first EG and I'm looking forward to contribute and also learn from our discussions along the way.
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. Pretty much what we had on the last few years with ACEGI/Spring Security, Shiro, PicketLink, Apache Deltaspike, home-made, and so on. And honestly, in general they all provide a very common set of capabilities.
I totally agree about what was said here about CDI and how we can extend it for JEE security. If it is going to be fully based on CDI or not, I think we are going to discuss that in the future ...
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.
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