> On Apr 29, 2015, at 12:56 PM, Steve Moyer <[email protected]> wrote: > > We've got a cluster of Java EE 7 application servers that host a significant > number of services and applications and are trying to follow the principle of > least privilege. > > Most of the services and applications simply need to retrieve permissions and > constraints from our Fortress server ... using an very unprivileged account > works fine (and we even have a set of OpenLDAP ACLs that enforce these > restrictions if anyone is interested). > > There are two other applications (so far) that need greater privileges and > we're wondering to make alternate fortress.properties files available to > those two applications. We're running on JBoss/Wildfly and so far our best > approach is to provide multiple modules and use the > jboss-deployment-structure.xml file in the two more privileged applications > to exclude the basic fortress.properties file and include the more privileged > one. > > Note that the fortress.properties files (and all our system configuration > files) are managed by the operations group and so they can't simply be > included in the application's WAR file. > > Any suggestions?
We have identified a similar concern with the fortress-web app. That is the war that can be downloaded has embedded fortress.properties and (right now) the only way to customize the ldap server coordinates and credentials is to extract artifact from jar, change and repackage. Obviously this isn’t an ideal scenario. I have opened an issue to track: https://issues.apache.org/jira/browse/FC-96 Basically the idea is to externalize the ldap config params with tomcat context.xml &/or system env variables. Would either work for your deployment scenario? Shawn [email protected]
