Session cookie, Http redirect binding and saml authnrequest – Google Search Appliance Authentication/Authorization for Enterprise SPI Guide User Manual
Page 7
![background image](/manuals/552785/7/background.png)
Google Search Appliance: Authentication/Authorization for Enterprise SPI Guide
7
•
Depending on the SAML Binding option:
Artifact Binding
•
The Identity Provider redirects the user back to the Security Manager providing a
SAMLArtifact token.
•
The Security Manager uses this SAMLArtifact and sends an ArtifactResolve request to the
identity provider’s Artifact Resolution URL.
•
The Identity Provider responds with a SAML
POST Binding
•
The Identity Provider creates an AuthnStatement Assertion for this user, digitally signs the
message and responds with an HTML form to auto-submit to the Security Manager. That is, the
HTML form returned by the IdP to the user’s browser contains an HTML form that is auto-
submitted (POST) to the Security Manager (which, in turn, eventually sends the identity to the
search appliance).
•
The Security Manager sends this identity enclosed in a SAML
which uses it for authorization.
Session Cookie
After a search user logs in using the Authentication SPI, the search appliance maintains a session for the
search user so that the user doesn’t have to reauthenticate to the Identity Provider on every search.
This session is maintained with a cookie named GSA_SESSION_ID, which contains the session ID. This
cookie is securely sent over HTTPS and is set for the search appliance’s hostname only.
Note: The Security Manager tags log entries with the session ID, in order to make it easier to follow a
particular session’s activity.
HTTP Redirect Binding and SAML AuthnRequest
When a search user performs a query (having no session cookie set), the search appliance
communicates with the IdP using HTTP 302 Redirects via the security manager.
Figure 2: Initial 302 redirect from the search appliance to the IdP via the REDIRECT Binding.
[1] User performs a secure search.