Where to store global enterprise properties?

Question

I'm faced with a crowd of java applications, which need different global enterprise wide properties for operation, for example: hostname of the central RDBMS, hostname and location of the central self-service portal, host location of central LDAP, host location of central mail server etc.

Formally we build each application with a properties file, where all this properties are definied. But that's a very bad solution, because if the hostname of the mail server changes, we need to change the properties files for each application and deploy all applications again.

Our idea is to centralize this properties, so that each application can ask for each property at runtime, for example:

1. Idea: Put the properties file to an easy accessible file share. So if we need to change a property, each application uses the new properties.

2. Idea: Put the properties to database. Main disadvantage: we need a dependency to database client libraries for each application.

3. Idea: Put all applications into one big application server, that provides system properties for each application. Main disadvantage: needs deployment of each application to one application server. But that isn't a realistic scenario.

4. Idea: Webservice that provides global enterprise wide properties. Main disadvantage: not very secure, because some properties are passwords or user credentials.

What other alternatives are recommended? What is state of the art?

Answer 1

There are three principally different approaches:

1. Have the applications pull the configuration every time.
2. Have a tool to push the configuration to the applications when it changes.
3. Make sure the configuration does not change.

In increasing order of preference. So

3. Make sure configuration does not change.

This is the preferred option. Create suitable aliases for everything that don't need to change.

Domain name for mail server should never change. The host can, but you just redirect the mail.company.com or mail.inranet¹ to the new host. The same applies for all other network locations. Just create suitable DNS names for them. The same goes for database.company.com, ldap.company.com, self-service.company.com etc. Each web service and web application should have it's own vhost too, so you can move each independently without having to change the dependent applications.

The only case where the host names would change is when when you for example split the database server to two separate databases, but then you have to configure different applications differently, so the central configuration isn't going to help you anyway.

Similarly, each application should have separate account to the database, named as the application and limited to only the operations the application needs. This is for security reasons to minimize the damage if some of the applications is compromised. As a side-effect, it gives each application it's own username and password that don't need to change often, so no more reason for central configuration. Quite contrary; you want to limit the number of places that have each password so when somebody cracks one, the other applications and their accounts are not compromised.

In a sense, it is a shared configuration, but stored in the DNS server. And don't forget DNS can store various other information. There is the SRV record for recording ports where services run, records for storing various kind of encryption keys etc.

2. Have a tool to push the configuration to the applications

There is various configuration management software. These are tools that take care of installing software and deploying configuration across networks. Any non-trivial network should use one to ensure installing security updates.

If you have one, just add appropriate rules to deploy the properties file to all servers that run some application. If you don't, pick one² and do the same, plus configure it to take care of the security updates.

Note, that these tools can also take care of restarting the application servers when they deploy new configuration or otherwise notify the applications that they need to reload the configuration.

So this is a good option, because such tool is very useful for administering the network in general.

3. Have the applications to pull the configuration.

This requires changing each application in advance. And it won't solve the issue completely anyway, because it suffers the chicken-and-egg problem. You still have to configure the location from which you should pull the rest of the configuration.

File sharing is obviously easiest regarding size of changes to each application. Just remember you'll have to restart the applications too or implement some mechanism for notifying them when configuration is changed, which also reduces the usefulness of the solution.

So I would definitely not recommend this approach of which all your original options are variations.

¹_{You can use arbitrary non-existent top level domain in internal network and it has the advantage that you won't have to change it even if the company is renamed. Just don't use .local, which is reserved for mDNS.}

²_{Or ask your system administrator to pick one; they are the one who will interact the most with it.}

Answer 2

Related to the last approach, using a web service: you may want to have a look at Apache Zookeeper. From its documentation:

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.

You are right to fear the security implications of this approach. Please note that Zookeeper comes from the Hadoop ecosystem, so its original intention was to provide configuration synchronization for Hadoop clusters, and other services that interact with Hadoop (like Hive, HBase, etc ...).

IMHO, Hadoop has never been very security-aware, since it expected all of these services to work in a trusted environment, but it is getting better at that and ZK may be an option to consider. You may configure ZK to perform authentication and authorization prior to giving away all your secrets, but these options seem to be disabled by default.