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.
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.
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.
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.
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
> > >
> >
>