How IT Admins Configure Connectors and Identity Permissions in Glean

Connecting enterprise software across fragmented departments—such as Microsoft 365, Google Workspace, Slack, Jira, Confluence, Salesforce, and custom internal repositories—creates a fundamental security dilemma for IT administrators. While employees need unified workplace search and conversational AI to locate project context, enterprises cannot afford data leakage across confidentiality boundaries. A unified index must not expose executive compensation spreadsheets, unreleased product roadmaps, or confidential HR tickets to unauthorized staff.

Glean resolves this dilemma through a permission-aware architecture that combines permission mirroring, identity stitching, and query-time access enforcement. Rather than requiring administrators to rebuild access control models inside Glean, the platform ingests and enforces the native Access Control Lists (ACLs) of every connected source tool.

This technical guide walks enterprise IT administrators through the end-to-end process of deploying data source connectors, configuring identity federation and user aliasing, and verifying permission boundaries to enable safe, cross-silo workplace search.

Architectural Fundamentals: How Glean Enforces Security

Before initiating connector deployments, IT administrators must understand the three core mechanisms that guarantee data governance inside Glean:

1. Permission Mirroring

Glean does not maintain a detached, synthetic permission layer. Instead, native connectors continuously ingest the exact permission schemas established in source applications. Whether a file in SharePoint inherits permissions from a nested folder, a Confluence space is restricted to a specific user group, or a Salesforce record has custom sharing rules, Glean mirrors these access maps directly into its Enterprise Knowledge Graph.

2. Identity Stitching Across Disparate Accounts

Enterprises rarely use identical account identifiers across all software tools. An engineer might authenticate via Okta as jane.doe@enterprise.com, appear in Jira as jdoe, commit code in GitHub under a personal handle, and hold legacy accounts in a secondary email domain following a merger. Glean's identity pipeline stitches these disparate accounts into a unified person record using directory attributes crawled from your primary Identity Provider (IdP).

3. Query-Time and Passage-Level Enforcement

When a user submits a search query or prompts Glean Assistant, Glean evaluates the user's verified identity against the mirrored ACLs in real time.

• Search Results: Items the user lacks permission to view in the source application are filtered out entirely; they do not appear in search results, previews, or suggested links.
• Generative AI Grounding: Glean Assistant synthesizes answers using Retrieval-Augmented Generation (RAG) strictly restricted to the documents the inquiring employee is allowed to view. If an employee asks about company financial projections, Glean cannot draw upon restricted executive files to formulate the answer.
• Passage-Level Restrictions: For document types supporting granular access controls, Glean isolates restricted sections, preventing unauthorized readers from viewing sensitive snippets embedded within broadly accessible documents.

Phase 1: Identity Provider Integration and Role Delegation

The first administrative milestone is establishing the identity foundation. Glean requires Single Sign-On (SSO) and synchronizes user profiles through automated People Data crawls.

Configuring SSO and Identity Providers

Single Sign-On is mandatory across all Glean deployments. Administrators configure IdP integration under Admin Console > Users & permissions > Authentication.

• Protocols: Glean supports OpenID Connect (OIDC) and SAML 2.0. OIDC is strongly recommended by Glean for its granular permission handling and seamless directory attribute synchronization.
• Supported IdPs: Native integrations exist for Microsoft Entra ID (formerly Azure AD), Okta, and Google Workspace.

Administrative Role Hierarchy

To follow the principle of least privilege, Glean establishes three administrative roles:

Administrators can assign these roles directly or map them dynamically via Group-based permissions. When mapped to an IdP security group (e.g., Entra-IT-Admins), group members automatically inherit Glean administrative privileges.

Phase 2: User Aliases and Identity Stitching

For unified search to work across disparate systems, Glean must link an employee's actions, authored documents, and access entitlements across every tool to their primary identity.

Directory Crawling and Alias Derivation

During scheduled People Data crawls, Glean retrieves user records from the IdP. Glean assigns each user one person record keyed to their primary email address. Additional email addresses and usernames discovered across source applications are mapped as aliases.

Microsoft Entra ID Attribute Mapping

• userPrincipalName: Crawled as the default primary email. (Can be switched to the mail attribute by requesting configuration update azure.useMailAsPrimaryEmailField=true from Glean support).
• mail: Crawled as an alias by default.
• proxyAddresses: Crawled as aliases by default. Recommended source: This field is IT-controlled in Entra ID and provides the safest mechanism to register multi-domain or alternate email addresses.
• otherMails: Off by default. Requires enabling azure.crawlOtherMailsForAlias=true.

Okta Attribute Mapping

• email: Crawled as primary email.
• login: Crawled as an alias by default.
• proxyAddresses: Crawled as aliases by default when mapped from Active Directory or configured as an admin-controlled custom attribute.
• secondEmail: Off by default.

Crucial Security Warning: User-Editable Attributes

[!WARNING] Attributes such as otherMails in Entra ID and secondEmail in Okta are user-editable in many corporate tenant configurations. If end users can freely modify these fields in their personal profile, treating them as trusted aliases introduces a severe privilege escalation vulnerability: a user could add a colleague or executive's email address and inherit access to documents shared with that address.

Keep these fields disabled unless your IT tenant explicitly locks end-user editing, and always populate multi-domain aliases through admin-controlled attributes such as proxyAddresses.

Identity Stitching in Mergers, Acquisitions, and Multi-Domain Setups

In organizations managing multiple email domains or post-merger environments:

1. Maintain secondary domain emails in the user's proxyAddresses attribute within the primary IdP.
2. Populate aliases for all active accounts, not just legacy migration batches.
3. If an upstream IdP cannot store necessary attributes (e.g., custom legacy systems), Glean provides a manual alias CSV upload utility in the Admin Console as a fallback.

Phase 3: Configuring Data Source Connectors

Glean supports a wide catalog of enterprise integrations categorized into distinct operational models:

• Native Connectors: Pre-built SaaS connectors (e.g., Google Drive, OneDrive, SharePoint Online, Slack, Jira, Confluence, Salesforce, GitHub, ServiceNow). They communicate directly with vendor APIs to pull content, activity signals, and ACLs.
• Push API Connectors: Custom integrations using the Glean Indexing API. Used for custom in-house tools, databases, or on-premises platforms hosted behind corporate firewalls.
• Partner Connectors: Third-party integrations maintained by software vendors using Glean's developer platform.
• Web History Connectors: Browser extension-based discovery for web apps lacking crawlable APIs, keeping browsing history private to the individual user.

Step-by-Step Connector Setup Workflow

[1. Select App in Hub] 
         │
         ▼
[2. Review Prerequisites & API Scopes]
         │
         ▼
[3. Authenticate & Configure Credentials]
         │
         ▼
[4. Define Content Rules in "Manage Data"]
         │
         ▼
[5. Run Initial Crawl & Indexing]
         │
         ▼
[6. Validate Permissions in Pilot Test Group]

Step 1: Select Application in Connectors Hub

Navigate to Admin Console > Connectors > Connectors hub and locate the target system (e.g., Confluence Cloud or Microsoft SharePoint).

Step 2: Verify Source-Side Prerequisites and Scopes

Review the prerequisite documentation for the specific connector:

• Service Accounts: Ensure you have an administrative account with read permissions across the target data corpus. For example, connecting ServiceNow requires granting specific table read ACLs and elevating to security_admin during setup.
• API Scopes: Prepare the OAuth application, Entra App Registration, or API key with necessary read-only permissions (e.g., Files.Read.All, Sites.Read.All for Microsoft Graph).
• Least Privilege: Glean's native connectors only require read-level permissions to crawl documents and security metadata. Write permissions are never required for search indexing.

Step 3: Configure Authentication and Connector Settings

Click Add connector, enter the instance domain, provide the credentials (OAuth client secret, service token, or admin authorization grant), and save the configuration.

Step 4: Define Scope in "Manage Data"

Many native connectors include a Manage data configuration tab:

• Inclusion/Exclusion Rules: Blacklist specific SharePoint site collections, Slack channels (e.g., executive or legal channels), Jira projects, or Confluence spaces that should never enter the unified index.
• Data Access Modes: Choose between Indexed (crawled ahead of time into Glean's tenant index) or Live / Hybrid (query-time API retrieval for fast-changing or long-tail entities).

Phase 4: Initial Crawl, Indexing, and Access Verification

Once configured, the connector enters the synchronization lifecycle.

The Two-Phase Sync

1. Crawling Phase: Glean's ingestion workers call the source APIs, fetching document objects, metadata (author, created date, change timestamps), and associated permission structures (user ACLs, group permissions, domain share flags).
2. Indexing Phase: Glean processes raw text, extracts embeddings, resolves entity relationships, maps user IDs to the People Graph, and incorporates documents into the searchable Knowledge Graph.

The duration of the initial sync depends on the size of the repository and the vendor's API rate limits. Administrators can monitor real-time sync progress, item counts, and API response metrics under Admin Console > Connectors > Manage connectors.

Validating Access Controls in a Pilot Group

Before rolling out search across the organization, administrators must validate security enforcement:

1. Configure a Test Group: Under connector settings, restrict visibility to an internal IT testing group or pilot cohort.
2. Positive Search Testing: Log in as pilot users with different departmental privileges. Ensure users can find files they have legitimate access to in Google Drive, Confluence, or SharePoint.
3. Negative Search Testing (Crucial): Search for known restricted assets (e.g., a locked HR salary sheet or an executive board deck). Confirm that users lacking permission in the native tool receive zero search results and that Glean Assistant does not cite or reference the restricted material.
4. Tool and Action Verification: If the connector includes live tools for Glean Assistant (such as ticket creation or MCP servers), confirm that actions are executed under the calling user's delegated credentials and that blocked tools cannot be invoked.

Phase 5: Ongoing Governance, Health Monitoring, and Agent Controls

Maintaining an enterprise search ecosystem requires proactive monitoring and ongoing governance:

Incremental Updates and Webhooks

Following the initial crawl, Glean relies on webhooks and periodic incremental crawls to reflect document additions, content edits, and ACL adjustments. In most native SaaS connectors, permission updates made in source tools synchronize within minutes, preventing permission drift.

Sync Health Alerts and Audit Logs

Administrators should monitor the Notifications Dashboard and Admin Alerts for connector failures, expired OAuth tokens, or API rate-limit throttling. Full administrative activity—including connector modifications and role assignments—is captured in immutable Audit Logs.

Governance for AI Agents and MCP Integrations

As organizations adopt Model Context Protocol (MCP) servers and autonomous agents:

• Glean enforces that agents never exceed the permission boundaries of the user prompting them.
• Administrators can centrally whitelist or block specific tool actions under Admin Console > Tools, preventing unapproved write-back operations or unintended data exposure across downstream tools.

Best Practices Checklist for Enterprise Administrators

1. Lock Down Identity Attributes: Audit Entra ID and Okta configurations to confirm that alias attributes like proxyAddresses are strictly IT-managed and user-editable fields remain isolated.
2. Leverage Group-Based RBAC: Map Glean administrative roles to existing IdP groups rather than assigning individual user accounts.
3. Audit Exclusions Early: Exclude non-work, highly confidential, or archival repositories via the Manage data tab prior to initiating the initial full crawl.
4. Conduct Rigorous Negative Testing: Validate access control boundaries with test accounts across different departments before removing test group restrictions.
5. Monitor Health Signals: Track connector sync status and directory crawl reports to catch credential expirations before they impact end-user recall.

By systematically aligning IdP directory attributes, delegating scoped administrative roles, and utilizing Glean's automated permission mirroring, enterprise IT teams can dismantle internal information silos while maintaining strict enterprise-grade security and compliance.

References

• About connectors
• Get started with connectors
• Administrator Roles
• User aliases and identity stitching
• AI Security: Protecting Enterprise Data with Glean