Task #37451

Rework usage of Roles in the security framework

Added by Rens Admiraal over 8 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Should have
Assignee:
Category:
Security
Start date:
2012-05-23
Due date:
% Done:

100%

Estimated time:
Sprint:
PHP Version:
Has patch:
No
Complexity:

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 AccountResolvedRens Admiraal2011-08-09

Actions
#1

Updated by Karsten Dambekalns over 8 years ago

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

Updated by Karsten Dambekalns over 8 years ago

  • Category set to Security
  • Has patch set to No
#3

Updated by Rens Admiraal over 8 years 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 over 8 years 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 over 8 years ago

  • Assignee set to Rens Admiraal
#6

Updated by Rens Admiraal over 8 years 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 about 8 years ago

  • Status changed from New to Under Review
#8

Updated by Karsten Dambekalns about 8 years 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 about 8 years ago

  • Target version changed from 2.0 to 2.1
#10

Updated by Robert Lemke over 7 years ago

  • Target version deleted (2.1)
#11

Updated by Karsten Dambekalns over 7 years ago

  • Status changed from Under Review to Resolved
  • Target version set to 2.0
  • % Done changed from 0 to 100

Also available in: Atom PDF