Server Administration
Authentication
Authentication validates the identity of an individual. With Server, the method for authentication is configured in the System Settings. An admin can choose one of 4 available methods.
Built-in: Users specify an email address and password of their choice to access the Server user interface (Server UI).
Integrated Windows authentication: Users access the Server UI with internal network credentials.
Integrated Windows authentication with Kerberos: Users access the Server UI with internal network credentials using Kerberos authentication protocols.
SAML authentication: Users access the Server UI with Identity Provider (IDP) credentials.
Built-In | IWA | SAML | |
|---|---|---|---|
Authentication Mechanism | Email and Password | Windows Domain Credentials | SAML Token |
Credential Storage | MongoDB | Domain Controller (Active Directory) | Identity Provider (IdP) |
Account Creation | User Sign Up or Admin Adds | Automatic | Through IdP |
Group Integration | Yes (Collections and Permissions) as of 2020.4 | Yes (Collections and Permissions) | Yes (Collections and Permissions) as of 2020.4 |
Session Timeout | Yes | No | Yes |
Multi-Factor | No | No | Yes |
重要
Choose the authentication type carefully. Once chosen, it should not be changed. The structure of MongoDB is tightly coupled with the authentication type. If you want to change the authentication, contact support to create a plan.
Integrated Windows Authentication provides the most functionality and the best user experience.
If your organization requires a single sign-on solution, SAML should be used.
The built-in authentication is appropriate for example, if public access is required or if there is no available Active Directory.
For more information about these methods, go to Configure Server Authentication.
Authorization
Authorization determines what actions a user can perform in the Server UI. In this case, authorization is determined by a user's role and their permissions. In the table below, review the actions that the different roles can perform. Go to the User Roles and Permissions help page for more info.
Groups
Groups are groups of Server users. You can assign a user's role through group assignment, but user permissions are explicitly tied their profile. Groups can be set up in 2 different ways. You can import Active Directory (AD) groups from Active Directory. Or you can create a custom group of users from the Server UI. Go to the Manage Groups help page for more info.
Server Configuration Security Settings
Configuration settings can provide additional levels of security in the Server by enforcing global settings for Users, Workflows, and the Server UI. With respect to security, these settings are important to review as they can enable or restrict access or actions that can be taken in the Server UI. Review each setting to learn how they can be applied to secure the Server.
Default Role: The default role is applied to all users that don’t have an assigned role via their user or a group. The default role is set to Viewer by default. Configuring the default role to No Access provides enhanced security to prevent access to the Server UI unless you explicitly define it.
Users Can Register: This setting enables a sign-up option on the login page for new users to create a new account to obtain access to the Server UI. This setting is only available for Built-In and SAML authentication types. If disabled, a Server admin has to explicitly grant access.
Unregistered Users Can Run Public Workflows on the Homepage: By default, only signed-in users can run workflows. When this setting is enabled, workflows made public on the home page can be run without signing in. Go to the Server UI Home help page for more info about managing public workflows.
Workflow Credentials Setting: This setting controls whether a user is required to enter workflow credentials to run workflows in the Server UI.
Users Can Schedule Workflows: This Server-level setting enables the ability to schedule jobs at the environment level. If a user has the matching user-level schedule-jobs permission, they can schedule jobs in the Server UI. Go to the User Roles and Permissions help page for more info on the user-level setting.
Disable Direct Download: This setting removes the ability for Server users to download workflows from the Server UI.
Go to the Alteryx Server Settings help page to learn more about these settings.
Run As and Workflow Credentials
By default, Server runs workflows as the system user. If you configure the Server to use a different service account, then Server uses that account to run workflows.
Because most workflows require input and output files that are stored in access-controlled directories, a Run As user should be used. A Run As user allows for the ability to run a workflow as a specific user. This supports controlling the access to data sources and permissions on a machine. A Run As user allows the engine to execute the workflow as that user. This provides access to read and write to protected file paths, as well as databases that support trusted Windows Integrated Security connections without requiring user credentials.
Go to Worker and Credentials help pages for more info.
API OAuth Parameters
When using the API we recommend using header parameters OAuth parameters instead of query parameters. Go to the Server API Overview to learn more.