----- Original Message -----
> From: "arjan tijms" <arjan.tijms_at_gmail.com>
> To: jsr375-experts_at_javaee-security-spec.java.net
> Cc: "alex kosowski" <alex.kosowski_at_oracle.com>
> Sent: Monday, March 30, 2015 3:24:21 PM
> Subject: [jsr375-experts] Re: JAVAEE_SECURITY_SPEC-12
>
> Hi,
>
> On Monday, March 30, 2015, Pedro Igor Silva <psilva_at_redhat.com> wrote:
>
> > Indeed. I can also see usage of SecurityContext in JSF if this bean is
> > exposed as a named bean.
>
>
> That's indeed the idea ;) The prospect of having this context is an
> important aspect of why we in the JSF EG agreed not to pursue this topic in
> JSF itself.
>
>
>
> > The key point here is that it doesn't only provide methods for retrieving
> > information about an user, but also perform security operations such as
> > login, logout and runAs.
>
>
> Well, it's not necessarily intended to directly establish an authenticated
> identity (i.e. "Login") when using these methods. Instead, they should
> probably best just *trigger* authentication, just like
> HttpServletRequest#login and HttpServletRequest#authenticate do.
>
> 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.
And that is one of the reasons that makes me think how critical is the SecurityContext for this spec.
>
> Of course, you can decide in your own application that the authentication
> repository is one that just takes the values coming from the login(...) at
> face value and without validating anything applies them directly.
>
> Whether we provide such an authentication repository as a standard one and
> how far we're willing to take this is an open discussion.
Agree. I really think we need some way to easily plug "authenticators" (if this is what you mean by authentication repository). Is that what you are thinking to address with JASPIC ?
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
> >
>