About

Auth plugin checks credentials (IP adress or username/password) against an identity store (with a Torus API) and retrieves account information from that store (displayName etc).

Protocol

Assuming the plugin has been mapped to the auth chain (see configuration) it is invoked with:

  GET /service-proxy/?command=auth

If mapping is successful you will see an error indicating that mandatory request parameters (specific to the plugin) are missing.

Request parameters

action

Specifies the action performed by the plugin.

One or more authentication actions can be specified on one request as a comma separated list of actions. The actions will in that case be performed in the specified order and processing will stop after the first successful authentication action or at the end of the list.

Depending on the action(s) specified, additional parameters may be mandatory.

Possible values include:

  • check - checks authentication status on the server does not require additional parameters

    Example:

      GET /service-proxy/?command=auth&action=check
  • login - performs authentication using username/password Required parameters: username, password

    Example:

      GET /service-proxy/?command=auth&action=login&username=John&password=SECRET
  • ipauth - performs IP authentication does not require additional parameters

    Example:

      GET /service-proxy/?command=auth&action=ipauth
  • referrer - performs authentication by "HTTP Referer".

    If the request comes to SP directly from the referrer, no further parameters are needed.

    However, in some scenarios the user would click a link on a remote site, which leads to an MK2 UI (for example), which will in turn make the request to the Service Proxy. In this case the intended referrer is the remote site but the referrer that SP sees will be that of the MK2 UI. In this scenario an MK2 UI forwards the referrer that the UI sees, using the parameter forwardReferrer, and Service Proxy will then authenticate using that value instead, while at the same time requiring that the referrer that SP sees (the address of the UI), is on the same host as SP itself.

    Example:

      GET /service-proxy/?command=auth&action=referrer&forwardReferrer=[some URI, presumably picked from a Referer header]
  • cookie - performs authentication by cookie values.

    The Torus query to run with the cookie values must be configured in service-proxy.properties (see configuration section below)

    Example:

      GET /service-proxy/?command=auth&action=cookie
  • constraint - performs authentication by running a pre-configured filter query (constraint) on the list of identities. At least one of the specific or general constraints has to be specified (see below).

    Example:

      GET /service-proxy/?command=auth&action=constraint
  • logout - remove authentication (both u/p and IP-based)

    Example:

      GET /service-proxy/?command=auth&action=logout
  • perconfig - performs authentication according to a sequence of action configured in service-proxy.properties or equivalent (see configuration section below).

    The UI can thus use 'perconfig' rather than repeat the same authentication sequence wherever authentication is needed. The UI should still explicitly provide the desired action, of course, when that differs from the default sequence - for instance to request 'auth=logout'.

    Example:

      GET /service-proxy/?command=auth&action=perconfig

identity

Optional parameter for the check action. If specified, check action will not only confirm that an authenticated session is established but will also validate if the session matches the provided identity ID.

username

Required in the login action, refers to the username specified in the identity store (Torus)

password

Required in the login action, refers to the password specified in the identity store (Torus)

forwardReferrer

Needed by the referrer action if the authentication request is sent through a UI (as opposed to directly to the Service Proxy).

Configuration

Registration

This plug-in is configured in service-proxy.properties or equivalent as follows:

  plugins.authn  = com.indexdata.serviceproxy.plugins.AuthNTorusPlugin

Chain mapping

Example:

  chains.auth = authn

Properties

TORUS_URL

The address at which to find user identity information

Mandatory

Example:

  authn.TORUS_URL = http://some-server/torus/identity/records/USERS/ 

MASTER_TORUS_URL

The address at which to find parent level information, i.e. attributes attached to a users library.

Optional

Example:

  authn.MASTER_TORUS_URL = http://some-server/torus/admin/records/admin/

ACTION_SEQUENCE

The sequence of authentication actions to perform when the client requests command=auth&action=perconfig.

Mandatory if the request contains action=perconfig, otherwise optional

Example:

  authn.ACTION_SEQUENCE = check,cookie,ipauth

REQUIRED_COOKIES

Used if the request contains 'action=cookie'.

Specifies the cookies that must be present for authentication to succeed.

Mandatory for cookie authentication.

Example:

  authn.REQUIRED_COOKIES = LibCode SomeSessionFlag  

COOKIE_QUERY

The Torus query to run with cookie values substituted.

Mandatory for cookie authentication

Example:

  authn.COOKIE_QUERY = instId=${LibCode}  

AGGRESSIVE_SESSION_INVALIDATION

Controls whether the 'logout' action is performed by completely invalidating the server-side session ('yes') or by removing user attributes only and keeping the session intact ('no'). While safest, some severs are known to cause problems with the aggressive invalidation.

Optional, default 'no'.

Example:

  authn.AGGRESSIVE_SESSION_INVALIDATION = yes

SESSION_TIMEOUT_MINUTES

The interval after which the HTTP session will time out if there has been no activity in form of requests from the client.

Optional

Example:

  authn.SESSION_TIMEOUT_MINUTES = 120 

GENERAL_CONSTRAINT

A constraint added (AND'ed) to any authentication request regardless of the authentication type used.

Optional

Example:

  authn.GENERAL_CONSTRAINT = someAccessRecordField=mytag 

For example, to only authenticate by Torus access records that have a field named 'vhost' with a value that matches the host name used in the request:

  authn.GENERAL_CONSTRAINT = vhost=${thisHost} 

SPECIFIC_CONSTRAINT

Used only by the authentication type 'constraint' and combined with the general constraint (if one is specified) to form the final authentication query.

Optional

Example:

Authenticate with identities where the ipRange is empty, missing or contains full IP range. This constraint would be subject to the general constaint above (AND hostName matches, if specified). Could also be extended to ensure that username or password has not been specified for the identity (NOT password "").

  authn.SPECIFIC_CONSTRAINT = (cql.allRecords = 1 NOT ipRanges <> "" OR ipRanges == "*0.0.0.0-255.255.255.255*")