Geomajas Community Documentation
Geomajas is built to be entirely independent of the authentication mechanism and the way to store policies.
Based on the user who is logged into the system, the following restrictions can apply:
access rights to a command
access rights for a layer
a filter which needs to be applied for a layer
a region which limits the data which may be accessed for a layer
access rights on the features
access rights on the individual attributes of the features
To assure the authentication mechanism is pluggable, an authentication token is used. The authentication token is used to determine the security context . The security context contains the policies which apply and which can be queried.
A list of
security services
can be defined
(using Spring bean security.SecurityInfo
). This list can
be overwritten in configuration. By default the list is empty, which
prohibits all access to everyone. The back-end does however include a
security service which can be used to allow all access to
everyone.
The security service is responsible for converting the
authentication token into a list of
authorization
objects
. The security manager will loop all configured
security services (using Spring bean
security.SecurityInfo
) to find all the authorization
objects which apply for the token. By default the security manager
will stop looping once one of the security services gave a result. You
can change this behaviour to always combine the authorization objects
from all security services.
The system explicitly allows authentication tokens to be generated by different authentication servers. In that case for each authentication server, at least one security service should be configured in Geomajas. However, when using such a configuration, you have to verify that the authentication tokens which are generated by the different servers cannot be the same.
In many systems (including RBAC systems) an authorization object matches a roles for the authenticated user.
Note that, as the actual authentication mechanisms are handled by the security services, Geomajas does not know any passwords or credentials. Similarly the secure, tamper-proof storage of policies is not handled by Geomajas either.
Details about the current authentication token and access to the
policies (using the authorization objects) is available using the
SecurityContext
. The security context is thread specific.
When threads are reused between different users, the security context
needs to be cleared at the end of a request (group). This is normally
handled by the faces.
The following general authorization checks exist:
isToolAuthorized(String toolId)
: true when the
tool can be used. The "toolId" matches the "id" parameter which is
used in the configuration as specified using the
ToolInfo
class.
isCommandAuthorized(String commandName)
: true
when the command is allowed to be called. The "commandName"
parameter is the same as the command name which is passed to the
CommandDispatcher
service.
And for each layer:
isLayerVisible(String layerId)
: true when (part
of) the layer is visible.
isLayerUpdateAuthorized(String layerId)
: true
when (some of) the visible features may be editable.
isLayerCreateAuthorized(String layerId)
: true
when there is an area in which features can be created.
isLayerDeleteAuthorized(String layerId)
: true
when (some of) the visible features may be deleted.
getVisibleArea(String layerId)
: only the area
inside the returned geometry is visible (uses layer coordinate
space). All features which fall outside the layer's MaxExtent area
are also considered not visible.
getUpdateAuthorizedArea(String layerId)
: only
the area inside the returned geometry may contain updatable
features (uses layer coordinate space). All features which fall
outside the layer's MaxExtent area are also considered not
updatable.
getCreateAuthorizedArea(String layerId)
: only
the area inside the returned geometry can new features be created
(uses layer coordinate space). All features which fall outside the
layer's MaxExtent area are also considered not creatable.
getDeleteAuthorizedArea(String layerId)
: only
the area inside the returned geometry may contain deletable
features (uses layer coordinate space). All features which fall
outside the layer's MaxExtent area are also considered not
deletable.
getFeatureFilter(String layerId)
: get an
additional filter which needs to be applied when querying the
layer's features.
isFeatureVisible(String layerId, InternalFeature
feature)
: check the visibility of a feature.
isFeatureUpdateAuthorized(String layerId,
InternalFeature feature)
: check whether a feature is
editable.
isFeatureUpdateAuthorized(String layerId,
InternalFeature oldFeature, InternalFeature newFeature)
:
check whether the update contained in the feature is allowed to be
saved.
isFeatureCreateAuthorized(String layerId,
InternalFeature feature)
: check whether a feature is
allowed to be created.
isFeatureDeleteAuthorized(String layerId,
InternalFeature feature)
: check whether deleting the
specific feature is allowed.
isAttributeReadable(String layerId, InternalFeature
feature, String attributeName)
: check the readability of an
attribute. The result can be feature specific.
isAttributeWritable(String layerId, InternalFeature
feature, String attributeName)
: check whether an attribute
is editable. The result can be feature specific.
These authorizations are split in several groups. The security service is not required to provide an implementation of each authorization test (see API), the security context always ensures that all methods are available.
Checking authentication and fetching the authorization details
can be time consuming (not to mention the hassle of logging in again).
To solve this, the results of the security services can be cached.
When a security service can authenticate a token, the reply can
contain details about the allowed caching. Three parameters are
allowed to be passed, the validUntil
and
invalidAfter
timestamps and an extendValid
duration.
The security manager first checks the cache to find (valid) authentication results. A cache entry is only valid until the "validUntil" timestamp. When an entry is valid, validUntil may be extended until "now" plus "extendValid" duration. However, "validUntil" is never extended past "invalidAfter". When no data can be found in the cache, the security services are queried.
There may be multiple authentications stored for a authentication token. When one of them becomes invalid, they are all considered invalid.
Entering credentials is never handled by Geomajas. When the authentication token cannot be verified, a security exception is thrown. It is up to the client application (the face probably) to assure that a new authentication token is created.
The authorization have two possible results. When reading or rendering, all unauthorized data should simply be filtered without warning or exception. When trying to invoke a command or to create, update or delete, any attempt which is not authorized should result in a security exception.
The security uses the approach that all access is forbidden unless is is allowed. Hence, you will always need to configure at least one security service to assure the system is usable.