[jboss-jira] [JBoss JIRA] (WFLY-3340) Authentication "module-options" inconsistently hash vs list of key/values

[Chris Pitman (JIRA)]

Chris Pitman created WFLY-3340:
----------------------------------

             Summary: Authentication "module-options" inconsistently hash vs list of key/values
                 Key: WFLY-3340
                 URL: https://issues.jboss.org/browse/WFLY-3340
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: CLI
    Affects Versions: JBoss AS7 7.1.1.Final
         Environment: RHEL 6.4, x86_64
            Reporter: Chris Pitman
            Assignee: Alexey Loubyansky


When adding an authentication mechanism to a security domain it is possible to set the module-options with a hash (which is great!). However, as soon as a reload occurs they revert back into a list of key-value pairs. This only makes sense if order matters (which I hope it doesn't) or if keys can be repeated (again, hope not).

Configuration management tools should only change a value when it needs to, and this is way easier if the value that is set is the same value that is read. Hashes are also far easier to work with in ruby/puppet/chef.

Steps to reproduce:
1. Set the module_options on an already existing authentication mechanism:
{code}
/subsystem=security/security-domain=servlet-security-quickstart/authentication=classic:write-attribute(name=login-modules, value=[{"code" => "Database","flag"=>"required","module-options"=>{"dsJndiName" =>
"java:jboss/datasources/ServletSecurityDS", "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?", "role
sQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"}}])
{code}

2. Read the resource (notice that module-options is till a nice easy to use hash!)
{code}
{
    "outcome" => "success",
    "result" => {"login-modules" => [{
        "module-options" => {
            "dsJndiName" => "java:jboss/datasources/ServletSecurityDS",
            "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?",
            "rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"
        },
        "flag" => "required",
        "code" => "Database"
    }]},
    "response-headers" => {"process-state" => "reload-required"}
}
{code}

3. Reload, then read-resource
{code}
{
    "outcome" => "success",
    "result" => {"login-modules" => [{
        "code" => "Database",
        "flag" => "required",
        "module-options" => [
            ("dsJndiName" => "java:jboss/datasources/ServletSecurityDS"),
            ("principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?"),
            ("rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?")
        ]
    }]}
}
{code}

4. module-options is now a list of key-value pairs, and is not equal to what it was set to before





--
This message was sent by Atlassian JIRA
(v6.2.3#6260)