Within the previous AS releases there are a few login modules that make use of properties files to store the users and roles, has there been any consideration yet as to how the equivalent capabilities will be provided in the context of AS7 where the hosts running the AS servers may be remote from the configuration?

Ideally the container will only have the "other" security domain configured in the domain xml. All applications would install their own security domain along with the files required for them. This way the property files will be available in the classpath of every host.

That would seem to be quite a restriction on how users can deploy their applications, a single server can still have multiple applications deployed each with their own domain requirements.

Also what do you mean when you say "All applications would install their own security domain along with the files required for them." - are you saying the domain would no longer be defined within a subsystem?

We can define security domain in the subsystem but like I said, ideally in the subsystem we will strive to have only the "other" defined. Applications would deploy something like security-domain.xml where the particular security domain is defined. For example if were to have a jmx-console.war it would deploy its own security domain (perhaps in the root folder or WEB-INF) along with the jmx-console-users.properties and jmx-console-roles.properties in the WEB-INF/classes directory.

So in this case you would be looking for the security domains to be statically defined within the application rather than centrally defined / manageable within the domain model - so to modify the configuration of a security domain the administrators would be required to redeploy their apllication across their domain to pick up a new configuration.

I actually disagree with application security configurations as being the recommended practice. The domain model represents administrative concerns, and a security policy is certainly an administrative concern, at least a reference to which policy should be used. We really don't want people putting password files in their deployments do we?

The properties file based login modules just mirror the /etc/passwd type functionality. They are used mainly for test deployments or such. Nobody should go into production with property based login modules. As Marcus said, real world deployments go with ldap or db.

An adminstrator should be able to specify or override an application specific security domain setting. If needed, it could be a domain property to ignore security domain settings from applications, but it certainly is an ease of use feature to allow them.

Can we have a properties element in the security domain schema that can allow for the properties files information to be provided?

We should also support property value obfuscation based on some domain server key in general for properties. Is that a notion we have in the domain model?

That could also be very useful for the out of the box handling of the users and roles for securing the management APIs. If some of the PicketLink functionality can be exposed as domain operations the admin console would then be able to manipulate the users and their roles.

We need to be very careful about how user management is done, if it should be done at all for 7.0. Anything that stores state has to somehow be replicated across all the hosts in the domain. This opens the door to all kinds of problems:

Do you allow distribution of keystores which may have private keys? (very dangerous)

Do you store passwords in the domain.xml, and do you obfuscate them giving a false sense of security?

If it's not in domain.xml how is the state going to be replicated in a way thats consistent with domain.xml?

Also note that anyone serious about security, is probably going to prefer a centralized security server over a user password distribution model. In this case all of the work we do here would go to waste.

In the meeting in Madison, we talked about how the likely easiest thing to do was to just have the domain.xml REFER to whatever the security store is, and then let the user decide how it gets on the box if it needs to be. They already have to install AS for every location, so that might as well drop a properties file if thats what they are using.