Enterprise Search Sourcebook 2008

Where documents already have access-level security provided by a file system or a content management system (CMS), search security can be applied at the document level. This method of securing data will feel very familiar to those with a database background—certain groups or users can see certain documents. database record (via select statement or view) and XML (via XSLT); moderately difficult subdivision includes HTML (because it is not always well-formed) and PDF ; and the most difficult level, which includes proprietary office documents, and often requires a document filtering library and custom code or document conversion. Emerging open documents standards will make subdividing documents easier as they come into more widespread use. Two Types of Implementation Document-level security, where each group can have access to different documents on a group-by-group basis, is the fastest growing segment of high-end search engine installations. To have different permissions for each document, you need to have some type of existing Access Control List system and/or Single-Sign-On system in place and integration software from the search engine vendor to connect to it. Although implementations are vendor-specific, there are two primary designs for providing document-level security: “early binding” and “late binding” document filtering. Early binding document filtering is set up before the query is sent to the core search engine. Detailed information about the user’s permission is automatically added to the query, so the core engine will only bring back documents that the user can access. Early binding document security is often more complex to set up, but it is strongly preferred since it provides better performance and avoids some odd display issues. Late binding document filtering handles document security after the search has been submitted to the core engine, while the results list of matching documents is being displayed to the user. Each document’s access level is checked against the user’s security credentials. The results list formatter will check every document against an external server to see if the user has access. Late binding document filtering can potentially be very slow and can strain corporate security systems. Late binding is much simpler to design and implement. Until very recently, it was much more common. Early binding security requires significant up-front work. For each document, URL, database record, and so on, its entire access details must be downloaded and stored in the search index. Gathering Access Control List information from each of these unique sources and then mapping each to actual users and groups inside of a company is a complex task. With late binding security, a single question can be asked of any matching document and a user. A simple “yes/no” request is made to retrieve the URL of each document, and the user who issued the search has his credentials forwarded to the remote system. The remote system will either return the document or not, depending of the user’s rights. From the search engine’s standpoint it will get either a “yes” or “no” answer and decide to display or discard that document from the results list accordingly. Vendors have many different names for these two implementations, so sadly you may need to do a little digging. Problems to Look Out For In this article, we have addressed some of the key issues a company faces when all of its documents are indexed by a central search repository. Sometimes business processes or requirements dictate that some distributed sources of content cannot be included in a central search index. In this case, you may be able to solve the problem using a federated search. In a federated search model, each user query is sent to the native search engine for the distributed data source. The authentication credentials of a user are passed with each request. These results are merged with results from the central search repository and presented to the user. There are a number of challenges in federating results in an effective manner, including relevance ranking and result presentation. Still, federation may be the only way to get all the relevant content to the user. It is possible that some remote search engines will not accept federated searches for either technical or policy reasons. If there are a number of nonfederated sites like this, the sites themselves can at least be listed as suggested sources of data if the descriptions of the site contain matching terms. There are many potential security holes that need to be verified as a company deploys an enterprise search engine. The exponential growth of data reserves will only continue, so these issues will eventually need to be dealt with by all but the smallest companies. By matching the appropriate search engine technical tools with a company’s business requirements, companies can alleviate many of these concerns and significantly reduce the risk of unwanted security breaches. MARK BENNETT is the chief technology officer of New Idea Engineering (www.ideaeng.com), which helps companies make search work right. NIE focuses on search best practices to help companies select, design, and deploy advanced enterprise search applications, including search 2.0 interactivity, periodic review of search activity and ongoing search data quality monitoring to ensure great relevancy and user satisfaction. WWW.ENTERPRISESEARCHCENTER.COM 61 http://www.ideaeng.com http://WWW.ENTERPRISESEARCHCENTER.COM

Table of Contents Feed for the Digital Edition of Enterprise Search Sourcebook 2008

Enterprise Search Sourcebook 2008 Contents Editor’s Note Publisher’s Note Findings and Figures Why Enterprise Search Will Never Be Google-y Searching for Search Usability Your Users Are Talking to You What’s Your Search Story? Search Is Dead—Now What? Delivering on the Promise of Enterprise Search Taming Multiple Search Engines in Your Organization Enterprise Search: Trends for 2008 Enterprise Search Seen From the Inside Open Source Search: Elixir or Poison? Avoiding the Big Mistakes in Search Semantic Search Takes Root in the Enterprise E-Discovery Essentials: The Rules You Need to Know SharePoint Search: An Enterprise Contender? Integrating Security Into Your Enterprise Search Infrastructure Engineering a Better Search Infrastructure Letting End Users Ask the Questions, Stat! The Power of Knowledge Legal Research Using Enterprise Search: A Developer’s View From Treading Water to Full Steam Ahead Pulling Out All the Stops With Midas A Natural Search Solution An Incremental Approach to Improving Enterprise Search The Enterprise Search Sourcebook Showcase Directory Index to Advertisers and Companies Mentioned

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.