Configuring Security Manager in 6.4


Starting with 6.4, user authentication is performed by Security Manager. Security Manager can be configured from Universal Login page (Serving > Universal Login) on the GSA. Legacy authentication has been disabled and hence customers using Legacy authentication should migrate to security manager and configure their respective authentication mechanisms (Serving >Universal Login Auth Mechanisms) for serving secure results.


SAML - Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data.

SPI - Service Provider Interfaces enable a Google Search Appliance to communicate with an existing access control infrastructure.

GSA - Google Search Appliance.

LDAP - Lightweight Directory Access Protocol.

IIS - Internet Information Server

Security Manager - Unified Authentication method used by the GSA for Cookie, Http, Kerberos, Saml and Connector based authentication mechanisms.

Legacy Authentication - Authentication method used by the GSA before Security Manager was implemented.

Conventions Used

Any particular menu/section referenced in the document, unless specified explicity refers to the Admin Console of the GSA. The admin console of the GSA can be accessed using port 8000 (http://GSA_NAME:8000). For example (Serving > Universal Login) would mean click on Serving menu, and then click on Universal Login page in the Admin Console.

Cookie Based:

No specific change is required, configure security manager for Cookie Based Authentication.

HTTP Based (Basic/NTLM):

This section is applicable if you are migrating HTTP/SMB based secure contents.

a. If you have configured http based (Basic/NTLM) secure serving (by setting up rules in Crawl and Index > Crawler access) and do not have LDAP configured, you will need to setup the security manager's HTTP-Based rules (Serving > Universal Login Auth Mechanisms > HTTP Based).

The administrator can configure HTTP-based basic/NTLM authentication in two ways:

1. Manually add a Sample Url which is protected by the HTTP authentication. Credential group is optional, leave the group as default if you have not configured one. Enable NTLM check box for NTLM based authentications.

2. Alternatively, the whole setup can be automated by importing the rules from crawler access by selecting "Import Mechanisms from Crawler Access" option in HTTP Based authentication configuration page (Serving > Universal Login Auth Mechanisms > HTTP Based). Edit the rules you would like to be included and save them.

b. If you have contents protected by SMB, change the Serving > Access Control > Challenge users for Basic authentication to "Always" to get prompted for secure results. By default "Automatic- only prompt if needed" is selected.

Kerberos Based:

No specific change is required, configure security manager for Kerberos Based Authentication.

SAML Bridge:

This section is applicable if you are migrating to 6.4 with SAML Bridge configured (assuming SAML Bridge was working without any issues before migration).


a. Stop IIS where SAML bridge is configured. Backup the old SAML bridge directory which is configured in IIS.

b. Ensure the latest SAML Bridge binary is installed.

c. Ensure SAML Bridge (Serving > Universal Login Auth Mechanisms > SAML) has been properly configured with Security Manager since Legacy authentication has been disabled starting from 6.4.

d. Ensure the new web.config for the SAML bridge has the correct <artifact_consumer/> and <idp_entity_id/> configured (web_config values are case-sensitive).

e. Ensure Resolve.aspx and Authz.aspx (part of SAML bridge binaries) have Anonymous Authentication enabled while all other files in the SAML bridge directory have Integrated Windows Authentication enabled.

f. If you have a custom SAML Bridge please use the following SPI link to incorporate the necessary changes (SPI Documentation).

Troubleshooting Checklist:

After update, if no secure results are returned then:

1. Check the prerequisites:

Ensure Pre-requisites for SAML Bridge have been properly implemented.

2. Check whether Authentication succeeded:

a. If the GSA does not return secure results, capture the http headers from the browser when performing a secure search. Verify the http headers to ensure Kerberos is used as an authentication mechanism against the SAML Bridge(browser and your content server must be enabled to perform Kerberos).

b. Check the ac.log in SAML bridge folder, here is a snippet of log where authentication was successful (for user user1@ESODOMAIN):

7/30/2010 1:59:36 PM, Page_Load: Login Request is: /saml/Login.aspx?SAMLRequest=fZJBT%2BMwEIXv%2FArL9zSO26 .............St1QQVEAmQ%3D
7/30/2010 1:59:36 PM, Page_Load: before Login::entering pageload 7/30/2010 1:59:36 PM, getAuthn: Authentication provider is SAMLServices.Wia.AuthImpl 7/30/2010 1:59:36 PM, ExtractAuthNRequestId: samlRequest = fZJBT+MwEIXv/ArL9zSO26......./P0TxAQ== 
7/30/2010 1:59:36 PM, ExtractAuthNRequestId: samlRequest decoded =  <samlp:AuthnRequest AssertionConsumerServiceURL="" Destination="" ID="_212fe1ac6db056d0eae5068fc959ab51" IsPassive="false" IssueInstant="2010-07-30T20:59:36.644Z" ProviderName="Google Security Manager" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
7/30/2010 1:59:36 PM, Page_Load: Extracted AuthNRequestId is :_212fe1ac6db056d0eae5068fc959ab51
7/30/2010 1:59:36 PM, Page_Load: The user is: user1@ESODOMAIN
7/30/2010 1:59:36 PM, Page_Load: before Login::redirect
7/30/2010 1:59:36 PM, Page_Load:  to:

c. If the ac.log does not have any information on why the authentication failed, ensure login.aspx has Integrated Windows Authentication enabled in IIS.

3. Check whether Authorization succeeded:

Check the authorizations logs (Serving > Access control > Authz Log) after a secure search is performed. If the secure documents have decision of 'Deny' for documents which the user has authorization access, then the most likely cause is authentication method for Authz.aspx does not have Anonymous Authentication enabled. Enable Anonymous Authentication in IIS server. Make sure to clear the cache (Serving > Access control> clear caches) before performing a search so that authorization results are not cached.

4. Verify Issuer/Idp_entity_id is properly configured:

The SAML Bridge binary extracts the Idp_entity_id from the web.config file. So if the Issuer/Idp_entity_id does not match the value configured in (Serving > Universal Login Auth Mechanisms > SAML > IDP Entity ID) the following are the possible causes:

a. The web.config file in SAML Bridge installation was not configured with Idp_entity_id. By default when Idp_entity_id is not defined in web.config file, SAML Bridge uses the host name where it is installed as the Idp_entity_id. To fix this add the following line with the correct Idp_entity_id to web.config:

<add key="idp_entity_id" value="(value)"/> 

b. Even after configuring idp_entity_id in web.config, if Idp_entity_id does not match the value configured in Admin Console, then check whether you have the latest SAML binary installed.

A sample snippet of improperly set Idp_entity_id:

[.saml.client.ResponseParser.warn] sid dec0abe605d6e99b11f6131ca7e44766: Issuer value: ESOTEST is not equals to expected value: myauthn 

The above line was extracted from Security Manager logs (Serving > Universal Login> SecMgr Log). 'ESOTEST' is the value set in web.config or the hostname if using an older saml-bridge installation. myauthn is the value of Idp_entity_id set in admin console (Serving > Universal Login Auth Mechanisms > SAML > IDP Entity ID).

5. 400 Bad request is returned:

When a 400 http error code is returned by the browser for a secure search, the most likely cause is web.config does not have the correct artifact_consumer value. Please verify and ensure the artifact_consumer value is set as follows:



a. If you have connector based secure contents and if your connector manager does not have multiple connector instances, configure security manager, from Serving > Universal Login Auth Mechanisms > Connectors. Note that if your connector manager has multiple connector instances, then you will be unable to save a rule on that page. Clicking save will not preserve the new rule in that case. You can use this approach with multiple connector instances by configuring each connector instance on a separate connector manager installation. However, this requires configuring a separate credential group (Serving > Universal Login) for each connector instance, which would require users to enter credentials for each connector instance separately.

b. If your connector manager has multiple connector instances, you have two choices:

1. Switch to another security manager authentication mechanism that provides a primary verified identity. Options include Cookie Based with a cookie cracker, HTTP Based (HTTP Basic or NTLM), Kerberos, SAML, or LDAP. The use of LDAP requires 6.2.0.G.22 or later, due to bug 2799831 ("Secure serving using LDAP or Client certificates will fail if security manager is not configured, it will not affect customers if they have never configured Security Manager and never plan to use it").

2. Re-enable the legacy authentication mechanisms and continue using the legacy connector authentication (HTTP Basic prompt). This approach requires disabling the security manager, so it will not work if you are using other security manager authentication mechanisms for separate secure content. You can re-enable the legacy authentication mechanisms by manually entering the following URL in the admin console:


where "mygsa" is the hostname or IP address of your GSA. On that page, uncheck the "Disable Legacy Authentication System?" checkbox and click Save Settings. Then, from the Serving > Universal Login page, uncheck the "Enable Security Manager" checkbox and make sure that the "Disable Legacy Authentication" checkbox is also not checked, and click Save Settings.

Was this helpful?
How can we improve it?