You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Anand Kumar Sankaran <an...@workday.com> on 2016/05/14 05:22:45 UTC
Custom GridSecurityProcessor plugin question
Hi
I following the instructions in http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/ and implemented a custom GridSecurityProcessor plugin. I got Ignite to recognize the custom provider and the provider is returning my custom GridSecurityProcessor like this:
@Nullable
@Override
@SuppressWarnings("unchecked")
public <T> T createComponent(PluginContext ctx, Class<T> cls) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent called for class " + cls.toString());
if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent returning TenantGroupSecurityProcessor");
return (T) new TenantGroupSecurityProcessor();
}
else {
System.out.println("TenantGroupSecurityPluginProvider:createComponent returning null");
return null;
}
}
All is fine when the first node starts up. When the second node starts up, TenantGroupSecurityProcessor.authenticateNode does not get called, but TenantGroupSecurityProcessor.validateNode gets called which is implemented like this:
@Nullable
@Override
public IgniteNodeValidationResult validateNode(ClusterNode node) {
System.out.println("TenantGroupSecurityProcessor:validateNode called");
return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access Denied");
}
Because of this, the second node is unable to join the cluster and it dies.
[22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: GridManagerAdapter [enabled=true, name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, reconCnt=10, maxAckTimeout=600000, forceSrvMode=false, clientReconnectDisabled=false]
at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:660)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1500)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:915)
at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1618)
at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1485)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
at org.apache.ignite.Ignition.start(Ignition.java:346)
at org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Access Denied
at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:1627)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:879)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:328)
at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1815)
at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:252)
... 13 more
Why isn’t the authenticateNode callback did not get called back? Did I miss anything?
Thanks for the help.
--
anand
Re: Custom GridSecurityProcessor plugin question
Posted by Anand Kumar Sankaran <an...@workday.com>.
Hi Denis
Thanks!
I was doing two things wrong.
GridSecurityProcessor.enabled() was returning false and my security processor implemented both DiscoverySpiNodeAuthenticator and GridSecurityProcessor
Once I fixed both, authenticateNode was getting called.
I think for my requirements (prevent a node from joining and not fine grained entitlement), validateNode is sufficient (and using ClusterNode.attribute to pass in parameters). A quick test along those lines seem to work.
I need to add a few comments to http://smartkey.co.uk/development/securing-an-apache-ignite-cluster explaining this.
--
anand
From: Denis Magda <dm...@gridgain.com>
Reply-To: "user@ignite.apache.org" <us...@ignite.apache.org>
Date: Monday, May 16, 2016 at 6:13 AM
To: "user@ignite.apache.org" <us...@ignite.apache.org>
Subject: Re: Custom GridSecurityProcessor plugin question
Hi Anand,
GridSecurityProcessor.authenticateNode(…) has to be called on your side. Please double check that GridSecurityProcessor.enabled() returns true. If it returns true then your GridSecurityProcessor will be registered in GridDiscoveryManager.start() method.
If this doesn’t happen please debug GridDiscoveryManager.start() method at the place when discovery SPI authenticator is set and places where DiscoverySpiNodeAuthenticator.authenticateNode is used and share the results with us.
—
Denis
On May 16, 2016, at 12:01 AM, Anand Kumar Sankaran <an...@workday.com>> wrote:
I went past this. Turns out if everything is ok, validateNode has to return null ☹.
That brings me to another question. validateNode callback only provides us with the ClusterNode. We were thinking the information needed to let a node join the cluster or not would be part of a custom SecurityCredentials object, which is available only at the authenticateNode level and not the validateNode.
If I want to prevent a node from joining the cluster, and if validateNode is the way to do it, should I add custom node attributes to ClusterNode and use that information?
--
thanks
anand
From: Anand Kumar Sankaran <an...@workday.com>>
Reply-To: "user@ignite.apache.org<ma...@ignite.apache.org>" <us...@ignite.apache.org>>
Date: Friday, May 13, 2016 at 10:22 PM
To: "user@ignite.apache.org<ma...@ignite.apache.org>" <us...@ignite.apache.org>>
Subject: Custom GridSecurityProcessor plugin question
Hi
I following the instructions in http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/<https://urldefense.proofpoint.com/v2/url?u=http-3A__smartkey.co.uk_development_securing-2Dan-2Dapache-2Dignite-2Dcluster_&d=CwMGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=qU_93SngJY3bPFd_cHFzZ8u3Owp9FHXx0iQE6zMz3jc&m=01Qixfyc18kKvq_I--s3PC9YgCsFRGlWT2LbskWFrqg&s=xLqLvdGDPFbP4OEHKMwhhYU4FuLd638U4oQ0YZ12IUI&e=> and implemented a custom GridSecurityProcessor plugin. I got Ignite to recognize the custom provider and the provider is returning my custom GridSecurityProcessor like this:
@Nullable
@Override
@SuppressWarnings("unchecked")
public <T> T createComponent(PluginContext ctx, Class<T> cls) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent called for class " + cls.toString());
if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent returning TenantGroupSecurityProcessor");
return (T) new TenantGroupSecurityProcessor();
}
else {
System.out.println("TenantGroupSecurityPluginProvider:createComponent returning null");
return null;
}
}
All is fine when the first node starts up. When the second node starts up, TenantGroupSecurityProcessor.authenticateNode does not get called, but TenantGroupSecurityProcessor.validateNode gets called which is implemented like this:
@Nullable
@Override
public IgniteNodeValidationResult validateNode(ClusterNode node) {
System.out.println("TenantGroupSecurityProcessor:validateNode called");
return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access Denied");
}
Because of this, the second node is unable to join the cluster and it dies.
[22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: GridManagerAdapter [enabled=true, name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, reconCnt=10, maxAckTimeout=600000, forceSrvMode=false, clientReconnectDisabled=false]
at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:660)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1500)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:915)
at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1618)
at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1485)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
at org.apache.ignite.Ignition.start(Ignition.java:346)
at org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Access Denied
at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:1627)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:879)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:328)
at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1815)
at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:252)
... 13 more
Why isn’t the authenticateNode callback did not get called back? Did I miss anything?
Thanks for the help.
--
anand
Re: Custom GridSecurityProcessor plugin question
Posted by Denis Magda <dm...@gridgain.com>.
Hi Anand,
GridSecurityProcessor.authenticateNode(…) has to be called on your side. Please double check that GridSecurityProcessor.enabled() returns true. If it returns true then your GridSecurityProcessor will be registered in GridDiscoveryManager.start() method.
If this doesn’t happen please debug GridDiscoveryManager.start() method at the place when discovery SPI authenticator is set and places where DiscoverySpiNodeAuthenticator.authenticateNode is used and share the results with us.
—
Denis
> On May 16, 2016, at 12:01 AM, Anand Kumar Sankaran <an...@workday.com> wrote:
>
> I went past this. Turns out if everything is ok, validateNode has to return null L.
>
> That brings me to another question. validateNode callback only provides us with the ClusterNode. We were thinking the information needed to let a node join the cluster or not would be part of a custom SecurityCredentials object, which is available only at the authenticateNode level and not the validateNode.
>
> If I want to prevent a node from joining the cluster, and if validateNode is the way to do it, should I add custom node attributes to ClusterNode and use that information?
>
> --
> thanks
>
> anand
>
> From: Anand Kumar Sankaran <an...@workday.com>
> Reply-To: "user@ignite.apache.org" <us...@ignite.apache.org>
> Date: Friday, May 13, 2016 at 10:22 PM
> To: "user@ignite.apache.org" <us...@ignite.apache.org>
> Subject: Custom GridSecurityProcessor plugin question
>
> Hi
>
> I following the instructions in http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__smartkey.co.uk_development_securing-2Dan-2Dapache-2Dignite-2Dcluster_&d=CwMGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=qU_93SngJY3bPFd_cHFzZ8u3Owp9FHXx0iQE6zMz3jc&m=01Qixfyc18kKvq_I--s3PC9YgCsFRGlWT2LbskWFrqg&s=xLqLvdGDPFbP4OEHKMwhhYU4FuLd638U4oQ0YZ12IUI&e=> and implemented a custom GridSecurityProcessor plugin. I got Ignite to recognize the custom provider and the provider is returning my custom GridSecurityProcessor like this:
>
> @Nullable
> @Override
> @SuppressWarnings("unchecked")
> public <T> T createComponent(PluginContext ctx, Class<T> cls) {
> System.out.println("TenantGroupSecurityPluginProvider:createComponent called for class " + cls.toString());
> if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
> System.out.println("TenantGroupSecurityPluginProvider:createComponent returning TenantGroupSecurityProcessor");
> return (T) new TenantGroupSecurityProcessor();
> }
> else {
> System.out.println("TenantGroupSecurityPluginProvider:createComponent returning null");
> return null;
> }
> }
>
> All is fine when the first node starts up. When the second node starts up, TenantGroupSecurityProcessor.authenticateNode does not get called, but TenantGroupSecurityProcessor.validateNode gets called which is implemented like this:
>
> @Nullable
> @Override
> public IgniteNodeValidationResult validateNode(ClusterNode node) {
> System.out.println("TenantGroupSecurityProcessor:validateNode called");
> return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access Denied");
> }
>
>
> Because of this, the second node is unable to join the cluster and it dies.
>
> [22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: GridManagerAdapter [enabled=true, name=o.a.i.i.managers.discovery.GridDiscoveryManager]
> class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, reconCnt=10, maxAckTimeout=600000, forceSrvMode=false, clientReconnectDisabled=false]
> at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
> at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:660)
> at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1500)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:915)
> at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1618)
> at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1485)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
> at org.apache.ignite.Ignition.start(Ignition.java:346)
> at org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Access Denied
> at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:1627)
> at org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:879)
> at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:328)
> at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1815)
> at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:252)
> ... 13 more
>
> Why isn’t the authenticateNode callback did not get called back? Did I miss anything?
>
> Thanks for the help.
>
> --
> anand
Re: Custom GridSecurityProcessor plugin question
Posted by Anand Kumar Sankaran <an...@workday.com>.
I went past this. Turns out if everything is ok, validateNode has to return null ☹.
That brings me to another question. validateNode callback only provides us with the ClusterNode. We were thinking the information needed to let a node join the cluster or not would be part of a custom SecurityCredentials object, which is available only at the authenticateNode level and not the validateNode.
If I want to prevent a node from joining the cluster, and if validateNode is the way to do it, should I add custom node attributes to ClusterNode and use that information?
--
thanks
anand
From: Anand Kumar Sankaran <an...@workday.com>
Reply-To: "user@ignite.apache.org" <us...@ignite.apache.org>
Date: Friday, May 13, 2016 at 10:22 PM
To: "user@ignite.apache.org" <us...@ignite.apache.org>
Subject: Custom GridSecurityProcessor plugin question
Hi
I following the instructions in http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/<https://urldefense.proofpoint.com/v2/url?u=http-3A__smartkey.co.uk_development_securing-2Dan-2Dapache-2Dignite-2Dcluster_&d=CwMGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=qU_93SngJY3bPFd_cHFzZ8u3Owp9FHXx0iQE6zMz3jc&m=01Qixfyc18kKvq_I--s3PC9YgCsFRGlWT2LbskWFrqg&s=xLqLvdGDPFbP4OEHKMwhhYU4FuLd638U4oQ0YZ12IUI&e=> and implemented a custom GridSecurityProcessor plugin. I got Ignite to recognize the custom provider and the provider is returning my custom GridSecurityProcessor like this:
@Nullable
@Override
@SuppressWarnings("unchecked")
public <T> T createComponent(PluginContext ctx, Class<T> cls) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent called for class " + cls.toString());
if (cls.isAssignableFrom(GridSecurityProcessor.class)) {
System.out.println("TenantGroupSecurityPluginProvider:createComponent returning TenantGroupSecurityProcessor");
return (T) new TenantGroupSecurityProcessor();
}
else {
System.out.println("TenantGroupSecurityPluginProvider:createComponent returning null");
return null;
}
}
All is fine when the first node starts up. When the second node starts up, TenantGroupSecurityProcessor.authenticateNode does not get called, but TenantGroupSecurityProcessor.validateNode gets called which is implemented like this:
@Nullable
@Override
public IgniteNodeValidationResult validateNode(ClusterNode node) {
System.out.println("TenantGroupSecurityProcessor:validateNode called");
return new IgniteNodeValidationResult(node.id(), "Access Denied", "Access Denied");
}
Because of this, the second node is unable to join the cluster and it dies.
[22:21:18,821][SEVERE][main][IgniteKernal] Failed to start manager: GridManagerAdapter [enabled=true, name=o.a.i.i.managers.discovery.GridDiscoveryManager]
class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, reconCnt=10, maxAckTimeout=600000, forceSrvMode=false, clientReconnectDisabled=false]
at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:660)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1500)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:915)
at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1618)
at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1485)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
at org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
at org.apache.ignite.Ignition.start(Ignition.java:346)
at org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Access Denied
at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:1627)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:879)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:328)
at org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1815)
at org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:252)
... 13 more
Why isn’t the authenticateNode callback did not get called back? Did I miss anything?
Thanks for the help.
--
anand