directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <smckin...@apache.org>
Subject Re: Multiple fortress.properties files on one server
Date Wed, 29 Apr 2015 19:14:31 GMT

> On Apr 29, 2015, at 12:56 PM, Steve Moyer <smoyer@psu.edu> 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
smckinney@apache.org

Mime
View raw message