Authentication and Access Control

Definition of the Terms Used

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.

Authentication Methods

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.

AuthenticationFilter

In CMS Fiona, the AuthenticationFilter supports the following mechanisms:

  • Basic Authentication by means of a user name and a password.
  • Single-sign-on tickets, for example for SSO against an SAP Enterprise Portal.
  • Adopting a RemoteUser that has already been set. This makes it possible to use any method that has been placed in front of the Portal Manager.

Single Sign On via Windows' NTLM

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.

Handling anonymous users

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.

Preventing Delivery of Protected Content

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.

Hiding Links Pointing to Protected Content

The Portal Manager supports the following two mechanisms for suppressing hyperlinks that point to protected content.

Automatic Link Removal

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:

  • Only the link itself is removed. The linked text, for example the title of the protected document, as well as HTML code possibly used for formatting purposes (like a table cell in a menu) are kept.
  • It can be enabled and disabled globally only.
  • It slows down the delivery of the pages because additional Velocity code needs to be processed for every link.

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.

npspm Elements

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:

Excluding Protected Content from Search Results

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>