9 Replies Latest reply on Apr 9, 2013 2:12 AM by hakimjamali

    Role based access for the web console

    sebastian.otaegui

      Hello guys,

       

      Will there be any way to give different type of access to different roles?

       

      This is, will I be able to give roles as "deployer"/"administrator" so developers can deploy but not change settings of a QA/UAT server?

       

       

      Thanks

        • 1. Re: Role based access for the web console
          jaikiran

          I don't think there's any plan for such level of access control for the admin console. I haven't seen any related JIRAs or discussions.

          • 2. Re: Role based access for the web console
            dlofthouse

            I am currently looking to add some simple role based permissions to the management API which will control what users of the admin console can actually do - to start with I am looking for something fairly coarse grained.

             

            One thing I would find very useful from users of AS7 is some listings of the actual roles their administrators would fit into and the tasks they perform so I can use this as a basis for the coarse permissions.

            • 3. Re: Role based access for the web console
              sebastian.otaegui

              I was thinking in something like

               

              Operator = Can do deploys and configure datasources

              Administrator = Can change all the settings on the app server

              Developer/User = Can do deploys (i.e. wars, ears, etc)

              • 4. Re: Role based access for the web console
                yves.p

                A readonly user would also be nice. Can be used for monitoring and checking settings.

                Something related: will there be a readonly user for jmx and cli for monitoring?

                • 5. Re: Role based access for the web console
                  dlofthouse

                  At the moment we are just finishing off making remote access to JMX accessible over Remoting - this is going to mean that the access to JMX can be secured using the exact same mechanisms as we use for the management interfaces so the users will be the same.  When you say read only access to JMX are you talking about read only access for the MBeans or are you referring to where the domain model is exposed over JMX?

                   

                  At this point I am focussing on the security for domain management itself, however one of main reasons we are doing this is so that we can follow up and use a consistent scheme for authentication and authorization across all management entry points.

                   

                  For the authorization checks we are implementing them server side after the interface specific handling, this means that whatever is implemented server side is going to be applicable equally to all clients so both the web based admin console and the CLI will have the same authorization restrictions, if you write your own client to perform some tasks that would also be subject to exactly the same authorization checks regardless of if your client uses the HTTP interface or the Native interface.

                   

                  The roles listed so far definately fit with the set of standard roles I was starting to consider, I would say I would probably expand the operator role to maybe cover all subsystems that have resources defined within them unless we wanted different operators i.e. they woul also be able to define JMS destinations and JAAS security domains.

                  • 6. Re: Role based access for the web console
                    yves.p

                    Darran Lofthouse wrote:

                     

                    When you say read only access to JMX are you talking about read only access for the MBeans or are you referring to where the domain model is exposed over JMX?

                    I'm talking about read only access to everything that's accessible over jmx, the domain model that's exposed over JMX and any other MBeans. Basically everything that could be used to monitor a JBoss server via jconsole or any other JMX capable monitoring tool (Nagios, Zenoss, Hyperic, RHQ etc). Why is that important?

                     

                    I would define the operator role as someone who can stop/start/restart stuff, empty queues or move messages in the messaging subsystem etc. and would require an admin user to manipulate any configuration.

                    • 7. Re: Role based access for the web console
                      dlofthouse

                      Why is that important?

                      The reason this is important is because I am placing the authorization checks close to the item being secured, i.e. the domain management authoriziation checks are to be performed server side before the operation is executed.

                       

                      Architecturay there is then the integration making the domain model accessible over JMX and then the MBean server exposing the actual MBeans.  As the MBean calls to the domain model are passed to the domain management tier any authorization checks in the domain management tier will apply equally to invocations coming in over JMX and over the domain management inferfaces so a users view and capabilities will be consistent - however this does not cover general authorization for access to the MBeanServer so I will review that separately.

                       

                      Overall I am trying to avoid situations where we implement client / transport specific authorization checks that lead to situations where an end user has different capabilities depending on how they access the server.

                      • 8. Re: Role based access for the web console
                        ddougherty

                        Darran,

                         

                        Is this work completed and slated to be included in an upcoming JBoss release?

                         

                        My company would like to allow the developers on our production support team to access to the JBoss Web Management Console, but we cannot due to the separation of duties that exists in our shop.  In our shop, application updates are normally deployed to production by a build manager - not by the developer(s) who updated the code.  Developers do, however, need to be able to monitor the current state of the AS and see what has been deployed, but they may not change what has been deployed (except in "break-the-glass" situations).

                        • 9. Re: Role based access for the web console
                          hakimjamali

                          Hi,

                           

                          Any updates on this.