1 2 Previous Next 17 Replies Latest reply: Feb 8, 2011 1:21 PM by Anil Saldhana RSS

AS7 Property File Based Login Modules

Darran Lofthouse Master

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?

  • 1. AS7 Property File Based Login Modules
    Marcus Moyses Novice

    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.

  • 2. AS7 Property File Based Login Modules
    Darran Lofthouse Master

    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?

  • 3. AS7 Property File Based Login Modules
    Marcus Moyses Novice

    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.

  • 4. AS7 Property File Based Login Modules
    Darran Lofthouse Master

    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.

  • 5. AS7 Property File Based Login Modules
    Jason Greene Master

    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?

  • 6. AS7 Property File Based Login Modules
    Marcus Moyses Novice

    Security domains based on property files are the simplest of  all login modules we provide. Any serious real world application would actually use DBs or LDAP servers as the backend for authentication.

    I don't see a problem of requiring the property file to be included in the application so it's available in its classpath. Remember web-console used to do just that.

  • 7. AS7 Property File Based Login Modules
    Anil Saldhana Master

    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.

  • 8. AS7 Property File Based Login Modules
    Anil Saldhana Master

    I think extremely simple test deployments can use settings from the domain model. Something along the lines:

     

    <security-domain><login-module name="inlinemodule"><option user="anil" pass="awesome"/> <option role="magic"/></login-module>

     

    This is for testing purposes or demo purposes only.

  • 9. AS7 Property File Based Login Modules
    Scott Stark Master

    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?

  • 10. AS7 Property File Based Login Modules
    Anil Saldhana Master

    A possibility is to create blocks of user/role/group combination in the domain model (using PL IDM), then reference them in the login module.

  • 11. AS7 Property File Based Login Modules
    Darran Lofthouse Master

    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.

  • 12. AS7 Property File Based Login Modules
    Anil Saldhana Master

    I am going to be bringing the PL IDM component as a module.  We need it for user management for components such as HornetQ user mgmt.

  • 13. AS7 Property File Based Login Modules
    Darran Lofthouse Master

    That will be interesting to see - if it meets the out of the box requirements for components such as HornetQ then it may be a good fit for the management API as well.

  • 14. AS7 Property File Based Login Modules
    Jason Greene Master

    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.

1 2 Previous Next