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:

...

The numbered steps below correspond to the red numbers in the graphic above. Authentication takes place in step 3 and 4 andauthorizationin 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.

...

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

	Connector	Azure AD	Azure AD with AD sync	Active Directory	Active Directory with Azure AD connector
1		Recommended	2nd choice	3rd choice	Option of last resort
2	AzureAD
3	Acos Websack [DBC]
4	Confluence	🟢	🟢	🟢	🟢
5	CorePublish	🟢	🟢	🟢	🟢
6	Dropbox Business
7	eDOCS DM [DBC]
8	EloECM	🟢	🟢	🟢	🟢
9	Enterprise Vault
10	ePhorte
11	Exchange - On Premises connection
12	Exchange - Online (Single sign-on to hosted Exchange via ADFS) connection
13	Exchange - Online (Logon to hosted Exchange via cloud credentials)
14	FileServer
15	Google Workspace
16	Hubspot
17	iManage Work / iManage Cloud
18	Jira	🟢	🟢	🟢	🟢

18

19

Maconomy Cloud

19

20

Mailstore

20

21

MediaWiki

21

22

Microsoft Dynamics CRM

22

23

NetDocuments

23

24	P360Online

24

25

Salesforce

25

26

Sharepoint

26

27

Simployer aka Infotjenester

27

28

Slack

28

29	SuperOffice CRM

29

30	SuperOffice CRM Online

30

31

Teams

31

32

Web

32

33

Worksite [DBC]

Authentication Method Selection Example

THIS EXAMPLE IS WRONG DUE TO WRONG TABLE DATA. IT WILL BE CHANGED ONCE THE TABLE HAS BEEN CORRECTED.

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 Online. As we can see, Active Directory 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 for this customer.

Install Guide section

User Authentication

Once Saga has been installed one needs to configure the Authority Service (Keycloak) with the authentication method that is to be used as instructed in the *Post-Install Configuration* section further down. The two options are Active Directory and Azure Active Directory, each option with a different set of prerequisites (see the two lists below).

Deciding Authority Service Authentication Method

The recommended authentication method to configure is Azure Active Directory in the authority service for the reasons below:

• Easier to configure.

• Fine-tuned authentication policy to better control access to resources.

• Enables 2 Factor Authentication (2FA).

However, some connectors depend on what type of security identifiers are retrieved from what is configured in the authority service. One should consult the *Authority Service Requirements* section in the [Data Sheets](https://ayfie-dev.atlassian.net/wiki/spaces/SAGA/pages/2928246816/Ayfie+Connector+Data+Sheets) for each connector one plans to configure, before making the decision on which authentication method to configure.

The requirements of all connectors except Salesforce connector are met, if users are synchronized across Azure Active Directory and Active Directory by the use of [Azure AD Connect](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-azure-ad-connect ) or otherwise having matching *userPrincipalName* properties. The authority service should be set up with Azure Active Directory and the [Saga AD AAD Sync](#saga) setting in the install script menu should be enabled if this is the case.

The connector data sheets will list the authentication methods below:

• **Azure AD with AD sync**: Azure AD configured in the authority service with *Saga AAD AD Sync* setting enabled.

• **Azure AD only**: Azure AD configured in the authority service.

• **Active Directory**: Active Directory configured in the authority service.

One need to confirm a *Yes* for an authentication methods in all data sheets before configuring that authentication method.