Skip to content

Authentication and Connection Management

The glean-powershell module manages Glean API connectivity through a centralized, module-scoped connection state object that abstracts two distinct authentication modes: Token-based Bearer authentication and Cookie-based Single Sign-On (SSO). The Connect-Glean cmdlet serves as the primary entry point, accepting parameters to configure the deployment instance, API base URLs, and authentication credentials, while delegating to specialized internal workers for browser-based cookie capture or direct token validation. Once established, the connection state is stored in $script:GleanConnection, allowing subsequent API requests to automatically inject the appropriate headers or session cookies without requiring repeated user interaction.

The Connect-Glean function determines the authentication mode based on the parameter set used during invocation. It supports two primary modes: Token and Cookie.

In Token mode, the module authenticates against the REST API using a Bearer token. The deployment target is specified either via the -Instance parameter, which expands to https://<instance>-be.glean.com, or via an explicit -BaseUrl 1. The token itself can be provided as a SecureString or plaintext string via the -Token parameter, or it falls back to the GLEAN_API_TOKEN environment variable. If neither is provided, the function throws an ArgumentException. The plaintext token is converted to a SecureString using ConvertTo-SecureString with the -AsPlainText flag to ensure secure storage in memory.

Cookie mode is selected using the -CookieAuth switch and is designed for environments protected by an identity provider that does not issue API tokens. This mode requires a -WebAppUrl to initiate the sign-in process. The module launches a browser (Auto, Edge, or Chrome) to capture the SSO session cookies. These cookies are then stored encrypted and reused for subsequent requests, enabling headless operation such as in MCP servers. The API base URL defaults to the origin of the WebAppUrl but can be overridden with -ApiBaseUrl.

The active connection is stored in the module-scoped variable $script:GleanConnection 2. This object is a pscustomobject that contains all necessary context for making API requests, including the authentication mode, base URL, API prefixes, and credentials.

The New-GleanConnection function constructs this object, ensuring a consistent shape regardless of the auth mode. Key properties include:

  • AuthMode: Either 'Token' or 'Cookie'.
  • BaseUrl: The trimmed base URL for the API.
  • ApiPrefix: A hashtable defining path prefixes for client and indexing APIs, defaulting to /rest/api/v1 and /api/index/v1 respectively.
  • Token: The SecureString bearer token (present only in Token mode).
  • WebSession: A WebRequestSession object containing cookies (present only in Cookie mode).
  • DefaultHeaders: A hashtable for custom headers like X-Glean-ActAs or X-Glean-Auth-Type 1.
  • SyncedAt and ConnectedAt: Timestamps for tracking connection lifecycle 2.

Engineers can inspect the current connection using Get-GleanConnection. This function returns a redacted view of the connection state via Get-GleanConnectionView 3. The view explicitly excludes sensitive data; for example, it reports HasToken as a boolean rather than exposing the token value, and similarly reports HasCookies based on the presence of the WebSession object 2. If no connection exists, it returns $null 3.

The Disconnect-Glean cmdlet clears the active connection by setting $script:GleanConnection to $null 4. This ensures that subsequent API calls will fail with a clear error message unless a new connection is established 2.

In Cookie mode, captured cookies are saved using Save-GleanCookieState 1. The module supports rebuilding a connection from this stored state using the -FromStore parameter, which avoids opening a browser window. The Convert-GleanSecureStringToPlain helper function is available for internal use to convert secure strings to plaintext when necessary, but it securely zeroes the memory after use to prevent leakage 2. For cookie capture, the module uses a debug transport that can be configured with AllowUnsafeDebugPort for local loopback access, though this is restricted in non-interactive contexts due to security risks 1.