Google Search Appliance Security - Manual (Page 27)

27
Key considerations
If you want to achieve a silent authentication experience with your SSO system, consider the following
items:
●
A session cookie must not be restricted to the same user IP—some SSO systems support this
restriction as a security measure.
●
The GSA must be part of the same domain as the session cookie used by the SSO system. For
instance, if a cookie is using domain “foo.com”, the GSA must be configured as part of that
domain, for instance “gsa.foo.com”. This way the browser will send SSO cookie to the GSA. The
cookie and the GSA domain must be scoped properly and in synch.
●
The cookie cracking application should be a simple web application written in any programming
language supported by your web/application server, such as Java or .NET. The application sends
the username back to the search appliance via a custom HTTP header. For example:
X-Username: luis.sanchez
●
The cookie cracking application is usually deployed behind the SSO system. It means that it can
be installed behind the SSO web plug-in that authenticates the user and usually passes that
identity to trusted web applications in an HTTP header in a secure way.
●
It doesn’t have to be a standalone application. It can be an additional ASP, JSP or other dynamic
web page in an existing application that’s protected by the same login form.
●
The “cookie cracker” doesn’t really “crack a cookie”—it just means that after authentication, a
cookie is generated that indicates a valid user session. The username might be obtained in
various ways. For example, a commercial SSO system like SiteMinder uses HTTP_SM_USER
header to add the user ID.
●
If it’s not possible to use a web SSO plug-in in front of such a custom web application to facilitate
the deployment of this solution, you can use the SSO API to extract the user behind the cookie.
Never fake an SSO system in production that passes the user ID in a cookie in plain text as this is
a high security risk.
●
Take into account some SSO systems might be configurable to pass those credentials in a HTTP
header without the need of developing a web application.
Group resolution for early binding (ACL authorization)
A cookie cracker authentication response can also be augmented to contain group information for the
user being authenticated. The cookie cracking process would not change, the only change required would
be to the headers on the response, as they would now also contain group information for the user. All
groups resolved through the Cookie authentication mechanism will belong to the global namespace of the
credential group selected for the mechanism. If groups are required for the authenticated session, an X-
Groups HTTP header would also be added:
X-Groups: department_users, enterprise_users