[
https://issues.apache.org/jira/browse/IGNITE-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068420#comment-17068420
]
Ivan Rakov edited comment on IGNITE-12759 at 3/27/20, 8:42 AM:
---------------------------------------------------------------
[~garus.d.g] In general, changes look good to me.
I'd propose to describe in the javadocs of IgniteSecurityProcessor and
GridSecurityProcessor the difference between their areas of responsibility.
The picture that I have right now in my head:
*GridSecurityProcessor is responsible for:*
- Node authentication
- Thin client authentication
- Providing configuration info whether global node authentication is enabled
- Keeping and propagating all authenticated security subjects
- Providing configuration info whether security mode is enabled at all
- Handling expired sessions
- Providing configuration info whether sandbox is enabled
- Keeping and propagating authenticated security contexts for thin clients
- Authorizing specific operations (cache put, task execute, so on) when
session security context is set
*IgniteSecurityProcessor is responsible for:*
- Keeping and propagating authenticated security contexts for cluster nodes
- Delegating calls for all aforementioned actions to GridSecurityProcessor
(IgniteSecurityProcessor serves here as a facade with is exposed to Ignite
internal code, while GridSecurityProcessor is hidden and managed from
IgniteSecurityProcessor)
- Managing sandbox and proving point of entry to the internal sandbox API
Also, javadocs should answer to the following questions:
- Difference between security subject and security context
- Authentication and authorization flow (authenticate call creates and ensures
further propagation of the security subject / context or subject ID;
#withContext(ctx / subjId) forces current thread to perform operations is
secure mode; #authorize called in security mode performs an actual permission
check)
- Whether GridSecurityProcessor is responsible for keeping authenticated
subjects of cluster nodes (or authenticatedSubjects should return only
instances for thin clients)
- Advice on how to implement user-specific security (the common pattern here is
to embed custom GridSecurityProcessor via Ignite plugin and keep default
IgniteSecurityProcessor)
I believe that while our security API is messy, presence of this information in
the javadocs will help a lot in untangling security logic by another Ignite
contributors and users.
was (Author: ivan.glukos):
[~garus.d.g] In general, changes look good to me.
I'd propose to describe in the javadocs of IgniteSecurityProcessor and
GridSecurityProcessor the difference between their areas of responsibilities.
The picture that I have right now in my head:
*GridSecurityProcessor is responsible for:*
- Node authentication
- Thin client authentication
- Providing configuration info whether global node authentication is enabled
- Keeping and propagating all authenticated security subjects
- Providing configuration info whether security mode is enabled at all
- Handling expired sessions
- Providing configuration info whether sandbox is enabled
- Keeping and propagating authenticated security contexts for thin clients
- Authorizing specific operations (cache put, task execute, so on) when
session security context is set
*IgniteSecurityProcessor is responsible for:*
- Keeping and propagating authenticated security contexts for cluster nodes
- Delegating calls for all aforementioned actions to GridSecurityProcessor
(IgniteSecurityProcessor serves here as a facade with is exposed to Ignite
internal code, while GridSecurityProcessor is hidden and managed from
IgniteSecurityProcessor)
- Managing sandbox and proving point of entry to the internal sandbox API
Also, javadocs should answer to the following questions:
- Difference between security subject and security context
- Authentication and authorization flow (authenticate call creates and ensures
further propagation of the security subject / context or subject ID;
#withContext(ctx / subjId) forces current thread to perform operations is
secure mode; #authorize called in security mode performs an actual permission
check)
- Whether GridSecurityProcessor is responsible for keeping authenticated
subjects of cluster nodes (or authenticatedSubjects should return only
instances for thin clients)
- Advice on how to implement user-specific security (the common pattern here is
to embed custom GridSecurityProcessor via Ignite plugin and keep default
IgniteSecurityProcessor)
I believe that while our security API is messy, presence of this information in
the javadocs will help a lot in untangling security logic by another Ignite
contributors and users.
> Getting a SecurityContext from GridSecurityProcessor
> ----------------------------------------------------
>
> Key: IGNITE-12759
> URL: https://issues.apache.org/jira/browse/IGNITE-12759
> Project: Ignite
> Issue Type: Improvement
> Components: security
> Reporter: Denis Garus
> Assignee: Denis Garus
> Priority: Major
> Labels: iep-41
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Extend the _GridSecurityProcessor_ interface by adding _securityContext(UUID
> subjId)_ method and use this method to get the actual security context.
> h4. Backward compatibility
> The logic of getting security context for Ignite:
> # Try to get a security context using _ClusterNode_ attributes (as it works
> now);
> # Get a security context through _GridSecurityProcessor_.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
