Authentication

CMS Fiona supports three methods for authenticating users of the editorial system:

  1. Log-in form (default setting)
  2. Basic Authentication
  3. Single sign-on via Kerberos

1. Log-in form

For the standard setting, no extra configuration is required.

2. Basic Authentication

For this method, the configuration at CMS_INSTANCE_DIR/webapps/GUI/WEB-INF/acegi.xml needs to be adapted.

Please deactivate the standard section (Formbased Authentication) and activate the Basic Authentication section in the acegiFilterChain instead. Afterwards, please deploy the GUI web application.

3. Single sign-on (SSO) via Kerberos

If you would like to use single sign-on via Kerberos, please also adapt the configuration at CMS_INSTANCE_DIR/webapps/GUI/WEB-INF/acegi.xml in order to use SSO authentication. Activate the Remote User section in the acegiFilterChain. Here too, please deactivate the standard section (Formbased Authentication). CMS Fiona will then try to retrieve the credentials from the REMOTE_USER server variable. After authenticating via Kerberos (using mod_auth_kerb) completed successfully, Apache saves the login to this variable.

If mod_proxy is used with Apache to forward requests to the Trifork server running the Fiona GUI, Apache does not hand down the REMOTE_USER variable to the Trifork server. Therefore, if mod_proxy is used, it is additionally required to extend the Apache and Fiona GUI web application configuration.

Apache (only if mod_proxy is used)

For passing on the REMOTE_USER, an additional header is required with Apache. This header receives the value of the variable, enabling the GUI web application to retrieve it.

In the example configuration below (lower part), the REMOTE_USER is saved to the NPS_REMOTE_USER header variable. The header may be given any other valid name, if desired.

<VirtualHost *:80>
  ...
  <Proxy *>
    AddDefaultCharset Off
    Order deny,allow
    Allow from all
    AuthType Kerberos
    AuthName "Kerberos Login"
    KrbServiceName HTTP
    KrbAuthRealms THE.DOMAIN.COM
    Krb5KeyTab /etc/apache2/my.keytab
    KrbMethodK5Passwd On
    KrbMethodNegotiate On
    require valid-user
  </Proxy>

  ProxyPass /default/NPS http://localhost:8080/default/NPS
  ProxyPassReverse /default/NPS http://localhost:8080/default/NPS

  RewriteEngine On
  RewriteCond %{LA-U:REMOTE_USER} (.+)
  RewriteRule . - [E=RU:%1,NS]
  RequestHeader set NPS_REMOTE_USER %{RU}e
  RequestHeader unset Authorization
  ...
</VirtualHost>

GUI web application (only if mod_proxy is used)

Starting at version 7, CMS Fiona includes a filter called RemoteUserInjectingFilter. Using this filter, the REMOTE_USER can be retrieved from a request's header variable defined for Apache before. This way, the Fiona GUI is able to determine and process the log-in credentials even if mod_proxy is used.

The RemoteUserInjectingFilter can be activated in the CMS_INSTANCE_DIR/webapps/GUI/WEB-INF/web.xml file. Please make sure that the filter configuration refers to the header Apache inserts into the requests, NPS_REMOTE_USER in this example:

<filter>
  <filter-name>RemoteUserInjectingFilter</filter-name>
  <filter-class>com.infopark.libs.http.RemoteUserFromHeaderInjectingFilter</filter-class>
  <init-param>
    <param-name>header</param-name>
    <!-- Attention: A client must not be able to provide this header's value -->
    <param-value>NPS_REMOTE_USER</param-value>
  </init-param>
  <init-param>
    <param-name>standardRemoteUserConsideration</param-name>
    <!-- possible values (default: ignore):
      - prefer:   REMOTE_USER is used, fallback to header value
      - fallback: header value is used, fallback to REMOTE_USER
      - ignore:   header value is used only
    -->
    <param-value>prefer</param-value>
  </init-param>
</filter>
...
...
<filter-mapping>
  <filter-name>RemoteUserInjectingFilter</filter-name>
  <url-pattern>/*</url-pattern>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>ERROR</dispatcher>
</filter-mapping>
Security notes
  1. The application server ports (8080, 8443) must under no circumstances be reachable "from outside". If this were the case, someone having knowledge of the header name could adopt the identity of any user by sending a request to the application server, including in this request the header name whose value has been set to the desired user.
  2. All (further) paths giving access to the application server (read: Apache) need to ensure that they have full control of the header value, letting no value pass "from outside".
General notes on using AD

ADS ignores upper and lower case with logins, the CMS, however, doesn't. To guard against conflicts arising from this, AD servers should be equipped with the LowercaseTransformer. This is a loginTransformer that lets you lower the case of logins before they are passed to the CMS. By default, the LowercaseTransformer is not in use. To utilize it, please edit the CMS_INSTANCE_DIR/webapps/GUI/WEB-INF/acegi.xml GUI file. Remove the comment characters preceding the loginTransformer specification in the abstractAuthenticationProvider bean:

<bean id="abstractAuthenticationProvider" abstract="true">
  <property name="loginTransformer">
    <bean class="com.infopark.libs.util.LowercaseTransformer"/>
  </property>
</bean> 

Finally, redeploy the GUI for the changes to become effective.