Secure search provides the ability to grant/deny access to search results based on some kind of authentication and authorization policy. Its not always immediately clear why results are being included or excluded.
There are two essential components to troubleshooting secure search:
- Authentication: Secure searches work by first determining, in some fashion, WHO the user executing searches may be. Authentication can be done via a variety of mechanisms: Cookies, LDAP, SAML, and Kerberos are some of the available options.
- Authorization: Once identity has been established, the GSA can process search results for a user, and determine which results should be included and excluded from their search results. The GSA supports fast authorization mechanisms such as storing security ACLs in the index (also known as early binding), and slower mechanisms such as head requests where the GSA individually tests search result URLs to see if the user has access.
To diagnose secure search, you must first confirm the authentication of a search user. If a user is unauthenticated, secure URLs will not be authorized.
The GSA logs information about authentication in the security manager log. This can be retrieved from the admin console via the Serving > Universal Login > SecMgr Log button in the admin console.
Authorization logs are stored separately from authentication logs. They can be found via the Serving > Access Control > Authorization Log. Within this log, you can see the decisions made about individual URLs for a given search and user.
We strongly recommend you read an overview of secure search in our normal documentation: Overview of Secure Search.
If you're still in the design stages of your GSA deployment, our Notes from the Field guides can be useful as well. Find them here: Notes from the Field