User Authentication Method Matrix

Introduction

Saga provides:

• User authentication - verifying that the user is who the user claim to be

• User authorization - providing access only to data that the user is entitle to access

In the context of user authentication and authorization, SIDs, which stands for Security Identifiers, play a crucial role. A SID is a unique alphanumeric identifier assigned to each user, group, or object in a Windows-based operating system. SIDs enable the system to identify and manage user accounts and control access to various resources. Even though the term SID is a Windows term, the concept is the same across all data sources supported by Saga.

User Authentication

User authentication was traditionally limited to checking users for their password. However, these days authentication typically also comes with additional security features such as multi-factor authentication (MFA), IP blocking, etc.

User Authorization

Once a user has been authenticated, it is possible to retrieve all the SIDs pertaining to that user. These user SIDs can then be compared with the SIDs of the indexed documents (a list of SIDs for particular document is called an ACL - Access Control List). Only documents with matching user and document SIDs will be included in search results returned to that particular user. In addition to regular SIDs (allow-SIDs), Saga also supports deny-SIDs that takes precedence over any allow permissions that may have been assigned.

The management of SIDs varies depending on the specific data source and the associated security system. In the case of Windows objects, Active Directory and Azure AD play a key role in SID management, ensuring proper access control and authorization. For non-Microsoft data sources, their respective security systems are responsible for the handling of their SIDs.

The Authentication and Authorization Data Flow

The figure below shows how this is done in Saga:

Open

The numbered steps below correspond to the red numbers in the graphic above. Authentication takes place in step 3 and 4 and authorization in step 6 and 7

1. The user opens a browser and enters the URL of the Locator search page in the address box

2. The Gateway routes the incoming request to the Search UI

3. The user is prompted for their credentials to authenticate.

4. The user is authenticated by the Authority service that is synced with one or more external user database, for instance Microsoft Active Directory.

5. The user enters a query in the search box of the Search UI

6. The query is expanded with user’s SIDs before it is passed to the Index.

7. The search result is cleaned for any document to which the user does not have access. This is referred to as security trimming.

8. The search result is further modified based on rules in the Rule Engine

9. The Search UI displays the search result with a URI to access the document at the data source

Configuration Options

Here follows a list of the the authentication and authorization options that the Saga platform provides in their preferred order:

• Azure AD: The Authority Service is configured to use Azure AD.

• Azure AD with AD sync: The Authority Service is configured to use Azure AD and the Saga AAD AD Sync setting enabled that will retrieve Active Directory SIDs based on the userPrincipalName.

• Active Directory: The Authority Service is configured to use Active Directory.

• Active Directory with Azure AD connector: The Authority Service is configured to use Active Directory and the Azure AD connector have been configured to retrieve SIDs independently.

The Authentication Method Matrix

The retrieval of user and document SIDs is done by the connectors. Each connector is a specialist so to speak for a particular data source. Not all connectors can be used with all four authentication and authorization options above. Since the Authority Service can only be configured to use one of the four methods, it is necessary to find the most optimal method supported by all connectors to be used.

The following 3 icons show to which degree each connector supports each of the methods above:

• The method can be used (the connector fully supports the method)

• The method can be used (the connector uses an approach that can be used in parallel with the method, coined secondary user authentication by Ayfie)

• The method cannot be used

Below the table, there is an example that explains how to use the table to determine which authentication method to use.

Authentication Method Selection Example

The authentication method to use is found by identifying the left most column with only green icons for the set of connectors that one is to use.

In the example above we have a customer that is to install the following 3 connectors: the FileServer, Exchange Online and SharePoint. As we can see, Azure AD with AD sync is the left most column with only green markings. And that would then be the configuration one should go for.