Re: JDBC thin client incorrect security context

[VeenaMithare]

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

[Abhay Gupta]

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

[VeenaMithare]

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

[VeenaMithare]

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

[VeenaMithare]

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

[Andrei Aleksandrov]

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 
 
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  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. */ } }|


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/

JDBC thin client incorrect security context

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