The fundamental difference between a couple of the role schemes we've looked at is how they deal with permissions for security privileged resources. Basically there are two variants:
1) An admininistrator role that effectively is root.
2) A split-responsibility setup, where there is an Administrator role that can deal with application level security, and an Admin Security Manager role that deals with administrative security.
The rationale for the split-responsibility setup is different parts of an organization deal may deal with application level security versus administrative security; e.g. the application teams will deal with the former while core IT will deal with the latter.
Some questions are:
1) Do we want to support separate roles for application level security vs administrative security?
2) If we do, can support for this be deferred to a subsequent iteration of this feature?
3) If we do, what changes are required to the underlying AS to allow a meaningful separation of the roles?
The first question is open for discussion. I'll address the second in a later post. This post is focused on the 3rd.
The way WildFly currently works, we cannot enforce a valid separation between application security management and core administrative security management. There are two basic issues:
1) Application-level security constructs (i.e. security domains in the security subsystem) leak into core administrative security via the ability to configure a core security-realm resource to delegate to a JAAS security domain configured in the subsystem.
2) Core security constructs leak into application security via a couple paths:
a) Ability to reference core security realms from security subsystem security domains.
b) Ability to reference a core security realm from a remoting subsystem connector.
(There's also a twist where a managed domain server can be configured to use a remoting subsystem endpoint for it's management connection back to its Host Controller. I need to untangle the implications of that.)
In a discussion with Darran and Heiko today, we discussed the following possible tasks for resolving these problems:
A) Remove the need for referencing security subsystem security domains from the core security realm by adding support to security realms for the configuration elements currently only available via security domains (login modules etc).
B) Remove the need for referencing core security realms from subsystem resources by adding the ability to configure security realms within the security subsystem.
This would allow a clean separation between administrative security and application security.
This direction would be contrary to a stated goal of doing everything in a security subsystem. However the intent would be the configuration elements would be consistent (with most code shared as well). Even with everything in a single security subsystem, if a clean separation of application security from administrative security is a valid long term requirement, the configuration of that single subsystem would have to have some construct to reflect that separation.
Following this approach does not allow us to require incompatible changes in this first iteration of the feature. So, an existing config with references between core security realms and subsystem resources will have to still be supported.
However, it is not required that we support configuring the new access control features with such a configuration. It is reasonable to require users who wish to enable access control to update their configs to use the new configuration options mentioned above. Enforcing this would lead to a 3rd task:
C) Detect cases where access control is configured but the config uses legacy model reference that blur the lines between administrative security and application security. Reject such configurations.
Thanks, Heiko, for driving the discussion that showed the need to clarify all this.
Thoughts, everyone?