----- Original Message -----
> From: "arjan tijms" <arjan.tijms_at_gmail.com>
> To: jsr375-experts_at_javaee-security-spec.java.net, "users" <users_at_jaspic-spec.java.net>
> Cc: "alex kosowski" <alex.kosowski_at_oracle.com>
> Sent: Monday, March 30, 2015 7:25:07 PM
> Subject: [jsr375-experts] Re: JAVAEE_SECURITY_SPEC-12
>
> Hi Pedro,
>
> On Mon, Mar 30, 2015 at 10:54 PM, Pedro Igor Silva <psilva_at_redhat.com>
> wrote:
>
> >
> > > Following a call to these, the authentication repository resp.
> > > authentication mechanism is called.
> >
> > Yeah, I got that. These methods would just start the authentication chain
> > (which we still going to discuss about it :) ). But in the end the result
> > is the same, right ? You end up authenticating the user.
> >
>
> Yes, that's true.
>
>
>
> > And that is one of the reasons that makes me think how critical is the
> > SecurityContext for this spec.
> >
>
> I think it's important indeed, but just to avoid confusion; the intend of
> that issue was not so much to specify new functionality.
>
> Instead, it's main intend is to unite the different (but largely
> overlapping) methods that currently reside within spec specific artifacts.
> E.g. starting part of the authentication chain can already be done today
> with HttpServletRequest#login as mentioned above, but this is a Servlet
> specific type.
>
> The main use case is the one mentioned in the beginning of the issue:
> "getUserPrincipal". Effectively the exact same method exists in multiple
> places in Java EE. Almost every spec has its own version of this. I'd like
> to standardize this within Java EE so to speak.
>
>
>
> > Agree. I really think we need some way to easily plug "authenticators" (if
> > this is what you mean by authentication repository).
>
>
> This exactly demonstrates the great need to standardize on the terminology
> first ;) At least to establish some working term. Now we're basically
> putting terms between quotes all the time and asking the other party what
> is meant with some term or maybe worse don't fully get the meaning of a
> proposal.
Yeah, now it is clear :)
>
> With Authentication repository I mean the thing where the credentials are
> given as input, and the principals (username/roles/groups) come out. An
> authentication repository can be backed by e.g. a simple xml file
> (users.xml), a database or LDAP.
I think "Identity Store" is being used in the scope documents. So they are the same thing ... ok ...
>
> This is different from an authentication mechanism, which is the thing that
> actually interacts with a user in order to obtain the credentials. A
> mechanism can return an HTML response, redirect the user multiple times,
> extract data from HTTP headers, inspect query parameters etc. This can be
> the well known FORM or BASIC authentication mechanisms, or LDAP, or
> 2-factor, etc.
>
>
>
> > Is that what you are thinking to address with JASPIC ?
> >
>
> Partially. JASPIC is of course already there, but the ease to plug in a
> mechanism (implemented by an authentication module, aka SAM in JASPIC
> terminology) now only exists in the vendor specific tooling at the
> container side. The Java/application side does have API available to
> register a SAM, but for an application developer who just wants to register
> a SAM this is overly verbose and low-level. Either as part of this EG or
> over at JASPIC (or perhaps together) I'd like to come to an easier way to
> register a mechanism. Technically this shouldn't be that difficult. I've
> already shown a one-liner in my article about the stateless header based
> SAM that does this, and we could easily back that by something annotation
> based.
That would be awesome.
>
> The authentication store should just as well be plugable and easily
> registrable. In addition, a couple of default implementations should be
> made available (as proposed by Reza Rahman).
>
> Authentication stores are used at multiple places. First and foremost it's
> something the authentication mechanism can optionally delegate to. This is
> what you most often see in practice. Users configure say FORM (a mechanism)
> in their web.xml, then LDAP (a store) at the container side. The FORM
> mechanism then obtains the user's credentials in the way specified by that
> mechanism, and subsequently obtains the LDAP store that was configured,
> passes the credentials to it, and the LDAP store then returns a Subject
> containing a username and zero or more roles.
>
> Authentication stores are also the thing to use when the application has
> already collected the credentials and doesn't want to initiate further user
> interaction. HttpServletRequest#login is used for this. Remote or
> programmatic logins from EJB (or other places that are non-web) that don't
> want or can't interact with the user also need this (additional JASPIC
> profiles could have been specified for say remote EJB, but this never
> happened).
>
> HttpServletRequest#login is problematic though. It exclusively assumes
> username/password credentials, and since there's isn't really a standard
> way to declare just the authentication store, JASPIC can't do anything else
> but throw an exception when a custom authentication mechanism (SAM) is
> configured and the application calls HttpServletRequest#login.
Yeah, it does no cover use cases other than username/password. I'll wait until we start discussing this epic to give more thoughts on that :)
I think there are some good solutions out there from Shiro and PicketLink that can be useful on how to deal with authentication and multiple credential types.
Thanks !
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
> >
> > PS.: Or maybe is best to hold this discussion when the corresponding Epic
> > begins :)
> >
> > >
> > > Kind regards,
> > > Arjan Tijms
> > >
> > >
> > >
> > > > And most important, everything integrated with the underlying
> > container.
> > > > So you don't need to deal with JAAS or container-specific
> > configuration in
> > > > order to authenticate users and have them propagated to the container.
> > > >
> > > > From an user perspective, the SecurityContext would be the entry point
> > for
> > > > any security related operation. However, still should be possible to
> > use
> > > > the "Identity Store" directly for more specific use cases.
> > > >
> > > > Also, I've noticed that in the scope document [1] the "SecurityContext"
> > > > doesn't have a relation with "Authentication Mechanism". I was
> > wondering if
> > > > the latter can not benefit from it in order to perform authentication
> > and
> > > > obtain the authenticated principal and any other information associate
> > with
> > > > it. Instead of necessarily being forced to deal with the "Identity
> > Store"
> > > > directly.
> > > >
> > > > Regards.
> > > > Pedro Igor
> > > >
> > > > [1]
> > > >
> > https://docs.google.com/document/d/12j4-L94crAlHHePaO97HE6VaLp4TtiblU6JxAYhEbbU/edit
> > > >
> > > > ----- Original Message -----
> > > > From: "Alex Kosowski" <alex.kosowski_at_oracle.com <javascript:;>>
> > > > To: jsr375-experts_at_javaee-security-spec.java.net <javascript:;>
> > > > Sent: Sunday, March 29, 2015 10:01:27 PM
> > > > Subject: [jsr375-experts] Re: JAVAEE_SECURITY_SPEC-12
> > > >
> > > > Hi Pedro,
> > > >
> > > > The Security Context could also be a managed bean used in EL
> > > > authorization rules mentioned in
> > > > https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7.
> > > >
> > > > Regards,
> > > > Alex
> > > >
> > > > On 3/29/15 7:34 PM, Pedro Igor Silva wrote:
> > > > > Hey All,
> > > > >
> > > > > I was driving through JIRA and noticed JAVAEE_SECURITY_SPEC-12.
> > I
> > > > was wondering if we should not prioritize this one over others.
> > Probably
> > > > after we finish our Terminology epic.
> > > > >
> > > > > IMO, this issue gathers an important point in respect to:
> > > > >
> > > > > - Centralized interface for security-related information
> > > > > - Removes redundancy and provides a more concise way to
> > provide
> > > > access to security related information
> > > > > - Helps other specs to address security in a more similar
> > > > fashion
> > > > >
> > > > > And also looks like a core concept if we are going to take it
> > > > forward.
> > > > >
> > > > > I think this issue brings one of the main reasons that make
> > people
> > > > usually decide to use frameworks such as Shiro, Spring Security or
> > > > PicketLink. I think all of them provide a similar concept.
> > > > >
> > > > > Regards.
> > > > > Pedro Igor
> > > >
> > >
> >
>