Bug 1016934

>> This seems to work fine but again the the Membership view will only show those in a role with an ALLCAPS name or SuperUse

I can see roles such as "host-master-ADMINISTRATOR" in assignment dialog without any issues 


/core-service=management/access=authorization/role-mapping=host-master-ADMINISTRATOR:add()

/core-service=management/access=authorization/role-mapping=host-master-ADMINISTRATOR/include=host-master-aministrator:add(name=host-master-administrator, type=user, realm=ManagementRealm)

If this is not a blocker for you, I'd like to postpone that until there's a way to read the standard roles names from the management API

General comments on how we want to handle case sensitivity and role names:

1) The persistent configuration should require use of the formal names of the roles. We should not be lenient and accept mismatches due to case.

So, if the user creates server-group-scoped-role=foo we should not accept role-mapping=FOO.

We can be (and are) lenient re: case with the "base-role" attribute of a scoped-role resource, but only in terms of accepting input. The value actually stored in the model is the formal name of the role, not any original case-incorrect input. It's technically possible to be lenient like this with an attribute, whereas it isn't possible with a resource address element like role-mapping=foo.

2) The formal names of legal roles should be expressly provided via the management API and should not involve any hard coding in the tools. I will add two runtime-only attributes of type ModelType.LIST to the /core-service=management/access=authorization resource:

standard-role-names
all-role-names

The latter being a superset of the former.

Exposing this should be a trivial task where I can complete a pull request today.

3) I'd prefer to stick with the existing mixed case names as the formal names for the standard roles, as that is what we will ship in the beta.

4) The formal name of a scoped role is the value portion of its address.

So /core-service=management/access=authorization/server-group-scoped-role=SCOPEDRoleA:add(...) creates a role whose formal name is "SCOPEDRoleA".

5) The names of scoped roles must be unique ignoring case with respect to any pre-existing roles, standard or scoped. This makes 7) below possible. So, /core-service=management/access=authorization/server-group-scoped-role=SuPeRuSeR:add(...) would be rejected.

This is already enforced.

7) When run-as role mapping is done by a superuser (e.g. :some-op{roles=deployer} we should be lenient regarding case. This is already handled that way.

8) The :whoami operation should if necessary be tweaked to ensure that the formal names of roles are returned, and not case-insensitive variants.

After further examination of this I am rising severity. There is also a very similar issue with role-mappings (BZ1018521).

I think we should address this ASAP.

Harald Pehl <hpehl> updated the status of jira HAL-241 to Resolved

Pull request https://github.com/jbossas/jboss-eap/pull/529 is merged implementing items 2) and 8) from Comment 5 above.

Heiko Braun <ike.braun> made a comment on jira HAL-241

I assume any role with insufficient priv's. I.e. serve group scoped role, monitor, etc. These roles cannot log in at all.

Harald Pehl <hpehl> updated the status of jira HAL-241 to Resolved

Harald Pehl <hpehl> made a comment on jira HAL-241

Standard role names are loaded on demand

Fixed in HAL 2.0.5.Final

Verified 6.2.0.ER7