Bug 1016934 - RBAC: roles names are assumed to be upper case by "Membership" dialog
RBAC: roles names are assumed to be upper case by "Membership" dialog
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Console (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity urgent
: ER7
: EAP 6.2.0
Assigned To: Heiko Braun
Jakub Cechacek
Russell Dickenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-08 21:12 EDT by Dana Mison
Modified: 2015-02-01 18:00 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-15 11:22:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker HAL-241 None None None 2014-08-28 07:48:36 EDT

  None (edit)
Comment 1 Jakub Cechacek 2013-10-09 02:47:05 EDT
>> 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)
Comment 4 Harald Pehl 2013-10-09 11:47:37 EDT
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
Comment 5 Brian Stansberry 2013-10-09 12:27:09 EDT
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.
Comment 7 Jakub Cechacek 2013-10-12 17:13:52 EDT
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.
Comment 8 JBoss JIRA Server 2013-10-13 16:37:16 EDT
Harald Pehl <hpehl@redhat.com> updated the status of jira HAL-241 to Resolved
Comment 9 Brian Stansberry 2013-10-13 23:50:56 EDT
Pull request https://github.com/jbossas/jboss-eap/pull/529 is merged implementing items 2) and 8) from Comment 5 above.
Comment 13 JBoss JIRA Server 2013-10-15 01:52:33 EDT
Heiko Braun <ike.braun@googlemail.com> 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.
Comment 14 JBoss JIRA Server 2013-10-15 04:04:48 EDT
Harald Pehl <hpehl@redhat.com> updated the status of jira HAL-241 to Resolved
Comment 15 JBoss JIRA Server 2013-10-15 04:04:48 EDT
Harald Pehl <hpehl@redhat.com> made a comment on jira HAL-241

Standard role names are loaded on demand
Comment 16 Harald Pehl 2013-10-29 09:50:58 EDT
Fixed in HAL 2.0.5.Final
Comment 17 Jakub Cechacek 2013-10-31 09:31:07 EDT
Verified 6.2.0.ER7

Note You need to log in before you can comment on or make changes to this bug.