11 Replies Latest reply on Nov 4, 2011 6:34 AM by Yves Peter

    Management Interface security and security-domains

    Yves Peter Newbie

      Hi everyone


      I'm currently trying to set up JBoss 7.0.2 for our environment and have arrived at hardening JBoss management interfaces.

      Why did you decide to create a new way to configure security modules for the management interfaces via security-realm instead of using the already implemented security-domains in the security subsystem? I mean why not take advantage of waste amount of the already implemented modules like LDAP, Database authentication etc. that are tested and have a huge number of features. The same goes for the JMX remoting subsystem.

      An option would be to create a security-realm which delegates to a security domain but removing the security-realms would be nicer...


      Currently I'm missing the following features from the management security configuration:

      • Does every user in the LDAP have access to the management interfaces or is it restricted to a certain role? We don't have a separate LDAP for admin users and it would be nice if we could use a role for that.
      • Client Cert with LDAP authentication for the Web Console.


      What do you think?

        • 1. Re: Management Interface security and security-domains
          Darran Lofthouse Master

          The reason for the change in direction was so that we could support authentication mechanisms at the transport level which don't require the users password to be sent in a reversable format.


          Using JAAS security domains the clear text password needs to be passed along with the username to the login modules for verification - switching to CallbackHandlers allows more choice over the mechanisms.


          In addition to this not all of the processes that expose domain management even have the security subsystem available to delegate to i.e in domain mode the host controller which exposes the management interfaces does not have running subsystems.


          At the moment by default authorization is not implemented for domain management so it is a case of all users have access, I will test if we can filter the user by one of their roles - this would allow the users that can be authenticated to be restricted to just those with a specific role.


          For client cert based authentication that is being implemented shortly, we don't currently have SSL enabled in Remoting for the Native interface and need consistency across the two.


          For AS 7.1 discussions are still continuing on better aligning the two approaches.

          1 of 1 people found this helpful
          • 2. Re: Management Interface security and security-domains
            Yves Peter Newbie

            Thanks for your quick response. I don't get that part:

            Darran Lofthouse wrote:


            Using JAAS security domains the clear text password needs to be passed along with the username to the login modules for verification - switching to CallbackHandlers allows more choice over the mechanisms.

            Isn't that already possible if you use for example a basecert login module with an ldap module and passwordstacking? No password needed, or what do you mean?


            I noticed that setting recursive="true" in management/outbound-connections/ldap should be possible after jboss-as-config_1_0.xsd but on startup JBoss throws a parser exception:

            22:45:47,704 ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration

            22:45:47,705 ERROR [stderr]     at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:89)

            22:45:47,705 ERROR [stderr]     at java.lang.Thread.run(Thread.java:619)

            22:45:47,705 ERROR [stderr] Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration

            22:45:47,706 ERROR [stderr]     at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:115)

            22:45:47,706 ERROR [stderr]     at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)

            22:45:47,706 ERROR [stderr]     at org.jboss.as.server.ServerService.boot(ServerService.java:195)

            22:45:47,706 ERROR [stderr]     at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)

            22:45:47,707 ERROR [stderr]     ... 1 more

            22:45:47,707 ERROR [stderr] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[69,4]

            22:45:47,707 ERROR [stderr] Message: Unexpected attribute 'recursive' encountered

            22:45:47,707 ERROR [stderr]     at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:84)

            22:45:47,707 ERROR [stderr]     at org.jboss.as.controller.parsing.CommonXml.parseLdapConnection(CommonXml.java:501)

            22:45:47,708 ERROR [stderr]     at org.jboss.as.controller.parsing.CommonXml.parseConnections(CommonXml.java:448)

            22:45:47,708 ERROR [stderr]     at org.jboss.as.controller.parsing.CommonXml.parseManagement(CommonXml.java:413)

            22:45:47,708 ERROR [stderr]     at org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:158)

            22:45:47,708 ERROR [stderr]     at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:91)

            22:45:47,709 ERROR [stderr]     at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:79)

            22:45:47,709 ERROR [stderr]     at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)

            22:45:47,709 ERROR [stderr]     at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)

            22:45:47,709 ERROR [stderr]     at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:107)

            22:45:47,709 ERROR [stderr]     ... 4 more

            • 3. Re: Management Interface security and security-domains
              Darran Lofthouse Master

              What I mean to say is that for domain management we have now switched to using SASL to handle the authentication for the native management interface and for the HTTP interface we have followed the same model.


              When working traditionally with JAAS the flow of information is: -


                Client -> HTTP Server Authenticator -> JAAS (Login Module)


              So here the incomming information needs to be passed across to the login module for independent verification, the reason I said password is because that is the mechanism used in the majority of cases, the certificate for BaseCert effectively replaces the password - the problem here is that we are still in the situation where it is assumed there is a username and password (or equivalent) for each request.


              The move to the SASL style change this to: -


                Client -> HTTP Server Authenticator <- Realm (Callback Handlers)


              So now instead of passing information to JAAS a realm is used to retrieve information required for authentication, this means that now the 'HTTP Server Authenticator' layer is 100% focussed on the transport level of the authentication process and the 'Realm' tier is 100% focussed on accessing the configured store.


              When using the common username and password mechanisms the need for this switch is not as obvious and for the simple authentication mechanisms we may still enable a realm to wrap callbacks to the login modules but as new authentication mechanisms are added the previous approach is no longer flexible enough to support them.


              A classic example would be the work I undertook writing JBoss Negotiation, beyond the message parsing that was needed for previous Java versions the bulk of JBoss Negotiation is to work around the architecture imposed by the JAAS approach, for SPNEGO negotiation we don't have either a username or a password so in the end we have a login module that is very tied to the transport level protocol.  Another mechanism that potentially raises concerns with the architecture is DIGEST authentication, here no password is received from the client only a hash so to work with this and JAAS you need the a login module to verify a mechanisn specific hash - with the realms the authenticator is responsible for validating the hash and the CallbackHandler is dedicated to accessing the store of user information.


              Regarding the parsing error, yes that does look like a bug - I am working on some LDAP issues today so I will also look into that one: -


              • 4. Re: Management Interface security and security-domains
                Yves Peter Newbie

                Thank you very much for taking time to explain it and for opening an issue! Does this mean that the plan is to slowly replace the older JAAS security domains with security realms?

                • 5. Re: Management Interface security and security-domains
                  Darran Lofthouse Master

                  For the issue that you have reported I have just been back and verified the behaviour and it appears you are specifying the recursive attribute on the wrong element.


                  Looking at your stack trace you are specifying it on the connection rather than the authentication definition, when looking at the configuration the outbound connection is used to define how to connect to ldap whilst the authentication definition defines how to search ldap.


                  I have just been verifying if we can add an additional roles filter but that is not currently present, I will see if I can add an additional attribute to define a better filter - at the moment the configuration tries to avoid the complexity of making administrators define the full search but the plan was always to allow more complex filters to be defined if the administrator wishes.


                  Regarding the JAAS security domains, the discussion that has started at the moment is only in terms of how we can better provide CallbackHandlers to the various authentication processes, the discussion hasn't progressed to the JAAS domains although I wouldn't imagine those ever being completely replaced.

                  • 6. Re: Management Interface security and security-domains
                    Darran Lofthouse Master

                    I have created the issue AS7-2031 so we can add an optional more advanced filter for identifying the user to authenticate against from LDAP.

                    • 7. Re: Management Interface security and security-domains
                      Yves Peter Newbie

                      I corrected my mistake and now it works. I'm even using ldaps for the connection, all I had to do was to set the system property javax.net.ssl.trustStore.

                      • 8. Re: Management Interface security and security-domains
                        Darran Lofthouse Master

                        As a further follow up I have just completed the work on AS7-2031, I am just running the testsuite and will then be submitting it for inclusion in AS 7.1


                        The change will now allow for a couple of different options to specify the search filter, the first is still based on just searching the attribute that matches the username: -

                        <ldap connection="EC2" base-dn="CN=Users,DC=darranl,DC=jboss,DC=org">
                        <username-filter attribute="sAMAccountName"/>

                        The second now allows an advanced filter to be defined if additional attributes need to be considered: -

                        <ldap connection="EC2" base-dn="CN=Users,DC=darranl,DC=jboss,DC=org">
                        <advanced-filter filter="(sAMAccountName={0})"/>

                        A more complete authorization solution is still to be considered, however this advanced filter can be used to filter the users based on membership information: -

                        <ldap connection="EC2" base-dn="CN=Users,DC=darranl,DC=jboss,DC=org">
                        <advanced-filter filter="(&amp;(sAMAccountName={0})(memberOf=CN=as7admin,CN=Users,DC=darranl,DC=jboss,DC=org))"/>

                        • 9. Re: Management Interface security and security-domains
                          Yves Peter Newbie

                          That's great news! Can you tell me when it's available in a nightly build? I like to test it in our environment.

                          • 10. Re: Management Interface security and security-domains
                            Darran Lofthouse Master

                            The changes went in on the 12th October so any builds after that point should be suitable: -



                            • 11. Re: Management Interface security and security-domains
                              Yves Peter Newbie

                              I was finally able to test it. I used a filter with a role that only I had and not my colleague. As expected I could login to the admin console and he could not.

                              Here is my configuration:


                                        <security-realm name="PropertiesMgmtSecurityRealm">
                                              <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" />
                                       <security-realm name="LDAPMgmtSecurityRealm">
                                             <ldap connection="ldap_connection" recursive="true" base-dn="OU=Mobi-Acc,DC=domain,DC=mycompany,DC=test">
                                                <!-- which user can connect? TODO: define role for production (ADJBOSS ?)-->
                                                <advanced-filter filter="(&amp;(sAMAccountName={0})(memberOf=CN=TESTROLE,OU=Groups,OU=Mobi-Acc,DC=domain,DC=mycompany,DC=test))"/>
                                       <ldap name="ldap_connection" url="ldaps://addc01.domain.mycompany.test" search-dn="CN=ADUser,OU=Service-Accounts,OU=Mobi-Acc,DC=domain,DC=mycompany,DC=test" search-credential="test123"/>
                                       <!-- Does not work jet: PLAIN not enabled until SSL supported for Native Interface -> LDAP uses plain pw -->
                                         <native-interface interface="management" port="9999" security-realm="PropertiesMgmtSecurityRealm"/>
                                         <http-interface interface="management" port="9990" security-realm="LDAPMgmtSecurityRealm"/>