User Identity Mapping In a Hybrid Environment, Part 2: ID Mapping Across Appliances

March 4, 2020

In the previous article, we discussed the significance of identity mapping for authorization and its importance within the Egnyte Platform. In this article, we will describe a mechanism that will make it possible to implement uniform ID-mappings across multiple appliances.

Before we take a deep dive into the solution, let us look at an example. User Jane from the Engineering department uses a network drive to access files while at work and also directly accesses the Egnyte cloud from remote locations. She has read rights to certain files and does not have any permissions over files being used by other departments. Her company uses Windows ActiveDirectory for Single Sign-On (SSO). Jane uses SSO credentials to use the network drive from the office. She should not be able to access data from, say, the Finance department from any end-point (on-premises or not). For that to happen authorization must come from a single source of truth, Egnyte Connect cloud in our case. Authorization is a function of the ID, and therefore, ID mapping needs to be accurate.

Let us see how the process starts. Jane authenticates with the on-premises Egnyte hybrid appliance using her laptop. When she tries to use the network drive, Winbind authenticates her with ActiveDirectory.

In the user-mapping phase of the appliance setup, we have already pulled down the user information both from the Egnyte Connect cloud and the local ActiveDirectory to the appliance. While pulling down this information, the Winbind’s id-map module has assigned a local ID to the users. Note that this ID is partially dependent on configuration and can be different on different hybrid appliances.

In background, our hybrid appliance periodically synchronizes ACLs with the Egnyte Connect cloud. An ID mapping process maps her ID within the Egnyte Connect cloud to the local ID provided by Winbind.

This user map stored on the device will be used to control access.This process is now modified such that, instead of having Winbind allocate the user-id to Jane, an Egnyte process will allocate the ID. This ID is based on her Egnyte Connect cloud ID her SID within ActiveDirectory. There are several advantages of this mechanism:

Access control across all Egnyte end-points is easier as one ID is being used everywhere.
The local ID mapping entity can provide the same IDs to multiple appliances.
It is possible to run the ID-Mapper in the cloud, thus allocating the same ID to devices across separate geographical locations.
Mappings based on a user's Egnyte Connect cloud ID is not impacted by username changes locally or in the cloud.

This is how it works:

‍Winbind is a component of SAMBA, which is responsible for authentication and ID-Mapping. Winbind provides several mechanisms of mapping a Windows user to the Linux server.

One of the mechanisms entails providing a backend script that provides IDs to the user. The format of the request and responses is well defined and published by the SAMBA community. We leverage this mechanism to provide a client program instead of a script. This program communicates with a local ID mapping server process. The server process in turn talks to the Egnyte Connect cloud to synchronize the ID mapping information which includes the ActiveDirectory SID. Egnyte Connect cloud already has a process to synchronize the users information with ActiveDirectory and only needs to synchronize the SID in addition to other information.

The AV presentation and slides describe the details of this scheme:

‍

The overall process of ID mapping using this mechanism is depicted in the figure.

Note that the process of pulling users information into the cloud from the AD is an out-of-band process.

In summary, this mechanism is extensible and can be used for uniform ID mapping and provides a solid mechanism for ID based authorization on hybrid appliances.

Complete SNIA presentation videos and slides can be found at the following locations: