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/02/12 15:54:34 UTC
JDBC thin client incorrect security context
Hi ,
We have built a security and audit plugin for security of our ignite
cluster. We are unable to get the right audit information i.e. we are unable
to get the right subject for users logged in through dbeaver ( jdbc thin
client. ). This is because the subjectid associated with the "CACHE_PUT"
event when an update is triggered by the jdbc thin client, contains the uuid
of the node that executed the update rather than the logged in jdbc thin
client user.
If this is a limitation with the current version of ignite, is there any
workaround to get this information ?
regards,
Veena.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDBC thin client incorrect security context
Posted by VeenaMithare <v....@cmcmarkets.com>.
Hi Andrei,
I checked again, The uuid associated with the cacheevent is associated to
the node that handles the request from the jdbc thin client. It doesnt show
the uuid of the logged in jdbc client(DBEAVER user).
Do I need to do something to associate the cacheevent with the logged in
jdbc client(DBEAVER user) in authorize ( or any other method) method of the
security plugin .
regards,
Veena.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDBC thin client incorrect security context
Posted by Abhay Gupta <ab...@avissol.com>.
I hen we tested we saw that older jdbc client would connect without security while latest version would give error and would require the correct username password .
Regards
Sent from my iPhone
> On 17-Feb-2020, at 4:07 AM, VeenaMithare <v....@cmcmarkets.com> wrote:
>
> As suggested by you , i have put up this question on the 'ignite developers'
> forum as well.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDBC thin client incorrect security context
Posted by VeenaMithare <v....@cmcmarkets.com>.
1. Another thing I noticed is that during a update through jdbc client, there
could be 2 kinds of threads acting on it. The 'client-connector' thread and
the 'sys-stripe'. If the client-connector thread completes the transaction
and calls the record on storagemanager, it is able to send a 'cache_put'
event with the uuid
of the person logged in to through the jdbc thin client . Whereas if the
'sys-stripe' thread completes the transaction, it sends the 'cache_put'
event with the node uuid.
Kindly guide.
2. Is there anyway I can get the session id of the associated jdbc session
in
the SecurityPlugin and the Audit plugin so that I can link the right UUID (
i.e. the UUID of the logged in jdbc thin client user ).
3. I am also noticing when I do insert from the dbeaver( jdbc thin client )
the transaction id associated with the TransactionStateChangedEvent is
different from that generated by the Cache_PUT event . Is there anyway i can
link the two.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDBC thin client incorrect security context
Posted by VeenaMithare <v....@cmcmarkets.com>.
As suggested by you , i have put up this question on the 'ignite developers'
forum as well.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDBC thin client incorrect security context
Posted by VeenaMithare <v....@cmcmarkets.com>.
HI Andrei,
That helps..For some reason, i got confused and thought I am getting the
UUID of the node on which it is running.
thanks,
regards,
Veena.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: JDBC thin client incorrect security context
Posted by Andrei Aleksandrov <ae...@gmail.com>.
Hi,
I see that you found the ticket related to the current issue:
https://issues.apache.org/jira/browse/IGNITE-12589
Looks like it can be a reason of your problem.
Generally, I don't know how you implemented your security plugin if you
take a look at similar plugin from third party vendor
<https://www.gridgain.com/docs/latest/administrators-guide/security/security-audit>
then you can see that subjectID should be related to user
connection/session, not to node where some task will be executed (yes
every node has it's subjectID and user but JDBC connection with another
user should have its own subjectID ).
How it implemented there in common details:
1)JDBC supports username and password fields:
https://apacheignite-sql.readme.io/docs/jdbc-driver#section-parameters
2)Every user session/connection mapped to some SecuritySubject (that
contains subjectID)
3)Every event that contains subjectID can be linked with some user
connection (SecuritySubject.login()) using the following code:
|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. */ } }|
In case if this approach doesn't work for your implementation because of
some issues then you can try to start the thread on Ignite developer
mail list.
BR,
Andrei
2/12/2020 6:54 PM, VeenaMithare пишет:
> Hi ,
>
> We have built a security and audit plugin for security of our ignite
> cluster. We are unable to get the right audit information i.e. we are unable
> to get the right subject for users logged in through dbeaver ( jdbc thin
> client. ). This is because the subjectid associated with the "CACHE_PUT"
> event when an update is triggered by the jdbc thin client, contains the uuid
> of the node that executed the update rather than the logged in jdbc thin
> client user.
>
> If this is a limitation with the current version of ignite, is there any
> workaround to get this information ?
>
> regards,
> Veena.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/