always refers to the latest version of Sitevision

Add filter

Filters are used to obtain login information from the HTTP request. For example, it may be a question of retrieving parameters or values from a cookie.

This information will then be used by the modules to perform the login against, for example, a directory service via LDAP.

Form filter

This filter uses parameters to obtain usernames and passwords. Either via POST or GET, which means that the following address can be used to identify the user:



BASIC Authentication is based on the browser sending an HTTP header containing the username and password to the server.
By default, this filter should be standard because of web clients that can only handle this way of logging in, for example. Here you can read a more detailed description of how BASIC works.



CAS is open source software for single sign-on (SSO) for web applications. Instead of SiteVision managing the login, Here you can read more about CAS External link, opens in new window..


Detailed description of the configuration parameters External link, opens in new window.

Easy configuration

  • CAS login URL - must be specified (https://<cas-server>/cas/login)
  • CAS service URL or Client server name - must be specified, this is the address that must be used for the redirect after successful login.
  • CAS ticket validation URL - must be specified (https://<cas-server>/cas/serviceValidate)

Developers can create their own filters and use them in SiteVision. Further information about this can be found on page Custom JAAS modules (only available in English)


CAS is open source software for single sign-on (SSO) for web applications. Instead of SiteVision managing the login, Here you can read more about CAS External link, opens in new window..

CAS3 uses the SAML1.1 protocol to authenticate users. It includes support for "attributes release".


Detailed description of the configuration parameters External link, opens in new window.


  • Tolerance - Specify the amount of time difference/operation allowed between SiteVision and the CAS server.
  • CAS server login URL - Must be specified (https://<cas-server>/cas/login)
  • Renew ticket on login - Specify whether you want the CAS server to require new authentication even if the user already has a session with the CAS server
  • CAS server URL - The CAS server’s URL (https://<cas-server>/cas), must be specified
  • Client service URL - The URL to which the user will be redirected after approved authentication. This or the "Client's server name" must be specified.
  • Client server name - Specify the server name if you want the user to be redirected to the page that the user called, after passing authentication. This or the "Client's server URL" must be specified.
  • Ignore certificate - Specified, for example, in testing to avoid installing the CAS server's certificate in SiteVision because the communication between SiteVision and CAS server must occur with HTTPS.
  • Use SAML 1.1 - Specify whether to use the SAML 1.1 protocol for communication between SiteVision and CAS server. Otherwise CAS2.0 is used.
  • Populate shared password - (Not mandatory). Users who are authenticated via the CAS3 module are populated with this password in order for a possible integrated underlying system to be able to verify that the user has been logged in.
  • Auth-method attribute - The underlying protocol used for authentication, e.g. SAML.

Client address

The client address filter used to obtain the client’s IP address, which can then be used to assign read access rights based on IP addresses.

  1. Use X-Forward-For-Header- To identify the original IP address if you are going through a firewall.

Configurable filter

The configurable filter can be used for example if you have your own security solution for which there is no ready filter. Here you can choose how the username, password, and authtype are retrieved from the HTTP request.

The following types are possible:

  • none
  • header
  • parameter
  • cookie
  • constant
Konfigurerbart filter


Specialised filter for managing headers that come from the security solution MobilityGuard External link, opens in new window..

It does not matter in what order this filter comes in the filter chain.



Specialised filter for managing cookies from the security solution PortWise.

  1. Use Portwise cookie for client address - Tick this box to send the IP address from the client address to SiteVision instead of sending the Portwise IP address. If you use this you can, for example, use IP logins, which logs the IP address that users come from.


OpenId is a standard that enables a federated login *. Often used to provide users with single log in to a community or blog. Used by Google, Facebook and Yahoo, among others. Read more at External link, opens in new window.


* Federated login = A user can log in to an organisation/service with an identity from another organisation or identity publisher.

Swedish e-identity

In SiteVision there is a connection to Swedish e-identity’s "cloud-based" login services. When the login module in SiteVision is used, the Swedish e-identity login service is called up, which performs the user login process according to the rules defined. Read more about Swedish e-identity.

Swedish e-identity


Microsoft has made a protocol SPNEGO that allows automatic login over Kerberos.

  1. Debug -Enable to facilitate troubleshooting.
  2. Allowed addresses - Which IP addresses will receive automatic login. If you have multiple IP address ranges, add them with a comma between each range.
  3. Service principal - SPN, the service account used.
  4. KDC - Stands for Key Distribution Center, usually domain controller.
  5. Realm - Must match domain name of website
  6. User-Agent filter (regexp) - Allows you to set a filter if, for example, you want to require a particular browser to be used. Type *firefox.*
  7. Service password - Password of the AD account specified for Kerberos.
  8. Domain - Domain name of the website.

 Set AD correctly and read about Kerberos before making settings here.

Read more about logging in with Kerberos from Apache Tomcat on their website Windows Authentication How-To External link, opens in new window..


This is outdated technology. We recommend SAML instead.

NTLM is a proprietary login method used primarily by Internet Explorer. This login method enables automatic login to SiteVision.

There are some limitations:

  • NTLM does not work if there is a web proxy between the user and the SiteVision server
  • It only works if "Integrated Windows authentication" is enabled in Internet Explorer.
  • The address used to reach the SiteVision server must be listed in the "Local intranet" zone in Internet Explorer. Otherwise, a Windows login window opens where you have to log in manually.
  • Caching of passwords in a local profile causes the password change in some environments not to be applied through the NTLM login.
  • Users who log in this way must be in the first directory service if there are multiple directory services.
  1. Use domain name for directory lookup - Tick this if you want to use the domain name.
  2. CIFS server SiteVision authenticates the user against this server via the CIFS protocol. Typically, this is the same server on which the directory service resides.
  3. Allowed addresses- Here you specify the IP addresses to be affected by this login method. The image above shows an example of how an IP range is specified correctly. If you have multiple IP ranges, they should be separated by commas. (NOTE! no spaces anywhere). If the field is left empty, all IP addresses are counted as allowed.

More information about NTLM

Secure cookie

The filter handles redirects for automatic login via the secure cookie (see secure cookie module)

This filter must be configured if the Secure cookie login is to work.

Secure cookie

Social Authentication

Social Auth


SAML stands for Security Assertion Markup Language and is an XML-based open standard for exchanging authentications and permissions.

SAML is a federated login method that organises your own login against AD without the need for direct contact with AD. Add an SAML filter to make settings:

To help you create an SAML filter, you can use the SAML configuration guide.

SAML 2 - del 1
  1. ConsumerService(Binding): HTTP-POST
  2. Default error message- If you want to have your own error message instead of the system error message.
  3. Login address IDP - Fill this in if you use IDP-initiated login, the user is then redirected to the IDP before logging into SiteVision.
  4. Assurance level: 0
  5. Domain name: In order to have several different SAML configurations on the same site, you need to fill in the domain name to associate the configuration with a domain name.
  6. Certificate for Keystore: Browse to the KeyStore file that you uploaded in the file archive in SiteVision. The Keystore file is located in the zip file (which is downloaded via <address>/SAML/download.
  7. Add NameID policy to the authentication request - If the IDP requires NameID policy, you need to tick this box for example Apache Shibboleth
  8. Ignore certificate - If self-signed certificates are OK, check this box.
  9. Certificate password: Keystore password (generated by Sitevision during SAML configuration)
  10. Use SHA256 for certificate - Tick this to use SHA 256 encryption of the Keystore in the SAML ticket. If you do not tick this, the older SHA 1 method is used for encryption.
  11. Address of error page - If you want to have your own error page instead of the error message.
  12. Provider-metadata - Paste the content from the SP metadata file here.
  13. IDP-metadata (URL) - If you would rather specify an address for IDP metadata. The advantage of this is that the information is updated every night at 05.00.
  14. IDP-metadata: If you do not use an address for the IDP metadata, paste the content from the IDP metadata file here.

This function requires you to have a license for SAML.

SAML 2 should be at the bottom of the filter list, because the filters are read from bottom to top.

The page published:

Did the information help you?