ementation made by Denis suits
> >> better
> >> > > to
> >> > > > > the very implicit contract that it's better to change API
> >> contracts
> >> > of
> >> > > an
> >> > > > > internal Igni
> actually mustn't be internal).
>> > > > >
>> > > > > > My approach doesn't require any IEPs, just minor change in code
>> and
>> > > to
>> > > > > >
>> > > > > >
>> > > > >
uld
> perform
> > > > > initial authentication based on credentials (this may include
> queries
> > > to
> > > > > external authentication subsystem, e.g. LDAP). User may want to
> don't
> > > > > authenticate thin client on every
> > of
> > > > requests to auth subsystem unless user implicitly implements
> > propagation
> > > of
> > > > thin clients' contexts between nodes and make #authenticate
> > cluster-wide
> > > > idempotent: first call should perform actu
; idempotent: first call should perform actual authentication, next calls
> > > should retrieve context of already authenticated client). Presence of
> the
> > > separate #securityContext(UUID) highlights that user indeed should care
> > > about propagation of thin clients' contexts
t;
> > --
> > Ivan
> >
> > On Fri, Mar 20, 2020 at 12:22 PM Veena Mithare >
> > wrote:
> >
> > > Hi Alexei, Denis,
> > >
> > > One of the main usecases of thin client authentication is to be able to
> > > audit the changes d
; We really need to resolve this concern as well :
> > https://issues.apache.org/jira/browse/IGNITE-12781
> >
> > ( Incorrect security subject id is associated with a cache_put event
> > when the originator of the event is a thin cl
enable that :
> We really need to resolve this concern as well :
> https://issues.apache.org/jira/browse/IGNITE-12781
>
> ( Incorrect security subject id is associated with a cache_put event
> when the originator of the event is a thin client. )
>
> Regards,
> Veena
>
>
>
associated with a cache_put event when the
originator of the event is a thin client. )
Regards,
Veena
-Original Message-
From: Alexei Scherbakov
Sent: 18 March 2020 08:11
To: dev
Subject: Re: Security Subject of thin client on remote nodes
Denis Garus,
Both variants are capable of
Denis Garus,
Both variants are capable of solving the thin client security context
problem.
My approach doesn't require any IEPs, just minor change in code and to
org.apache.ignite.internal.processors.security.IgniteSecurity#authenticate(AuthenticationContext)
contract.
We can add appropriate doc
Hello, Alexei!
I agree with you if we may not care about compatibility at all,
then we can solve the problem much more straightforward way.
In your case, the method GridSecurityProcessor#authenticate will have an
implicit contract:
[ if actx.subject() != null then
returns SecurityContext
e
Denis Garus,
I've looked at the IEP proposed by you and currently I'm thinking it's not
immediately required.
The problem of missing SecurityContexts of thin clients can be solved much
easily.
Below is the stub of a fix, it requires correct implementation of
method
org.apache.ignite.internal.pr
HI ,
Created this jira :
https://issues.apache.org/jira/browse/IGNITE-12781
regards,
Veena.
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> I dont think that is true.
/**
* *Gets authenticated node subject.*
*
* @param subjId Subject ID.
* @return Security subject.
* @throws IgniteCheckedException If error occurred.
*/
public SecuritySubject authenticatedSubject(UUID subjId) throws
IgniteCheckedException;
> Nothing stops an
>>2. Method GridSecurityProcessor#authenticatedSubject returns
authenticated *node
subject* (from JavaDoc).
I dont think that is true. Nothing stops an implementer to return a Remote
Client Security Subject.
The primary issue is how to link the event which contains the remote node
uuid ( but wa
The biggest blocker is the one I mention here :
http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-thin-client-incorrect-security-context-td45929.html
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
1.Return type. SecurityContext is implemented by security plugin
developers,
and we cannot make SecurityContext from SecuritySubject.
But GridSecurityProcessor#authorize method requires SecurityContext as
parameter.
2. Method GridSecurityProcessor#authenticatedSubject returns
authenticated *node
s
Hi Denis,
Thank you for working on the security issues w.r.to thin client logins . We
plan to use the thin clients extensively in our project , it will really
help if the blockers around it are resolved,
regards,
Veena.
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
HI Denis,
Ref :
https://cwiki.apache.org/confluence/display/IGNITE/IEP-41%3A+Security+Context+of+thin+client+on+remote+nodes
How is this method
public interface GridSecurityProcessor extends GridProcessor {
// Other methods.
/**
* Gets security context.
*
* @param s
Hello!
Please avoid targeting feature tickets on 2.8.1 by default.
As far as my understanding goes, plan for 2.8.1 is to be a bugfix release
with specific changes cherry picked, so new features are unlikely to be
included, and should be negotiated with person responsible for this release
before
Hi guys!
I created the iep ticket [1] and started work.
1. https://issues.apache.org/jira/browse/IGNITE-12759
чт, 5 мар. 2020 г. в 12:00, Denis Garus :
> Hi, guys!
>
>
> I've prepared the IEP-41: Security Context of a thin client on remote
> nodes [1]; take a look, please.
>
> If there aren't an
Hi, guys!
I've prepared the IEP-41: Security Context of a thin client on remote nodes
[1]; take a look, please.
If there aren't any questions, I could create an issue and start work.
Ivan, could you be an IEP sponsor?
Thx!
1.
https://cwiki.apache.org/confluence/display/IGNITE/IEP-4
Hi, Alexei.
The ticket [1] describes the general problem for all thin client
authorizations. Its particular case is described in the mentioned in [1]
ticket [2] on the example of a JDBC client with the reproducer attached.
[1] https://issues.apache.org/jira/browse/IGNITE-12589
[2] https://is
Denis Garus,
It is forbidden to remove any public IGNITE attribute without proper
deprecation steps.
I have read the thread and still do not clearly see the problem. The subject id
is not required to be a node id.
The referenced in the thread ticket [1] do not provide any reproducers.
Can you p
Hi, guys!
The change suggested by Denis looks robust to me: it covers security
subject handling by all kinds of clients/nodes at once. As for
ATTR_SECURITY_SUBJECT_V2 attribute, it is really better to move it to
plugin implementations to support backward compatibility with peer nodes of
older vers
> I just transmitted security subjects for rest requests.
SecurityContext has an unlimited size so we can get significant overhead.
And we do not solve problems with other thin clients.
>If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility between old
versions and new.
I suggest remov
Yes, I said about it at 07.19.
http://apache-ignite-developers.2346864.n4.nabble.com/Improvements-for-new-security-approach-td42698.html#a42708
And in my solution, I just transmitted security subjects for rest requests.
If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility between old
ve
Hi, Igniters!
At present, a security subject id is assumed to be node id.
But when we are dealing with thin client, JDBC or REST subject id is random
UUID. In this case, we cannot get the subject information on a remote node,
and we get problems like these [1], [2].
To fix the problem, we shoul
28 matches
Mail list logo
