ViaWorks Security

What is security?

From the ViaWorks point of view, security is about finding out:

• Who you are, in order to perform a secure login. This is referred to as authentication.
  
• If you have a minimum of read access to the data sources you want to search, and to any result element within each data source before placing it in your search results list. This is referred to as authorization.

ViaWorks maintains security with heterogeneous data environments, with a variety of data sources like file servers, mail servers, database systems, groupware applications like SharePoint and IBM Domino, and others.

• Confirming the identity of a user.
  
• Microsoft Active Directory is an example of an authentication system.
  

Authorization

• Confirming that a specific user has access rights to a specific resource.
• Checking if user "johndoe" has read access to the file "performance_stats.docx" on the file share "C:\performance_documents\" is an example of determining authorization.
  

Impersonation and Delegation

These are methods used by Microsoft .Net to authenticate a person and to perform security authorization requests.

• Impersonation is using a person's credential to grant access (authentication) on login, and to check object level security (authorization).
• Delegation is a server side feature, required to be able to perform the impersonation.
• These are valid for any Microsoft Active Directory source, such as Microsoft Windows File, Exchange, and SharePoint servers, and other Active Directory integrated data sources.

The ViaWorks security model contains methods to handle both authentication and authorization.  To meet the requirements for high security Enterprise Indexing, the VirtualWorks system architecture utilizes three key security methods:

• Integrated Microsoft Active Directory user authentication.
• Microsoft Active Directory Single Sign-On support.
• Integrated security for non-AD data sources.
  

When using ordinary MS Active Directory (AD) authentication, the user will be presented with a web form, asking the user to submit the Windows username and password.  The option "Keep me signed in" will use browser cookies to store the user details.
ViaWorks matches the credentials provided against the security list handled by the repository authority.  For example:

• For Microsoft Fileserver, SharePoint, Exchange, the repository authority is Active Directory.
• For IBM Domino, the repository authority is the Domino Server.
• For Database Applications, the authority is the database (SQL, Oracle Server).

To allow ViaWorks users a "seamless" experience when using ViaWorks search, the ViaWorks administrator can choose to configure the ViaWorks server to use Single Sign-on (SSO).   This will allow users to login to ViaWorks without having to provide their user credentials.  By default, ViaWorks uses Microsoft NTLM for SSO authentication.  When SSO is enabled on the ViaWorks server, the user's credentials are supplied by the user's Windows session, and carried by the NTLM token to the ViaWorks server, which will automatically login the user.  

SSO is enabled from the ViaWorks Management Console by the ViaWorks administrator.  For instructions to enable SSO, please refer to the Management Console Sign-on Options page in the Administrator Guide.

As an alternative to NTLM, ViaWorks can also be configured to use Microsoft Kerberos for SSO authentication.  Please see the article Configuring Kerberos Authentication in the Administrator Guide for details.

Integrated Security for Non-AD Data Sources

For data sources not using Active Directory (AD) security, ViaWorks provides an integrated single sign-on security model.

• Significantly reduces search time.
• Reduces the amount of CPU required during search.
• Allows ViaWorks search clients to provide better features, such as deep refiners.

This paragraph only applies if group security is not being used.  If group security is being used then there is no window.  Using index-based security does allow for a small window where the security information for a document has changed, but has not yet been reflected in the index.  In this instance, an item may be returned in the search results for which the user does not have access to read, however, the user will never be able to open a document for which they do not have access.  Additionally, a user potentially may not find in the search results a document for which they have been given access until the security information is retrieved during the next discovery pass.

ViaWorks index based security is desirable over real-time security due to the following factors:

• Security information for individual documents rarely change.
• Information Technology best practices state that security policies should be implemented via group policies.  Using group policies prevent the instances of "stale" security information within the index.
• Security data is retrieved during the discovery phase which is the fastest phase. Discovery can run multiple times throughout the day, thus keeping security information in the index up-to-date.
• Index based security provides for much faster searches, and allows for providing deep refiners.

 It should be noted that Microsoft SharePoint 2010, with added FAST search, uses only index based security, and Microsoft SharePoint 2013 uses index based security as the default. 

The ViaWorks core is a highly efficient and scalable index. The index is located centrally on the ViaWorks server, inaccessible to any user, unless logged in locally on the ViaWorks server as an Administrator or Server Operator, and using specific tools and programming libraries to read the index content.

Access to the ViaWorks index is only offered through the ViaWorks REST API.  The API documentation is now included with the product, and after installation, can be found on the ViaWorks server at http://localhost/restservice/documentation.  For those who would like to review the REST API prior to installing ViaWorks, the documentation can be found at apidocs.virtualworks.com/RestService/Documentation.