Google Search Appliance Security - Manual (Page 32)

32
Trusted Application
(beta)
A very common use case is for the GSA to be deployed behind a portal to provide a search service. The
search UI is provided in the portal and users don’t interact with the appliance directly. A challenge in such
a use case is how to pass the user’s credential to GSA without asking the user to login. To achieve that,
the search page must simulate browser behavior when interacting with the appliance, obtain the user’s
credential from the existing portal session, and pass that on to the appliance. Because of the variety of
authentication protocols used by portal applications and how the end user credentials are handled, it
could be quite a challenge.
In order to make the integration easier for portal developers, the Google Search Appliance added a new
feature in 7.2:
Trusted Application . The concept is simple: portals use a pre-configured trusted user
account to establish the session with GSA using limited, but simple authentication protocols, and sends in
secure search requests using an end user’s username. It avoids the challenges mentioned earlier with
the following:
1. Simple authentication protocols are easy to handle. Basic Authentication and Cookie Cracking
are the two supported mechanisms.
2. Since only usernames are required, it solves the problem when user passwords are not available
in an established user session in the portal.
End user’s identities are sent in using the following two custom HTTP headers:
X_GSA_USER: header that holds the username
X_GSA_CREDENTIAL_GROUP: header that identifies the credential group of the end user.
Key considerations
1. All configured authentication mechanisms will be triggered when a secure search is performed.
This includes the mechanism configured for the Trusted Application.
2. You can use any development languages: Python, Java, C#.
3. The "trusted user" must be verified. Since GSA supports cookie cracking and Basic
Authentication, it means the performance will be affected by the back end content server. You
should avoid performing authentication as much as possible.
4. You can use the returned GSA session cookie from a call to GSA for subsequent calls.
5. Each search request must be accompanied by the end user name and credential group in order
to get results for the right user.
6. Group resolution will be triggered as part of the authentication process for the end user. If there is
any group resolution configured, the group resolution will be invoked. Since Group resolution also
has performance implications, you need to avoid group resolution for every single API call.
7. When the same end user is re-submitted with another search using the same and still valid GSA
session cookie, group resolution won’t be triggered again. When a different end user is sent in for
the first time even with the same GSA session cookie, group resolution is triggered for that user.