Task #37451
Rework usage of Roles in the security framework
| Status: | Resolved | Start date: | 2012-05-23 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | Rens Admiraal | % Done: | 100% |
|
| Category: | Security | |||
| Target version: | TYPO3 Flow Base Distribution - 2.0 | |||
| Sprint: | Has patch: | No | ||
| PHP Version: | 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
Associated revisions
[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
[!!!][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
[!!!][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 about 3 years ago
- Project changed from TYPO3 Flow Base Distribution to TYPO3.Flow
#2 Updated by Karsten Dambekalns about 3 years ago
- Category set to Security
- Has patch set to No
#3 Updated by Rens Admiraal about 3 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 about 3 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 almost 3 years ago
- Assigned To set to Rens Admiraal
#6 Updated by Rens Admiraal almost 3 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 over 2 years ago
- Status changed from New to Under Review
#8 Updated by Karsten Dambekalns over 2 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 over 2 years ago
- Target version changed from 2.0 to 2.1
#10 Updated by Robert Lemke about 2 years ago
- Target version deleted (
2.1)
#11 Updated by Karsten Dambekalns almost 2 years ago
- Status changed from Under Review to Resolved
- Target version set to 2.0
- % Done changed from 0 to 100