----- Original Message -----
> From: "Alex Kosowski" <alex.kosowski_at_oracle.com>
> To: jsr375-experts_at_javaee-security-spec.java.net
> Sent: Monday, March 30, 2015 8:41:22 PM
> Subject: [jsr375-experts] Re: JAVAEE_SECURITY_SPEC-12
>
> Hi Pedro,
> > 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.
>
> The diagram is a "Dependencies among the Epics", and indicates that the
> group of tasks associated with Security Context does not depend on the
> group of tasks associated with the Authentication Mechanism epic. That
> is because the Authentication Mechanism epic is about building the
> simplified Authenticator, events, etc. To initiate authentication,
> obtaining the principal, etc, the Security Context needs access to the
> Servlet container to methods similar in the HttpServletRequest. This
> would be a source of the convenience methods Security Context would
> provide.
>
> I am trying to indicate a dependency graph among the epics in the
> diagram. For example, to define the Security Context, the Identity Store
> and Role/Permission Assignment need to be defined, since the Security
> Context uses that. But, the Security Context will also need access to
> container stuff not shown in the diagram, because the spec to define
> that access will probably be part of the Security Context spec.
>
> The stuff in the Authentication Mechanism epic is mostly the
> simplification layer. But if Security Context needs a facility defined
> in the Authentication Mechanism epic, I will add a line.
>
> I am just trying to get an idea of what order we should execute the epics.
>
> Thanks,
> Alex
I'm asking this because in PicketLink there is a difference between "authenticators" and "authentication mechanisms". The first is responsible to actually authenticate the user using an identity store. The latter are just mechanisms such as FORM, BASIC, DIGEST, X.509, TOKEN, etc. So it basically extracts credentials from the request and invoke what would be a "Security Context" to initiate the authentication.
I think better is wait until we start discussions around this epic :) But it is much more clear for me now what you are planning, thanks for that.
>
> On 3/30/15 9:40 AM, Pedro Igor Silva wrote:
> > Indeed. I can also see usage of SecurityContext in JSF if this bean is
> > exposed as a named bean. 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. 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>
> > To: jsr375-experts_at_javaee-security-spec.java.net
> > 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
>