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 > <anand.sanka...@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 <anand.sanka...@workday.com> > Reply-To: "user@ignite.apache.org" <user@ignite.apache.org> > Date: Friday, May 13, 2016 at 10:22 PM > To: "user@ignite.apache.org" <user@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
