wiki/info/security/permission-concept.md
... ...
@@ -100,14 +100,16 @@ Additionally, on fresh instances not sharing a UserStore, a set of default roles
100 100
101 101
### Role "admin"
102 102
103
-This role implies the "*" permission. It should ideally be used with a user group ownership qualification, such as the server-specific group, making a user with a role qualified in this way an administrator for the server object as well as for all other objects owned by that server group.
103
+This role implies the "*" permission. It should ideally be used with a user group ownership qualification, such as the server-specific group, making a user with a role qualified in this way an administrator for the server object as well as for all other objects owned by that server group. The ``admin`` role could also be used together with a user qualification, as in ``admin::{username}`` to grant a user full permissions to all objects owned by that user. Note that this in the future, as we introduce payed premium content, would include such premium permissions. Likewise, the ``admin`` role qualified to the user's default group ``{username}-tenant`` could be granted to users so they obtain full rights for all objects owned by their default ``{username}-tenant`` group.
104 104
105 105
### Role "user"
106 106
107 107
This role is intended to be used to describe the permissions that object owners shall be granted. In particular, when qualified
108 108
for objects owned by the user being assigned the role, that user obtains the permission to execute actions
109 109
``CHANGE_ACL,CHANGE_OWNERSHIP,CREATE,DELETE,READ,READ_PUBLIC,UPDATE`` for objects of any type. By default, users are also assigned
110
-this role constrained for objects whose group owner is the user's dedicated group (``{username}-tenant``).
110
+this role qualified for objects whose group owner is the user's dedicated group (``{username}-tenant``).
111
+
112
+Note that for good reasons this role does not imply all ("*") permissions to object owners. All permissions would include features that we may want to charge a price for. The ``user`` role shall include only those permissions that all users with no premium permissions have. In a sense, the user role's permission set is the difference of the admin role's permission set ("*") minus all premium permissions.
111 113
112 114
### Role "sailing_viewer"
113 115
wiki/info/security/security.md
... ...
@@ -1,6 +1,6 @@
1 1
# Security
2 2
3
-The Sports Sponsorships Engine (SSE) on which the SAP Sailing Analytics and the SAP Tennis Analytics are based, uses Apache Shiro to implement security. This in particular includes authentication and authorization. This document does not aim to replace the Shiro documentation which is available, e.g., at [http://shiro.apache.org/configuration.html](http://shiro.apache.org/configuration.html), [http://shiro.apache.org/permissions.html](http://shiro.apache.org/permissions.html) and [http://shiro.apache.org/web.html](http://shiro.apache.org/web.html).
3
+The Sports Sponsorships Engine (SSE) on which the SAP Sailing Analytics and the SAP Tennis Analytics are based, uses Apache Shiro to implement security. This in particular includes authentication and authorization. This document does not aim to replace the Shiro documentation which is available, e.g., at [http://shiro.apache.org/configuration.html](http://shiro.apache.org/configuration.html), [http://shiro.apache.org/permissions.html](http://shiro.apache.org/permissions.html) and [http://shiro.apache.org/web.html](http://shiro.apache.org/web.html). It relies on a sophisticated and powerful security engine that is part of SSE and whose [permission concept is described here](permission-concept.md).
4 4
5 5
## Users, Sessions, Roles, and Permissions
6 6
... ...
@@ -58,11 +58,23 @@ There are generally two ways in which some feature can require the user to be eq
58 58
59 59
Example for a declarative permission check:
60 60
[urls]
61
- /api/v1/events = bearerToken, perms["event:view"]
61
+ /api/v1/events = bearerToken, perms["EVENT:READ"]
62 62
This requires users trying to access the URL `/api/v1/events` to be authenticated using a valid `JSESSIONID` cookie or any authentication supported by the `bearerToken` filter such that the authenticated user has permissions that imply the `event:view:*` permission.
63 63
64
-Example for a programmatic check:
65
- SecurityUtils.getSubject().checkPermission("event:view");
64
+Examples for programmatic checks if the domain object, here ``event`` is at hand:
65
+
66
+```
67
+ SecurityUtils.getSubject().isPermitted(SecuredDomainType.EVENT.getStringPermissionForObject(DefaultActions.READ, event))
68
+```
69
+
70
+or
71
+
72
+```
73
+ SecurityUtils.getSubject().isPermitted(SecuredDomainType.EVENT.getStringPermissionForTypeRelativeIdentifier(
74
+ DefaultActions.UPDATE, EventBaseImpl.getTypeRelativeObjectIdentifier(eventId)))
75
+```
76
+
77
+if only an ID such as ``eventId`` is available at the point of the permission check.
66 78
67 79
### Special Case: Permission Checks in the AdminConsole
68 80