Sure, you can handle it. But should you?
Let our experts manage the tech maintenance while you focus on your business.
Let our experts manage the tech maintenance while you focus on your business.
Configuration
GSA Late Binding Authentication
Copyright ©
Mindbreeze GmbH, A-4020 Linz, 2024.
All rights reserved. All hardware and software names are brand names and/or trademarks of their respective manufacturers.
These documents are strictly confidential. The submission and presentation of these documents does not confer any rights to our software, our services and service outcomes or other protected rights. The dissemination, publication or reproduction hereof is prohibited.
For ease of readability, gender differentiation has been waived. Corresponding terms and definitions apply within the meaning and intent of the equal treatment principle for both sexes.
Introduction
The GSA Late Binding Authentication service can be used in web indexing use cases where authorization can’t rely on access control lists or a search-time access check of the results is required. Additional requirement is that the access checking requests (head or get requests) should be authenticated with session cookies.
It is not recommended to use this method if authorization based on ACLs exclusively is sufficient. If possible, one should use it in conjunction with ACL check (only if the ACLs allow access) as an additional authorization method. The reason is, that the search-time access check can significantly impact search performance.
Configuration
Late Binding Authorization Service
The Late Binding Authorization Service can be configured as a Mindbreeze InSpire Launched Service using the Mindbreeze InSpire Management Center. Navigate to the “Indices” Tab and add a launched service of type “GSALateBindingAuthorization”.
You can configure the following settings for the server:
Bind port | Port that is used for receiving authorization requests. |
Cookie header property | The authorization service receives a user identity data structure within the authorization request. This property is the name of the identity property that contains the original session cookie header of the search request. |
The access check rules for given URL patterns can be defined in form of “Authorizers”.
IMPORTANT: the authorization result for a given documents is delivered by the first authorizer with a matching URL pattern.
An authorizer can have the following attributes:
URL Pattern | Regular expression matching the URL (key) of the authorizable document. If matches, this authorizer will be used for access check. The pattern has to fully match the URL input. |
Denied Status Code Pattern | If set, a HTTP request is performed on the URL of the authorizable document with the search user’s original session cookies. The configured regular expression (f. ex. “401|403” or “301|40.*”) is checked against the status code of the HTTP response. If matches, the user is denied access on the document. The pattern has to fully match the status code. |
Denied Content Pattern | If set, a HTTP Get request is performed on the URL of the authorizable document with the search user’s original session cookies. Note: if only “Denied Status Code Pattern” is set in an authorizer without a “Denied Content Pattern”, only HTTP HEAD requests are used for authorization check. The configured regular expression is checked against the content of the HTTP response. If the regular expression matches a substring of the content, the user is denied access on the document. |
Check Content Pattern for Matching Media Type | This regular expression pattern is set per default to “text/.*”. The role of this setting is to restrict matching the configured “Denied Content Pattern” to responses with certain Content-Type header. In this way one can prevent text matching on content for responses in binary or non-textual formats. If not set, the “Denied Content Pattern” is applied on all responses. |
Data Source Configuration
For using the configured GSA Late Binding Authorization Service for access check in a given Data Source (for example Web) the service should be selected as “Authorization Service” in the configuration of the given data source.
If ACLs are used on the index a “Caching Principal Resolution Service” has to be selected as well:
Index Configuration
To improve the performance, it is advised to set the following index configuration options:
- Approved Hits Reauthorize: Token Cache
- Initial Precheck Bulk Size: 1
- Maximum Precheck Bulk Size: 1
Cookie Header Preserver Session Authentication Plugin
The role of this plugin is to allow sending the original user session cookies with the authorization requests to the GSA Late Binding Authorization service.
The plugin should be configured as a SessionAuthenticationService on the Client Service that will be used for searching.
For the configuration navigate to the “Client Services” Tab of the Mindbreeze InSpire Management Center and in the configuration of the selected Client Service, add a Session Authentication Plugin of type “CookieHeaderPreserverSessionAuthenticationService”.
The following settings can be configured for the plugin:
Cookie header property | The name of the property in the generated identity data. Default is “cookieheader”. This must be configured on the same value as the “Cookie header property” of the GSA Late Binding Authorization service. |
Username Source | Can be set to “Username”, “Header” or “Anonymous”. Username: a user identity is created having the name set to the value configured in the “Username” setting. Header: the name of the created user identity is set to the value of the “X-Auth-User” HTTP request header. |
Username | If “Username Source” is configured as “Username”, the name of the generated identity is set to this value. |
Has Group Principals | If active, the comma separated list of groups set in the “X-Auth-Groups” HTTP request header is parsed and the group names are added as additional principal names to the generated identity. |