Archived
This forum has been archived. Please start a new discussion on GitHub.
Using IceGrid like an improved DNS
Hello, I want to use IceGrid for the location of the Ice servers instead of a dns because of the oppurtunity to specify the port and the protocol in the endpoint
and the load balancing.
But during the activation the server registers itself to the locator with an AdapterId, how can I secure this over internet an avoid that another server registers with the same AdapterId an overwrites my server?
Thanks.
and the load balancing.
But during the activation the server registers itself to the locator with an AdapterId, how can I secure this over internet an avoid that another server registers with the same AdapterId an overwrites my server?
Thanks.
0
Comments
-
The simplest way is to deny access to the IceGrid administrative port via a firewall. However, depending on your application deployment and intended use this may not be possible. In this case you should can use SSL. You can read all about this and more in my article "IceGrid Security" in issue 17 of our newsletter connections. http://www.zeroc.com/newsletter/issue17.pdf0
-
I've read it, but I still don't find what I need...
It seems I should use the property:
IceSSL.TrustOnly.Server.IceGrid.Registry.Server
but I need a rule on the registry that states this:
"If a server with id AS137_1 is activating one of its adapters on the registry, it has to have CN=AS137 in the distinguished name"
The servers are not activated on-demand, but manually.
Do I need to insert property tags in the server tag of the xml description of the application?0 -
Otherwise I need a method to avoid server activation and to statically define the endpoints of the adapter inside the server during deployment.
I tryed with
<adapter name="Facade" endpoints="ssl -h xxxx -p 10001" replica-group="AS137Facade"/>
but the problem was still the same.0 -
Its not clear to me what you really want to do. Are you looking at preventing this as a security mechanism, or as a defense as programming errors?
If you are mostly concerned about security then you would likely want to give all of your servers the same identity and then only allow that identity to connect to the relevant port (see my article for details).
If you are concerned about programming errors and want to prevent a buggy server from registering an incorrect adapter id then at present you cannot do this with IceGrid as it stands today. I'd suggest more testing
0 -
I'm looking at preventing this as a security mechanism, because every server is owned by one autonomous system and has a different certificate, I don't want that one server can register as another server, but only for the server deployed with the id equal to its common name.
Otherwise I don't want the server activation at all and I want to set the server endpoints during the deployment (if possible).0 -
Ok, you cannot do that. This is rather unusual deployment, and not directly supported in that there is no way to say that the adapter id must be equivalent to the server common name.
It is possible to disable on-demand server activation & set the endpoints directly. However, how do you see this solving your problem?0 -
Without server activation I can set the endpoint during the deployment and if it cannot be overwritten by a server activation, it's under control.
How can I disable the need of server activation?
I've tried in this way, I've set in icegrid.config
IceGrid.Registry.Server.Endpoints=ssl -p 12001
Ice.Plugin.IceSSL=IceSSL:createIceSSL
IceSSL.VerifyPeer=1
IceSSL.DefaultDir=certs
IceSSL.CertAuthFile=cacert.pem
IceSSL.CertFile=Registry_cert.pem
IceSSL.KeyFile=Registry_key.pem
IceSSL.TrustOnly.Server.IceGrid.Registry.Server=CN=Registry
and I've deployed this application
<icegrid>
<application name="BGP2P">
<server-template id="AS137">
<parameter name="index"/>
<server id="AS137_${index}" exe="python" activation="manual">
<adapter name="Facade" endpoints="ssl -h tocai.dia.uniroma3.it -p 10001" replica-group="AS137Facade"/>
</server>
</server-template>
<replica-group id="AS137Facade">
<load-balancing type="round-robin"/>
<object identity="sFactory" type="::BGP2P::SessionM::BGP2PSessionFactory"/>
</replica-group>
<node name="localhost">
<server-instance template="AS137" index="1"/>
</node>
</application>
</icegrid>
I've commented:
#Facade.AdapterId=AS137_1.Facade
so the server doesn't try to activate the adapter to the registry
but when I try to locate sFactory@AS137Facade I get NoEndpointException
In fact if I see the status of the adapter AS137_1.Facade, it's Inactive0 -
Without server activation I can set the endpoint during the deployment and if it cannot be overwritten by a server activation, it's under control.
I fail to see how either static endpoints or manual server activation really help you. Static endpoints are not a very good idea as they are hard to administer. How does disabling on-demand server activation help you? Are you assuming that all servers startup on system startup and never crash? If this is the case its pretty risky and if the environment really is hostile is definitely not a good idea.How can I disable the need of server activation?
I've tried in this way, I've set in icegrid.config
...
I've commented:
#Facade.AdapterId=AS137_1.Facade
so the server doesn't try to activate the adapter to the registry
but when I try to locate sFactory@AS137Facade I get NoEndpointException
What are id are you trying to locate? You wrote: sFactory@AS137Facade. Do you, however, really mean [email]sFactory@AS137_1.Faca[/email]de?In fact if I see the status of the adapter AS137_1.Facade, it's Inactive
If the server is actually active and IceGrid shows otherwise this generally means you used the wrong adapter name when you created the OA.
It looks to me like you have a rather complex deployment with replica-groups, templates, variables and other things. If I were you I'd take the IceGrid simple demo and modify the code and deployment descriptor to do what you want as this eliminates many variables. However, before doing any of this you should address what I said above and ensure that what you are doing is going to solve your problem.0 -
I fail to see how either static endpoints or manual server activation really help you. Static endpoints are not a very good idea as they are hard to administer. How does disabling on-demand server activation help you? Are you assuming that all servers startup on system startup and never crash? If this is the case its pretty risky and if the environment really is hostile is definitely not a good idea.
The server startup has not to be controlled by me, because they are on computers of other people and can be in different geographical places and if they crash they are responsible to respawn them. I want to use IceGrid only to locate them.What are id are you trying to locate? You wrote: sFactory@AS137Facade. Do you, however, really mean [email]sFactory@AS137_1.Faca[/email]de?
It's not an error, I meant the AS137Facade, the replica group of the Facade adapter.If the server is actually active and IceGrid shows otherwise this generally means you used the wrong adapter name when you created the OA.
No, If I uncomment the line
Facade.AdapterId=AS137_1.Facade
on the server
all works well, but I don't want server activation (if possible, how to do that?)
That's because I called this thread "Using IceGrid like an improved DNS", when you start a server you don't have to communicate to the DNS Server that you are started and if you ask it to resolve a name, it returns the ip even if the server is not active.0 -
Hi,
It's not possible to set the endpoints at deployment time. The endpoints you specify in the deployment descriptor are just used to generate the object adapter endpoints property in the server configuration file. The server will always register these endpoints on startup regardless of the activation mode.
To do what you want, IceGrid would need to allow static endpoint registration but as Matthew mentioned, such a setup could be difficult to administrate as you would have to assign the endpoint information at deployment time for each server. It seems to me that the best would be to have IceGrid check for the DN of the server before to accept the endpoint registration, we'll consider this for addition on our TODO list for IceGrid!
Btw, you could also consider implementing the Ice locator and locator registry yourself instead of using IceGrid (or you could also delegate the implementation to IceGrid and add all the security checks you need). See the Ice manual for more information on the locator interface.
Cheers,
Benoit.0 -
Thanks for your help,
now I'm going to change the architecture and use a simple DNS Server, for dynamic updates I'll use an Ice adapter that accepts update requests, verifies the certificate and, if allowed, makes a dynamic update to the dns server.0
