Task #37451

Rework usage of Roles in the security framework

Added by Rens Admiraal 12 months ago. Updated 1 day ago.

Status:Under Review Start date:2012-05-23
Priority:Should have Due date:
Assignee:Rens Admiraal % Done:

0%
Category:Security
Target version:-
Sprint: Has patch:No
PHP Version: Complexity:
Votes: 1 (View)

Description

Roles are now simple string values but there's actually an entity object for it. We need the Roles to be persisted (like for example to to add new roles in the phoenix backend)

Related issues

related to TYPO3.Flow - Bug #28862: Inconsistent handling of roles as objects and strings in ... Resolved 2011-08-09

Associated revisions

Revision a79904d9
Added by Rens Admiraal 12 months ago

[FEATURE] Add hasRole() method to Account entity

At the moment the roles still have to be persisted as
strings in the serialized roles property in the database.
Already converting all roles to objects would require
some more refactoring.
This change is tested on already existing, and on new
users.

Change-Id: Ibb4989f43d4e92e2e19732786999654eb6531fb8
Releases: 1.2
Related: #37451

Revision f0776fb3
Added by Karsten Dambekalns about 1 month ago

[!!!][FEATURE] Handle roles consistently as objects

With this change roles are consistently used as objects.

To prevent naming conflicts between roles from different packages the
package key is added to the role names.

The handling of roles now is more strict and does not allow the use of
not configured (non-existent) roles anymore.

Roles are now referenced as real instances instead of their string
identifiers in models. Roles which were defined in policies are now
automatically mirrored to the RoleRepository (usually stored as a
table in a database).

The getRoles() method has been removed from TokenInterface.

Change-Id: I39f335baa01fbe9b883e98e85cb1f063bbaf5744
Resolves: #28862
Resolves: #43578
Related: #37451
Related: #27698
Releases: 2.0, master

Revision 28e52aa8
Added by Karsten Dambekalns about 1 month ago

[!!!][FEATURE] Handle roles consistently as objects

With this change roles are consistently used as objects.

To prevent naming conflicts between roles from different packages the
package key is added to the role names.

The handling of roles now is more strict and does not allow the use of
not configured (non-existent) roles anymore.

Roles are now referenced as real instances instead of their string
identifiers in models. Roles which were defined in policies are now
automatically mirrored to the RoleRepository (usually stored as a
table in a database).

The getRoles() method has been removed from TokenInterface.

Change-Id: I39f335baa01fbe9b883e98e85cb1f063bbaf5744
Resolves: #28862
Resolves: #43578
Related: #37451
Related: #27698
Releases: 2.0, master

History

#1
Updated by Karsten Dambekalns 12 months ago

  • Project changed from TYPO3 Flow Base Distribution to TYPO3.Flow

#2
Updated by Karsten Dambekalns 12 months ago

  • Category set to Security
  • Has patch set to No

#3
Updated by Rens Admiraal 12 months ago

Some short notes from a discussion with Christian:

  • Role is an entity
  • Maybe we should keep special roles in memory only (like anonymous and everybody, which are both not assigned by relation but by context)
  • Matching on string values should still be possible
  • Roles configured in Policy.yaml should automatically be persisted (probably in the policyService)
  • Identifier has to be unique, but should probably not be annotated @ORM\Id
  • There should be an easy way to find all parent roles

#4
Updated by Robert Lemke 10 months ago

Rens Admiraal wrote:

  • Role is an entity

yes!

  • Maybe we should keep special roles in memory only (like anonymous and everybody, which are both not assigned by relation but by context)

yes, anonymous and everybody are hard-wired in the security framework and certainly should stay like that. So: don't persist.

  • Matching on string values should still be possible

you mean hasRole($string) etc? Then sure!

  • Roles configured in Policy.yaml should automatically be persisted (probably in the policyService)

And there we start mixing things up … I think what you really want is persisting groups, not persisting roles. Let's discuss that.

  • Identifier has to be unique, but should probably not be annotated @ORM\Id
  • There should be an easy way to find all parent roles

#5
Updated by Rens Admiraal 9 months ago

  • Assignee set to Rens Admiraal

#6
Updated by Rens Admiraal 9 months ago

  • Subject changed from Store roles as an entity to Rework usage of Roles in the security framework

The changes pushed to the review queue implement the following concept:

  • Roles are defined in a programmatic way (Policy.yaml)
  • The policyService / securityContext handle Roles as objects (not as string, exception: the hasRole requires a string representation)
  • Roles reside in their own package namespace (like Foo.MyPackage.RoleName)
  • 'Old style definition' should still work
  • The framework should support nestable groups which can have roles assigned to make roles configuration more flexible in an application if needed

#7
Updated by Karsten Dambekalns 6 months ago

  • Status changed from New to Under Review

#8
Updated by Karsten Dambekalns 6 months ago

  • Target version set to 2.0

What those changes are missing as of today - to fully replace the idea of the AuthorizationGroup - is an addRole() method

#9
Updated by Karsten Dambekalns 5 months ago

  • Target version changed from 2.0 to 2.1

#10
Updated by Robert Lemke 1 day ago

  • Target version deleted (2.1)

Also available in: Atom PDF