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