Deployment Scenario Handbook

Cookie Translation with Silent Authentication

Scenario overview


In the use case for this scenario, Acme Inc. wants to integrate their SiteMinder SSO and three different content sources with the GSA using the following mechanisms:

  • Per-URL ACLs
  • Connector-based authorization
  • Public content

They would prefer their users had a seamless, silent authentication experience with search after logging into the main company portal.

Requirements


  • Index the following content:
    • Livelink
    • Web Based People Directory Application
    • Lotus Connections
  • Provide a general search box, which would return a results page with the most relevant links across all indexed content.
  • Present search results for secure content only to users authorized to see the content.
  • Provide seamless silent authentication with search after a user initially logs into the main portal.
  • Content in Lotus Connections is secured based on native Lotus Connections groups as well as LDAP groups.

Assumptions


  • SiteMinder SSO is in place to authenticate users to the secure content sources—Livelink and Connections.
  • All content sources use the same common identity.
  • The existing Google Search Appliance Connector for Livelink will be used to integrate the GSA with Livelink.
  • Connections content will be fed into the GSA.
  • ACLs can be fed with Connections content to take advantage of the Per-URL ACLs feature of the GSA.

Key considerations


  • Confirm the assumption that all content sources use the same common identity.
  • Determine whether the content sources use content source-native groups or groups synched with Active Directory/LDAP.
  • Confirm the assumption that Lotus Connections can use the Per-URL-ACL’s feature of the GSA to feed ACL information along with the content feed.

Recommended approach


Google’s recommended approach for implementing cookie translation that provides silent authentication covers the following areas:

Architecture overview

Acme Inc. will integrate the content sources listed in the following table with the GSA.

Content source Integration method
Lotus Connections
  • Connections native groups along with LDAP groups are fed in with the content
  • Content is kept in synch by using the SeedList capability of Lotus Connections
Open Text Livelink
  • The connector keeps the content in synch
  • ACLs are not fed in along with the content.
  • Connector-based authorization is used—it authorizes batches of documents at a time
Web-Based people directory content  

Authentication

According to Acme Inc.’s authorization mechanisms, both secure content sources need a verified identity with a username in order to authorize content for users at serve time. The Livelink connector needs a verified username in order to perform connector-based Authorization. A valid username, along with associated groups, needs to be supplied to the GSA to authorize content with ACLs in the index.

Because both content sources are under the SiteMinder SSO at Acme Inc., users will have a cookie in their session that enables them to access the sources after logging into the main search portal to perform a search. A Universal Login Forms Based Authentication rule will be setup to fetch a sample URL, protected by SiteMinder, as part of the authentication process. If a user is already logged into the portal and has a SiteMinder cookie, he will be authorized and won’t have to provide credentials.

Authorization

Both content sources’ authorization mechanisms require credentials:

  • Livelink requires a verified identity with a username
  • Connections requires a username and groups

For this reason, the SiteMinder SSO-protected sample URL page will need to return the following information about the user providing the SSO cookie for authentication:

  • A username
  • A list of groups associated with the user

This is also referred to as “cookie cracking.”

This is achieved by creating a JSP or ASP.NET that, after validating the authenticity of the SSO cookie, returns a HTTP response to the GSA. The response has a 200 OK status code and a verified username and list of associated groups in the header, specifically “X-Username” and “X-Groups.” Note that Connections native groups, along with user LDAP groups will need to be returned to support Connections ACLs in the index.

The following steps describe a full and successful authentication and authorization flow:

  1. User logs into company intranet portal through a SiteMinder login page and a SiteMinder cookie is created in his/her session.
  2. User performs a search on the GSA, passing along applicable scoped cookies.
  3. GSA fetches Sample URL, passing along cookies that are scoped for the fetch; the cookie is used to verify authentication to the SiteMinder protected page.
  4. The page returns a 200 along with the verified username and groups associated with the user whose cookie was passed to the page.
  5. The GSA considers the fetch a success and associates the username and group to the verified identity credential group.
  6. The username and groups are used to further authorize content on the GSA. The username is passed on to do Connector based AuthZ for Livelink. The username and groups are passed on to do authorization checks for ACLs associated to content in the index.

Alternative approach


For all content, perform HEAD request authorization checks, which wouldn’t need groups and a username associated with the verified identity.

Project task overview


The following table lists the project tasks and activities for implementing cookie cracking that provides silent authentication.

Task Activities
Plan deployment architecture
  • Deploy that application into a web/application server that is protected by SiteMinder—in the case of Apache, a SiteMinder plugin can be used to integrate with the SSO
Configure crawl and index
  • Configure crawler for indexing public content
Configure Cookie Based Authentication with a Sample URL under Universal Login Auth Mechanisms  

Long term enhancements


  • Perform an architecture review as new content sources are brought on to see if existing architecture needs to be modified for onboarding new content.
  • If ACLs for Livelink become available, adjust cookie cracker to return Livelink groups as well. Consider a cookie cracker in a separate credential group (namespace), if there are group name clashes.
Was this helpful?
How can we improve it?