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 Collection localEvents(IgnitePredicate 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 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/
