Users typically log in directly to the client service when searching. To do this, one of the authentication methods, Kerberos, SAML, or CAS is used.
With trusted peer authentication, it is possible to send the user name used for the authorization check of the search results along with the query. In order to prevent a user from searching in the name of another user, the caller must provide proof that he or she can be trusted.
There are two ways to do this:
Trusted peer authentication can be used, for instance
In order for client services to be able to use trusted peer authentication, communication between client service and query service has to be secured using trusted peer authentication with certificates.
If certificates are used for the trust relationship between requester and service, the following conditions must be met:
Important: The CA certificate may only be used for the trust relationship. Each requester receives a client certificate signed with this CA certificate. This reduces the potential for improper use. For example, it is negligent to use the CA certificate that is used for SSL server certificates in the company, otherwise every SSL server certificate would be trusted.
The CA certificate must be available as a PEM file. The private key does not have to be included. For communication between client service and query service, a client certificate in PKCS #12 format and without password must be installed.
Only one CA certificate per installation can be used as a trusted peer certificate.
Under Certificate, select SSL and then select the client certificate (.pem) to be installed. Then upload the SSL certificate with “Upload.
Navigate to the tab “Client Services” and in the section “Trusted Peer Communication To Query Services” select the installed client certificate in the setting “Credential Certificate”. Also, enable the setting “Authentication Generates Trusted Peer Credentials”:
When authenticating with OAuth 2.0 bearer token, the OAuth server must be stored. Trusted peer authentication is only allowed for users who have been assigned a configured role. The individual configuration values are best obtained from your OAuth server administrator.
Description | |||||||||
Realm | The OAuth Realm to be used. See your OAuth server for details. | ||||||||
Resource | The OAuth resource to be used. Details can be found on your OAuth server (in some OAuth servers also called client). | ||||||||
SSL Security for Communication with Auth Server | Determines how the HTTPS connection to the Auth Server will be checked:
| ||||||||
Role Trusted for Identity Delegation | Only users assigned to this role are allowed to perform trusted peer authentication. |
The user name can be sent either as an HTTP header or in the request.
The user name is transmitted as HTTP header X-Auth-User.
Example of sending the user name as HTTP header:
X-Auth-User: max.mustermann
For api.v2 queries, the user name can be transmitted in the user_context.username property.
Example of sending the user name as part of an api.v2.search query:
{
"user_context": {
"user_name": "max.mustermann"
},
"properties": [
{
"formats": [
"HTML"
],
"name": "title"
}
],
"count": 5,
"query": {
"unparsed": "mindbreeze"
}
}
The setting “Identity Extraction Order” in the section “Trusted Peer Identity Extraction” determines how the user name can be sent. The following options are available:
Option | Description |
Header, Request | The user name is used, if it is set in the X-Auth-User HTTP header. If not, the user name from the query is used. |
Header | The user name in the X-Auth-User HTTP header is used. The request will not be considered. |
Request | The user name from the query is used. The X-Auth-User HTTP header will not be considered. |
Request, Header | If the user name is set in the query, it is used. If not, the user name from the X-Auth-user HTTP header is used. |
User groups can be transferred as HTTP header X-Auth-Groups. The user groups must be comma-separated and then HTML form encoded.
Example for sending user groups as HTTP header:
X-Auth-Groups: marketing%2Cauthors%2Cquality%20assurance
This results in the following user groups:
marketing
authors
quality assurance
With HTTP headers it is possible to add additional attributes to the user identity.
HTTP headers can be sent according to the following patterns:
X-Identity-Property-{{key}}: {{value}}
For example, the following headers
X-Identity-Property-mail: user@example.com
X-Identity-Property-color: light%20blue
create this properties:
"mail": "user@example.com"
"color": "light blue"
Note: The {{value}} must be HTML form encoded.
These attributes are internally linked to the user identity (Identity Property) and can then be used in other services.