Owner's manual

ManualsBrandsGoogle ManualsSoftwareSearch Appliance Authentication/Authorization for Enterprise SPI Guide

Google Search Appliance

Authentication/Authorization for Enterprise SPI Guide

Google Search Appliance software version 6.8 and later

October 2010

Summary of content (33 pages)

PAGE 1
Google Search Appliance Authentication/Authorization for Enterprise SPI Guide Google Search Appliance software version 6.
PAGE 2
Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 www.google.com October 2010 © Copyright 2012 Google, Inc. All rights reserved. Google and the Google logo are registered trademarks or service marks of Google, Inc. All other trademarks are the property of their respective owners. Use of any Google solution is governed by the license agreement included in your original contract.
PAGE 3
Contents Authentication/Authorization for Enterprise SPI Guide ...................................................
PAGE 4
Authentication/Authorization for Enterprise SPI Guide The SAML Authentication and Authorization Service Provider Interfaces (SPIs) enable a Google Search Appliance to communicate with an existing access control infrastructure via standard Security Assertion Markup Language (SAML) messages. The Authentication and Authorization SPIs are also required to support Windows Integrated Authentication with the Google SAML Bridge for Windows.
PAGE 5
• SAML 2.0: An XML-based standard whose primary use case is inter-domain single sign-on. [http:// www.oasis-open.org/specs/#samlv2.0] • SOAP 1.1: The Simple Object Access Protocol is an XML-based protocol for exchanging information over the Internet. [http://www.w3.org/TR/2003/REC-soap12-part1- 20030624/] • GSA Universal Login with SPI: The GSA’s security-manager providing universal login forms/SPI.
PAGE 6
Authentication Purpose of the Google Search Authentication SPI When implemented, the Authentication SPI allows search users to authenticate to the search appliance. It is designed to allow customers to integrate the search appliance into an existing access control infrastructure. Instead of authenticating search users itself, the search appliance redirects the user to an Identity Provider (IdP), a customer-implemented server, where the actual authentication takes place.
PAGE 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 element to the Security Manager. The in the response contains the identity of the search user.
PAGE 8
Assume no prior search appliance session or SSO cookie has been granted. http://gsa.yourdomain.com/search?q=secure&btnG=Google Search&access=s&client=default_frontend&output=xml_no_dtd&proxystylesheet=defaul t_frontend&sort=date: D:L:d1&entqr=3&oe=UTF-8&ie=UTF-8&ud=1&site=default_collection GET /search?q=secure&btnG=Google +Search&access=a&client=default_frontend&output=xml_no_dtd&proxystylesheet=defau lt_frontend&sort=date %3AD%3AL%3Ad1&entqr=3&oe=UTF-8&ie=UTF-8&ud=1&site=default_collection HTTP/1.
PAGE 9
GET /security-manager/samlauthn? SAMLRequest=fZJNT8MwDEDvSPyHKPeuHxIMRWvRYJrYBKhAQYJb1rltRuKUOB3w7+k6EHCAq2P7PduZ nL4ZzbbgSFlMeTyKOAMs7 VphnfL7Yh6c8NPs8GBC0uhWTDvf4C28dECe9ZVIYnhIeedQWEmKBEoDJHwp7qZXlyIZRaJ11tvSas4Ws 5SvVlJvTLOpn7G2gPhsjT IV6o2tNK4aJSsjy3bTcPbwpZXstBZEHSyQvETfh6I4CqJxEB8XUSKiIxHFT5zln6QzhfsJ/ tNa7ZNIXBRFHkydV5Us/dBkq9bgrvu KlNfW1hpGpTU7hVwSqW0frqQm4NmwFzGouR8L+R/ c94CeZpFnjfetCMNvSAjowbVOEYQ1ybBIgutxcnZzk+SPy7tlMQl/ELPPs +xMF7PcalW+s6nW9vXcgfS9pncdcDa3zkj/t1Q8ioeIWgfVkCo6pBZKVSlYcxZme+rv+/e
PAGE 10
HTTP/1.x 302 Moved Temporarily Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=DBF3B9029E3F442CDB78FABDFD4CFDE6; Path=/security-manager Date: Fri, 16 Jul 2010 02:05:02 GMT Cache-Control: no-cache, no-store Pragma: no-cache Location: http://idp.yourdomain.
PAGE 11
The SAMLRequest is first DEFLATE-compressed, then Base 64 encoded, then URL encoded. It must be decoded and parsed if using the security manager. The following lines of code in python and c# demonstrate the conversion: python: def dec_b64_inflate(bstring): d_data = base64.b64decode(bstring) return zlib.decompress(d_data, -15) C#: public string Decompress(byte[] input) { using (MemoryStream inputStream = new MemoryStream(input)) { using (DeflateStream gzip = new DeflateStream(inputStream, CompressionMode.
PAGE 12
After Authentication, the IdP can either use Artifact Binding or POST Binding depending on what mechanism its setup for. HTTP Artifact Binding [6a] With Artifact Binding, the IdP generates a random-looking string called an artifact, then associates it with the response from the authentication step. This association is used later to look up the response.
PAGE 13
GET /security-manager/ samlassertionconsumer?SAMLart=emwjzal36b2dfyoc8en74xmvg9kps5qr HTTP/1.1 Host: gsa.yourdomain.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.19) Gecko/ 2010031422 Firefox/3.0.19 (.NET CLR 4.0.20506) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://gsa.yourdomain.
PAGE 14
An artifact must not be reusable. Once an artifact is dereferenced, the Identity Provider must reject attempts to dereference the same artifact again. PAGE 15
HTTP POST Binding [6d] [6e] With POST Binding, the IdP sends a digitally signed authentication Assertion identifying the user to the security manager via an HTML form POST through the browser. That is, the Assertion is digitally signed (XML Digital Signature) using the private key of the IdP. The signed assertion is embedded as a hidden variable (SAMLResponse) in an HTML form and transmitted directly to the user’s browser.
PAGE 16

PAGE 17
With the base64 encoded form of the signed SAML Response: PAGE 18
PAGE 19
When a user performs a search over access-controlled documents, the user must first authenticate to the search appliance. This allows the search appliance to reference the user’s identity when making authorization checks, and to include the search user’s identity in search logs. There is an option to turn off cache links and snippets for access-controlled documents. This allows the administrator to assess the risk of storing access-controlled documents on the search appliance.
PAGE 20
Here are the relevant portions of the SAML schema (see http://www.oasis-open.org/committees/ download.php/11903/saml-2.0-os-xsd.
PAGE 21
PAGE 22
Here are some relevant portions of the SAML schema for the response:
PAGE 23
PAGE 24
Since the URL found in the cache link (the cache URL pointed to by the cache link, not the URL that points to the original document) is not secret, we must again check the “GET” authorization for a document when the user tries to access the corresponding cache link URL.
PAGE 25
The following is an example of a possible response from the Policy Decision Point: HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnn PAGE 26
2. Enter the URL of the service so that the system can access the service when authorization is needed. 3. If you want to use batched SAML requests and your system meets the conditions described in this section, click the Use batched SAML Authz Requests checkbox. 4. Click the Save Settings button. SAML Batched Authorization Usage With Batched Authorization enabled, the search appliance performs authorization requests by inserting multiple AuthzDecisionQuery elements into a SOAP envelope.
PAGE 27
The following is an example of a message the search appliance sends to the Policy Decision Point: POST /authz HTTP/1.1 Host: pdp.yourdomain.com Content-Type: text/xml SOAPAction: http://www.oasis-open.org/committees/security Content-length: nnn PAGE 28
In return, the search appliance expects to receive one or more SAML Response elements inside a SOAP envelope from the Policy Decision Point. The PDP should return the same number of Response elements to correspond with the number of AuthzDecisionQuery elements that the search appliance sent in its request. The ordering of the responses within the SOAP envelope does not matter, but the ID attributes of the AuthzDecisionQueries must be preserved in the Response elements.
PAGE 29
GET Google Search Appliance: Authentication/Authorization for Enterprise SPI Guide 29
PAGE 30
SPI CallFlow Diagram The following diagram is the complete call flow for SPI showing both the Artifact and POST Bindings: Figure 10: Full SAML SPI calls between Google Search Appliance, security manager, IdP and PDP Google Search Appliance: Authentication/Authorization for Enterprise SPI Guide 30
PAGE 31
References • GSA Admin Toolkit: Sample SPI for authentication and authorization [https://code.google.com/p/ gsa-admin-toolkit/] • SAML 2.0: [http://www.oasis- open.org/specs/#samlv2.0] • Google Search Appliance Universal Login with SPI: The GSA’s security-manager providing universal login forms/SPI. [“The SAML Authentication Service Provider Interface (SPI)” in Managing Search for Controlled-Access Content] • XML Digital Signatures: Used for integrity protection of SAML Assertions. [http://www.w3.
PAGE 32
Index Symbols &SAMLRequest= 9, 11 identity transfer 18 IdP/PDP server 5 A L ActiveDirectory 4 Apache Axis 5 Artifact binding 15, 18 ArtifactResolve 7, 13 Assertion 6, 7, 15, 31 AssertionConsumerServiceURL 12 authentication challenge 9 Authentication Request Protocol 6 Authentication SPI 6–18 AuthN log 31 AuthnStatement 6, 7 Authorization SPI 18–29 AuthZ log 31 LDAP directory service integration 4 logs, AuthN and AuthZ 31 B batch authorization requests 25–29 C c# 11 cookie-cracker 4 D DEFLATE-compre
PAGE 33
X x.