Managing access restrictions
[]
Target groups
- Administrator (Web)
- Developer (Web)
Context
OC-Permissions restrict access to content for Website users.
OC-Permissions are not related to permission system implemented in censhare server.
Prerequisites
- censhare-Client (java)
Introduction
The Online Solutions supports a permission concept to restrict access to content for website users. Read on to learn how to setup and use this concept in an easy way.
The online channel permission concept distinguishes two major startegies:
- access restriction on asset access level
- access restriction on explicit actions
Asset access level permissions are used to grant access on exact match.
The protected object and the request for access use the same resource, one as a key the other as a lock. Access is granted on exact match.
This article focuses on the most common usages which are easy to enable.
Granting permissions to users
Permissions granted are stored on the party asset (person.account.) of a logged in user.
Each permission is realized as an asset of type module.oc.permission-group..
The party asset must be enriched by featuregroup censhare:module.oc.permissions.granted with inner features censhare:module.oc.permission.group-ref referring to the granted permission's asset.
The permission assets provided by the party asset are compared to permissions protecting an object.
If the party asset's offered permissions and the protecting permissons find at least one match the access is granted.
Each protecting permission can be imagined as a locked door - not as a lock on a single door.
Using the Online Portal user assets can be granted permissions on registration by configuration.
<user>
<permissiongroups>
<group-ref>acme:online-group-basic</group-ref><!-- use resource-key -->
</permissiongroups>
</user>(This describes the current proposed realization, previous implementations are still supported though details slightly differ.)
Restricting access to content assets
The term 'content asset' is used as there are exceptions to permission checks on assets. For some kinds of assets -most of them for technical usage (e.g. assets required for satellite operation)- the permission check is not applied.
Permissions on this level...
- restrict access on satellite's database level: content assets are filtered by the database and not available in user context without permission
- protect assets by adding features censhare:module.oc.permission.group-ref on content asset
- are activated in OC Configuration
<!-- Check user permissions on widgets -->
<component-delegate apply-permissions="true"/>
<!-- Check user permissions on asset of StorageItems -->
<storageitem-requesthandler check-permissions="true"/>
<!-- Check user permissions on images -->
<image-requesthandler apply-permission-filter="true"/>
<permissions>
<!-- Configure class implementing permission check for content assets -->
<lock class="com.censhare.oc.system.site.impl.StandardAssetLock"/>
<!-- Configure class implementing permission check for storage items -->
<lock class="com.censhare.oc.system.site.impl.StandardStorageItemLock"/>
<!-- Configure class implementing provider for permissions granted -->
<keyring class="com.censhare.oc.system.site.impl.StandardPartyAssetKeyring"/>
</permissions>Restricting navigation
Cutting back the navigation tree for users lacking required permissions needs some distinction.
Depending on the 'resolver' used to aquire content, different approaches are to use. A navigation item resolving to content can be protected by protecting that 'content asset'.
This has a drawback: insufficient permissions are answered as 'not found' / HTTP 404.
As the navigation tree is a technical resource, it's navigation items itself are not part of the 'content asset' permission check. To enable direct checks on navigation assets (module.oc.navigation.) it must be enabled in OC Configuration as an 'explizit' or 'detailed' permission check.
Provide implementating class
<permissions>
<!-- Configure class implementing permission check for navigation assets -->
<lock class="com.censhare.oc.system.site.impl.NavigationTreeNodeLock"/>
</permission>- protect navigation assets by special parent feature censhare:module.oc.permission.required.read.navigation with common inner features censhare:module.oc.permission.group-ref referring to the protecting permission asset.
- access must be restricted in implementation
- in skins use 'cs.permitted(NavState)'
'Complete' site requires registration and login
By use of the Online Portal this can be accomplished by configuration
- an interceptor redirecting anonymous users to the login page can be activated
<user>
<interceptors>
<interceptor key="com.censhare.standard.portal.interceptor.AuthorizationInterceptor" enabled="true"/>
</interceptors>
</user>As the whole site requires login, the interceptor will redirect all anonymous requests - but those related to login and registration.
Some navigation items require permissions
Again distingushed wether the navigation items require ...
... login: protect the navigation item, this way anonymous requests can be redirected to login
... additional permission: protect the content, rejected request are answered with 'not found'(HTTP 404)
- ensure those navigation items in navigation tree are protected - but those needed to register, login, reset passwort ...
Disable permission check for 'shared-link' access
The module 'share-link' allows to share files via web pages. It is available for the OnlinePortal.
The access to shared fils can be restricted by permissions (as described above) or public.
This configuration affects all shared-links, it can not be configured on an individual 'shared-link'.
Disabling the permission checking requires at least version 2.3.5 of the Online Portal.
Change in SiteConfiguration:
user/share-link@context-datastore-session=false (default:true - enable permission check)
Permission used by the 'Bouncer'
The bouncer is a special SessionManager. It is used to restrict access to private websites as development or staging instances.
It is configured in the OC Configuration and supports IP whitelisting.
Additional a specialized Bouncer configuration must be used.
For blocked requests a login screen is offered. The login accepts the same user logins (same credentials) as the website with a few additional requirements.
- A permission group is referred in bouncer configuration. A xpath expression with the assetId of that permission is used as datastore filter.
- The permission must be granted to each party asset allowed to pass the bouncer.
- Of course all related assets must have a proper output channel to be available in the satellite's database.
Note: In rare cases changes in Bouncer configuration do not affect satellites on the fly. If all other is checked and bouncer is still not cooperative please restart satellite