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 :)
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
>>
>
>