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).
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.
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:
Example:
GET /service-proxy/?command=auth&action=check
Example:
GET /service-proxy/?command=auth&action=login&username=John&password=SECRET
Example:
GET /service-proxy/?command=auth&action=ipauth
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]
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
Example:
GET /service-proxy/?command=auth&action=constraint
Example:
GET /service-proxy/?command=auth&action=logout
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
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.
Required in the login action, refers to the username specified in the identity store (Torus)
This plug-in is configured in service-proxy.properties or equivalent as follows:
plugins.authn = com.indexdata.serviceproxy.plugins.AuthNTorusPlugin
The address at which to find user identity information
Mandatory
Example:
authn.TORUS_URL = http://some-server/torus/identity/records/USERS/
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/
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
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
The Torus query to run with cookie values substituted.
Mandatory for cookie authentication
Example:
authn.COOKIE_QUERY = instId=${LibCode}
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
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
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}
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*")