Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.2-RC1
-
Fix Version/s: 2.2-RC1
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
The new security subsystem allows roles to be derived from different role services. The danger of name clashes is obvious.
On inserting a new role, the role name has to be checked against all roles in all role services. Duplicate names are not allowed. Additionally, the following system roles are reserved for Geoserver.
1) ROLE_ADMINISTRATOR (administrator)
2) ROLE_GROUP_ADMIN (to administer groups )
3) ROLE_ANONYMOUS ( used for an anonymous authentication)
4) ROLE_AUTHENTICATED (this role is assigned to each successful authentication)
1) and 2) can be mapped to local roles for each service. These roles are never assigned to a user/group directly, the mapped roles have to be used for assignment.
It is not allowed to insert a role into a role service named like a system role described above.
3) and 4) are never assigned to user/group directly.
Additionally, migration code has to migrate rest.properties,layers.properties and service.properties to use the role mapping described above. 1) is replaced by ADMIN, which is the local role name for the default XML role service. The default XML role service maps its local role ADMIN to ROLE_ADMINISTRATOR.
On authentication, the roles are calculated. If the authenticated user has a local admin role, he also has the role "ROLE_ADMINISTRATOR". The same holds true for the new role ROLE_GROUP_ADMIN.
No changes are required for the code relying on "ROLE_ADMINISTRATOR" !
The roles for access control (data and services) is calculated the following way:
ROLE_ANONYMOUS + ROLE_AUTHENTICATED + union of all roles in all role services.
Sounds good Christian. One thing I request is that specifying no prefix on a role name be supported, at least syntactically. No prefix should basically mean "system", or perhaps mean the current active role service.