-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secure all entities #182
Secure all entities #182
Conversation
@@ -9,7 +9,8 @@ | |||
* The `saveOrUpdate` method of the services are now void. Existing projects that are using this method may need some simple adaptions like changes from `PersistentObject newObject = object.saveOrUpdate()` to `object.saveOrUpdate()` | |||
* The webapp-archetype has been extended to demonstrate how custom permission evaluators for project specific solutions can be used. | |||
* New features: | |||
* An `AbstractSecuredPersistentObjectService` has been introduced. This service provides useful methods to add and remove permissions for certain objects. `PermissionCollection`s will be persisted in the database when using these methods. All services of entities that extend `SecuredPersistentObject` should extend the abstract service mentioned above. | |||
* All `PersistentObject`s now have a set of user and group permissions, i.e. all entities can be protected if needed. In this context, the permission evaluators have been overworked. The database structure has changed here, which means that existing projects are affected by this change and would need a data migration if they can not boot in a vanilla state (with `hibernate.hbm2ddl.auto=create`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overworked => overhauled?
👏 👏 👏 @buehner: nice work! I really like the simplification this brings to both code and applications. Some minor questions (which may even end up in the release notes file, who knows)
I'd love to hear anything from @weskamm about this (and the needed restructurings that will follow for his projects). And as always… we may want to release the next dev-version before we merge this, right? |
Custom permission evaluation can be controlled by injecting a custom implementation of a <beans:bean id="permissionEvaluator" class="de.terrestris.shogun2.security.access.Shogun2PermissionEvaluator">
<beans:property name="permissionEvaluatorFactory">
<!-- This is how project specific permission evaluators can be used/configured -->
<beans:bean class="de.terrestris.sandbox.security.access.factory.ProjectEntityPermissionEvaluatorFactory" />
</beans:property>
</beans:bean> The factory is responsible to return the correct permission evaluator for a given entity class, e.g. if(ProjectApplication.class.isAssignableFrom(entityClass)) {
return new ProjectApplicationPermissionEvaluator();
} The concrete permission evaluators need to implement the method @Override
public boolean hasPermission(User user, E entity, Permission permission) {
...
} It is recommended to extend the following SHOGun2 base classes when implementing a factory or a permission evaluator:
Then you can implement your custom logic and call the methods from the parent classes as a fallback/default. |
nice restructuring, i like the idea to have every entity secured by default and configuring access on a project level. Maybe you want to put your explanations from above somewhere in the readme / docs? |
Previously there were tables - e.g. As the
So the data from |
👍 |
8bf63d7
to
dc49738
Compare
any concerns merging this now @marcjansen ? i could successfully run this PR in a project! |
If you are in a hurry, we can do it later. Looks great otherwise 👍 |
We'll do the documentation later. I created a separate issue for this: #183 |
This PR contains a major refactoring of the permission handling:
SecuredPersistentObject
has been removed and itsuserPermissions
andgroupPermissions
properties have been moved up to thePersistentObject
model, which allows us to protect all entities now (based on project specific needs). The services and tests have been adapted according to this change.hibernate.hbm2ddl.auto=create
) there will only be one table for all user permissions and one table for all group permissions (of all entities). This is a huge simplification on the database side! Existing projects that can not start in a clean state need a data migration.AbstractPermissionAwareCrudService
has been introduced and should be extended by ALL services. There is only one expection:PermissionCollectionService
. Have a look at the release note changes within this PR for details.SecuredPersistentObject
) anAlwaysAllowReadPermissionEvaluator
has been introduced. By default, this evaluator allows READ access for the following entities (and all their subclasses):Extent
InterceptorRule
LayerAppearance
LayerDataSource
Layout
MapConfig
MapControl
Module
Role
TileGrid
Token
SecuredPersistentObject
s):AbstractLayer
Application
File
Person
UserGroup
Please review!