JBoss AS7: Brainstorm Admin Console Security Tab

[anil.saldhana]

This thread is mainly to discuss the security configuration elements in the admin console. 

The main task that is primarily done by users is configuring the security domains.

Security Domains:

Security Domains need to have CRUD capabilities.  The CRUD should not require server restart.

The constituents of a security domain include:

• Security Domain Name.
• Authentication
  • Stack of Login Modules
    • A login module has
      • code
      • flag (required/sufficient/optional/requisite)
      • set of module options
• Authorization
  • Stack of Policy Providers
    • A policy provider has the same settings as login module.
• Mapping
  • Stack of Mapping Providers
    • A mapping provider has
      • code
      • type
      • set of module options
• Audit
  • Stack of Audit Providers
    • An audit provider has
      • code
      • set of module options

Visually, I am thinking for the module options, you can provide a button with ellipsis which when clicked, gives opportunities to enter key value pairs.

From prioirty perspective, the configuration for authentication is very high.

Authorization second high.

Mapping and Audit are good to have in console.

Lets get this taken care of first to work on other items - TBD

Other aspects of security

It will be nice if the user can get to the other security things such as Hornetq, Management Security etc from where the security subsystem is configured.

JIRA Issues:

https://issues.jboss.org/browse/AS7-1781

[jason.greene]

Anil Saldhana wrote:

Security Domains need to have CRUD capabilities.  The CRUD should not require server restart.

Just a note that my refactor adds the ability to restart a domain without requiring a restart but that means any service which depends on that security domain (perhaps a deployment) will be restarted as well. For this reason the default is to put the server in a state where it must be restarted at the next opportunity for the change to take affect.

If the console passes the ALLOW_RESOURCE_SERVICE_RESTART operation header, which is intended to be triggered by some checkbox or dialog that tells the user what that action means, then the doman service will bounce.

If however, the pbox impl is extended to support hot runtime updates in the futrue, we can replace the restart stuff with that.

[bosschaert]

Hi Anil,

Thanks for this. I will do these 4 first and then we can re-evaluate the rest.

Anil Saldhana wrote:

It will be nice if the user can get to the other security things such as Hornetq, Management Security etc from where the security subsystem is configured.

Do you mean simply a link that would open the relevant screen? Where would you ideally see these links appear?

Best regards,

David

[anil.saldhana]

David,  my view was the user may want to look at the security settings for the entire server.  So he may start with hornetq security and may want to move onto the AS security,  http mgmt security and vice-versa.  More of a usability thing. 

Not sure, the perfect way to do it.:)

Maybe,  "click here to go to hornetq security",  "click here to configure hornetq security" type of links.

[anil.saldhana]

Jason Greene wrote:

Anil Saldhana wrote:

Security Domains need to have CRUD capabilities.  The CRUD should not require server restart.

Just a note that my refactor adds the ability to restart a domain without requiring a restart but that means any service which depends on that security domain (perhaps a deployment) will be restarted as well. For this reason the default is to put the server in a state where it must be restarted at the next opportunity for the change to take affect.

Jason, I do not think the services that depend on a security domain need to be restarted.  Some of the reasons are as follows:

* The PicketBox layer has an authentication cache that may have stale information.  So that needs to be flushed for the security domain that was restarted.

* Web layer caches the roles in the tomcat generic principal in the catalina session.  So the security domain changes may require the currently authenticated user to have different roles, than what is currently available in the cached user principal. But I am sure it is good to invalidate the session principal or try to do authentication again, as it may have an effect on the user experience.

* All the other layers - ejb3, hornetq, jca etc are not affected by the security domain restart.

[anil.saldhana]

David Bosschaert wrote:

Hi Anil,

Thanks for this. I will do these 4 first and then we can re-evaluate the rest.

Anil Saldhana wrote:

It will be nice if the user can get to the other security things such as Hornetq, Management Security etc from where the security subsystem is configured.

Do you mean simply a link that would open the relevant screen? Where would you ideally see these links appear?

Best regards,

David

David, additionally I think "security" should be prominent on the LHS.  Currently it is hidden inside "container".  I would think the user/admin may want to configure the security of the JBoss AS instance and should start from one place.  Of course, he should be able to get to some of the subsystem security configuration (hornetq, domains, mgmt etc) from those subsystem also.  Just IMO.

[bosschaert]

Anil Saldhana wrote:

David, additionally I think "security" should be prominent on the LHS.  Currently it is hidden inside "container". 

Ok - I'll make it a top level component for the moment. I know Heiko was trying to reduce the number of top-level components but its easy to move it down again if feeling is that things are getting too crowded.