You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by VeenaMithare <v....@cmcmarkets.com> on 2020/07/22 13:17:37 UTC

2.8.1 : Ignite Security : Cache_Put event generated from a remote_client user action has subject uuid of Node that executes the request

Hi Team,

1. I noticed that this issue (
https://issues.apache.org/jira/browse/IGNITE-12781) is not resolved in
2.8.1.

Could you guide how can we get audit information if a cache record
modification is done on dbeaver and the cache_put event contains the node id
instead of the remote_client subject id ?

Please note this is a blocker issue for us to use Apache Ignite , since we
use dbeaver to update records sometimes. 
If this is not resolved, could we kindly ask this to be included in the next
release. 

2. Even if the cache_put event did contain the remote_client user id , how
are we supposed to fetch it from the auditstoragespi ?

The below link mentions 
http://apache-ignite-users.70518.x6.nabble.com/JDBC-thin-client-incorrect-security-context-td31354.html

public class EventStorageSpi extends IgniteSpiAdapter implements
EventStorageSpi {
    @LoggerResource
    private IgniteLogger log;

    @Override
    public <T extends Event> Collection<T> localEvents(IgnitePredicate<T> p)
{
        return null;
    }

    @Override
    public void record(Event evt) throws IgniteSpiException {
        if (evt.type() == EVT_MANAGEMENT_TASK_STARTED) {
            TaskEvent taskEvent = (TaskEvent) evt;

            SecuritySubject subj = taskEvent.subjectId() != null
                    ?
getSpiContext().authenticatedSubject(taskEvent.subjectId())
                    : null;

            log.info("Management task started: [" +
                    "name=" + taskEvent.taskName() + ", " +
                    "eventNode=" + taskEvent.node() + ", " +
                    "timestamp=" + taskEvent.timestamp() + ", " +
                    "info=" + taskEvent.message() + ", " +
                    "subjectId=" + taskEvent.subjectId() + ", " +
                    "secureSubject=" + subj +
                    "]");
        }
    }

    @Override
    public void spiStart(@Nullable String igniteInstanceName) throws
IgniteSpiException {
        /* No-op. */
    }

    @Override
    public void spiStop() throws IgniteSpiException {
        /* No-op. */
    }
}

IgniteSpiContext exposes authenticatedSubject which according to some
discussions gets the subject *only for node* . (
http://apache-ignite-developers.2346864.n4.nabble.com/Security-Subject-of-thin-client-on-remote-nodes-td46029.html#a46412
)

/*securityContext(uuid ) was added to the GridSecurityProcessor to get the
securitycontext of the thin client. However this is not exposed via the
IgniteSpiContext.* /


3. The workaround I did was as follows. Please let me know if you see any
concerns on this approach - 
a. Add the remoteclientsubject into the authorizationcontext of the
authenticationcontext in the authenticate method of the securityprocessor.

b. This authorizationcontext is now put in a threadlocal variable ( Check
the class AuthorizationContext )
private static ThreadLocal<AuthorizationContext> actx = new ThreadLocal<>();

c. The following has been done in the storagespi when a change is made in
the dbeaver, 
c1. capture the EVT_TX_STARTED in the storage spi. The thread that generates
this event contains the subject in its threadlocal authorizationcontext.
Store this in a cache that holds the mapping transaction id to security
subject.

c2. capture the cache_put event and link the transaction id in the cache_put
event to the transaction id in the EVT_TX_STARTED and get the subject by
this mapping. 

c3. The transactionid in cache_put and the transactionid in EVT_TX_STARTED
could be same, in which case it is a direct mapping

c4. The transactionid in cache_put and the transactionid in EVT_TX_STARTED
could be different, in which case it is a case of finding the nearxid of the
transactionid in the cacheput event. And then find the security subject of
the nearxid


regards,
Veena.





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : Ignite Security : Cache_Put event generated from a remote_client user action has subject uuid of Node that executes the request

Posted by Andrei Aleksandrov <ae...@gmail.com>.
Hi Veena,

Indeed it looks like that current problem wasn't solved. It looks like 
there are not enough people interested in the current fix. However, 
Ignite is the open-source community. You can make a patch for you or 
even provide it to the community.

Unfortunately, I don't think that somebody on the user mail list can 
help here. You can try to ask one more time on the developer mail list.

Also, you can try to investigate some third party security plugins in 
case if it's important to you.

BR,
Andrei

7/22/2020 4:17 PM, VeenaMithare пишет:
> Hi Team,
>
> 1. I noticed that this issue (
> https://issues.apache.org/jira/browse/IGNITE-12781) is not resolved in
> 2.8.1.
>
> Could you guide how can we get audit information if a cache record
> modification is done on dbeaver and the cache_put event contains the node id
> instead of the remote_client subject id ?
>
> Please note this is a blocker issue for us to use Apache Ignite , since we
> use dbeaver to update records sometimes.
> If this is not resolved, could we kindly ask this to be included in the next
> release.
>
> 2. Even if the cache_put event did contain the remote_client user id , how
> are we supposed to fetch it from the auditstoragespi ?
>
> The below link mentions
> http://apache-ignite-users.70518.x6.nabble.com/JDBC-thin-client-incorrect-security-context-td31354.html
>
> public class EventStorageSpi extends IgniteSpiAdapter implements
> EventStorageSpi {
>      @LoggerResource
>      private IgniteLogger log;
>
>      @Override
>      public <T extends Event> Collection<T> localEvents(IgnitePredicate<T> p)
> {
>          return null;
>      }
>
>      @Override
>      public void record(Event evt) throws IgniteSpiException {
>          if (evt.type() == EVT_MANAGEMENT_TASK_STARTED) {
>              TaskEvent taskEvent = (TaskEvent) evt;
>
>              SecuritySubject subj = taskEvent.subjectId() != null
>                      ?
> getSpiContext().authenticatedSubject(taskEvent.subjectId())
>                      : null;
>
>              log.info("Management task started: [" +
>                      "name=" + taskEvent.taskName() + ", " +
>                      "eventNode=" + taskEvent.node() + ", " +
>                      "timestamp=" + taskEvent.timestamp() + ", " +
>                      "info=" + taskEvent.message() + ", " +
>                      "subjectId=" + taskEvent.subjectId() + ", " +
>                      "secureSubject=" + subj +
>                      "]");
>          }
>      }
>
>      @Override
>      public void spiStart(@Nullable String igniteInstanceName) throws
> IgniteSpiException {
>          /* No-op. */
>      }
>
>      @Override
>      public void spiStop() throws IgniteSpiException {
>          /* No-op. */
>      }
> }
>
> IgniteSpiContext exposes authenticatedSubject which according to some
> discussions gets the subject *only for node* . (
> http://apache-ignite-developers.2346864.n4.nabble.com/Security-Subject-of-thin-client-on-remote-nodes-td46029.html#a46412
> )
>
> /*securityContext(uuid ) was added to the GridSecurityProcessor to get the
> securitycontext of the thin client. However this is not exposed via the
> IgniteSpiContext.* /
>
>
> 3. The workaround I did was as follows. Please let me know if you see any
> concerns on this approach -
> a. Add the remoteclientsubject into the authorizationcontext of the
> authenticationcontext in the authenticate method of the securityprocessor.
>
> b. This authorizationcontext is now put in a threadlocal variable ( Check
> the class AuthorizationContext )
> private static ThreadLocal<AuthorizationContext> actx = new ThreadLocal<>();
>
> c. The following has been done in the storagespi when a change is made in
> the dbeaver,
> c1. capture the EVT_TX_STARTED in the storage spi. The thread that generates
> this event contains the subject in its threadlocal authorizationcontext.
> Store this in a cache that holds the mapping transaction id to security
> subject.
>
> c2. capture the cache_put event and link the transaction id in the cache_put
> event to the transaction id in the EVT_TX_STARTED and get the subject by
> this mapping.
>
> c3. The transactionid in cache_put and the transactionid in EVT_TX_STARTED
> could be same, in which case it is a direct mapping
>
> c4. The transactionid in cache_put and the transactionid in EVT_TX_STARTED
> could be different, in which case it is a case of finding the nearxid of the
> transactionid in the cacheput event. And then find the security subject of
> the nearxid
>
>
> regards,
> Veena.
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/