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