Authentication is a two-step process. In step one, a user identifies himself, for example by means of a user name (login) and a password. In step two, the user's identity is checked.
In a computer program identities (i.e. identified persons) are usually associated with permissions. Authorization denotes the process a computer carries out to check whether a particular identity possesses a particular permission, for example the permission to read a particular file.
The authentication methods available in the Portal Manager can be extended by providing the filters that implement the desired authentication functionality. In the standard scope of supply the following mechanisms are included.
In CMS Fiona, the
AuthenticationFilter
supports the following mechanisms:
RemoteUser
that has already been set. This
makes it possible to use any method that has been placed in front of the
Portal Manager.The NTLMFilter determines a RemoteUser
via NTLM. Therefore,
when using Windows and the Internet Explorer (restrictions apply to Firefox),
the user needs to log-in only once to Windows. Subsequently, his log-in
information is also available in the Portal Manager.
The NTLMFilter enforces authentication. However, falling back to Basic Authentication can be enabled for authenticating users even if NTLM authentication fails.
Particular URLs and IP ranges can be exempted from authentication.
If no explicit log-in request is issued and the RemoteUser
has not been set, the request is anonymous. If an nanonymous user accesses a
protected file, the PermissionFilter
blocks the request. Instead
of the file, the HTTP response code "401 Unauthorized" is delivered to the
user. Typically, the servlet container redirects this response to an error
page that has been defined in the web.xml
configuration file.
In the delivery state of the Portal Manager, anonymous users cannot access
content because the NTLMFilter
enforces authentication. However,
by specifying an appropriate URL pattern in the web.xml
configuration file of the filter, particular sections of the website can be
exempted from authentication, making them available to anonymous users.
The delivery of textual as well as binary content can be restricted to particular user groups.
Access permissions are checked on the file level. Typically, a file either has no access restrictions (its content may be accessed by everyone), or user groups permitted to read the file have been defined (protected content). In the first case, the file is simply delivered. In the second case the Portal Manager checks whether reasons for delivering the file to the user exist. One such reason is that the user is a member of at least one user group permitted to read the file.
Alternatively, any number of additional checks can be configured. The scope of delivery includes the option to check access permissions on the basis of the IP address of the computer requesting a file.
The user groups permitted to read an exported file can be assigned to the
corresponding file in the editorial system in two ways: by means of the
Content Navigator or via the Tcl interface of the Content Management Server
(CM). The permission concerned is labelled Live server read
permission, its Tcl keyword is permissionLiveServerRead
.
The Portal Manager supports the following two mechanisms for suppressing hyperlinks that point to protected content.
The Template Engine can be configured to suppress links that point to
protected content. A link is suppressed by removing the href
attribute from the a
tag. To achieve this, every
href
attribute is embedded into Velocity code at export time. At
request time, this code checks the user's permission to access the link
target and removes the href
attribute if the check fails.
The advantage of this method is that it is safe and reliable. No links to protected files will ever be published, even if links to such files are placed into the content by, for example, the editorial staff.
However, the method has the following disadvantages:
Automatic link removal can be switched on and off in the
export.xml
file by means of the
export.convertNpspm.hideForbiddenLinks
configuration entry. It
is enabled by default.
By means of npspm
elements, layouters are given a means to
directly modify the HTML code with which, for example, link lists are
displayed, causing the relevant parts to be only visible if the user meets
particular criteria:
Files a user is not permitted to access should not show up in his search results. For this purpose, the user groups permitted to read a file are indexed together with the contents of the file. This makes it possible to add the required group-membership condition to the search query. Thus, documents containing the search words will be added to the search result only if no access restrictions apply, or if the user is a member of one of the given user groups.
The following sample configuration for the search portlet
(SearchPortlet
) implements such a query:
#macro (getPermissionQuery) #set($groups = "") #foreach ( $perm in $user.permissions) #if ("$!groups" != "") #set ($groups = "$groups , "$perm.trim()"" ) #else #set ($groups = ""$perm.trim()"") #end #end #if ("$!groups" != "") <#ANY>((($groups) <#IN> permissionLiveServerRead), ( "free" <#IN> noPermissionLiveServerRead)) #else <#YESNO>("free" <#IN>noPermissionLiveServerRead) #end #end ... <condition> <and> [Place your search query here] <vql-statement>#getPermissionQuery</vql-statement> </and> </condition> ...
From CMS Fiona, version 6.5, the Portal Manager also supports base queries in addition to the actual search queries. The base query is made prior to the actual search query. Its purpose is to reduce the number of documents to be searched. It simplifies the code considerably:
To the and
section of the base query the following is
added:
<or> <vql-statement> "free" <#IN>noPermissionLiveServerRead </vql-statement> #foreach ($group in $user.permissions) <vql-statement> "$group" <#IN>permissionLiveServerRead </vql-statement> #end </or>