Authentication
IOTA VUE always relies on Single Sign-On (SSO) using an organization-managed Identity Provider (IdP). IOTA supports OpenID Connect (OIDC) for authentication, which means you can connect your existing enterprise identity provider: such as Azure Entra ID, Okta, or any OIDC-compliant provider.
There are two approaches to identity management:
- Customer-managed IdP (recommended): Use your organization's existing identity provider. Users sign in with the same credentials they use for other enterprise applications. This is the recommended approach for production environments.
- IOTA-managed IdP: For evaluation or scenarios where a customer IdP is not available, IOTA can manage the identity provider on the IOTA side. Contact your Customer Success Advisor (CSA) for details.
For step-by-step setup instructions, see Configuring Your Identity Provider.
Data Source Authorization
Signing in to IOTA is a separate question from what a user is allowed to read in a connected system. When IOTA retrieves data from an external source, authorization is enforced by whichever model that source's driver supports, so which model applies depends on the data source, not on IOTA alone.
Three models are used across the driver portfolio.
User Pass-Through Permissions
For drivers that support user pass-through, the authenticated end-user identity is propagated to the data source, and the source system enforces authorization using that user's own permissions. IOTA never widens access beyond what the source grants that user.
Not every driver supports this. Sources that do include Azure SQL, Azure Synapse, Snowflake, Seeq, and Cognite.
Service Account-Based Access
The driver connects using a single service account, service principal, or access key. Every IOTA user reaches the source under that same authorization context, so on its own this model cannot tell users apart. Where per-user restrictions are needed, they have to come from somewhere else; see the hybrid approach below.
Hybrid Approach
Combines service account connectivity to the source with IOTA-side access controls, giving finer-grained permissions than the service account alone would allow.
The AVEVA PI System driver works this way: it connects under one Windows service account, then enforces per-user access internally by mapping identity-provider groups to PI and AF identities. See User Permissions and Write-Back.
Check your specific data source
Because support varies by source, do not assume a model. Each driver's pages list the authentication methods it actually supports; start from Data Sources and Driver Overview and open the guide for your source.
What's Next
Ready to set it up? Follow Configuring Your Identity Provider for the step-by-step OpenID Connect configuration.
Related
- Configuring Your Identity Provider: the setup steps
- Getting Started as an Admin: where authentication fits in the setup sequence
- Roles, Users, and Groups: control access once users can sign in