In order to be able to restrict access to an object to either roles, a group of users or even a single user, all of these objects implement this interface, thereby allowing for one signature on the secured objects.
The implementations then need to make sure they can recognize the authority and resolve the permissions that were applied. For example, if a secured object o
is told to only allow access to {@link Role}r
, and then o
is being accessed by {@link ch.entwine.weblounge.common.security.User} u
who happens to haverole r
assigned, access should be granted.
Known authorities are:
ch.entwine.weblounge.common.security.Role
ch.entwine.weblounge.common.security.Group
ch.entwine.weblounge.common.user.User
Permissions can include viewing a portfolio or a class of portfolios, modifying a portfolio, viewing market data, etc.
Permissions can be regular expressions, for example /MarketData/Bloomberg/*/View
, which would grant its holders the right to view any Bloomberg market data. See {@link PathMatcher}.
Note that Authorities
are technically granted to {@link UserGroup}. Each {@link User} belongs to a number of UserGroups
. This reduces the need to modify individualpermissions when users move within a company.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|