To connect, set the URL and provide authentication. The URL is your Zendesk Support URL: https://{subdomain}.zendesk.com.

Authenticating to Zendesk

Zendesk uses Basic authentication or the OAuth 2 authentication standard.

Use Basic to connect to your own data. Use OAuth to allow other users to connect to their data.

Using Basic Authentication

To use Basic authentication, specify your email address and password or your email address and an API token. Set User to your email address and follow the steps below to provide the Password or ApiToken.

1. Enable password access in the Zendesk Support admin interface at Admin > Channels > API.

2. Manage API tokens in the Zendesk Support Admin interface at Admin > Channels > API. More than one token can be active at the same time. Deleting a token deactivates it permanently.

Using OAuth Authentication

OAuth requires the authenticating user to interact with Zendesk using the browser. The provider facilitates this in various ways as described below.

Register an OAuth Application

Follow the procedure below to register a third-party application and obtain the OAuth client credentials, the OAuthClientId and OAuthClientSecret. Note that this procedure requires admin access to your Zendesk account.

1. In the Zendesk Support Admin interface, go to Admin > Channels > API.

2. Click the OAuth Clients tab on the Channels/API page and then click the plus icon (+) on the right side of the client list.

3. Complete the required fields to create a client.

   If you are making a desktop application, set the Redirect URI to http://localhost:33333 or a different port number of your choice.

   If you are making a Web application, set the Redirect URI to a page on your Web app you would like the user to be returned to after they have authorized your application.

4. Click Save. After the page refreshes, a new prepopulated Secret field appears on the lower side.

5. Use the unique identifier as the OAuthClientId and the secret value as the OAuthClientSecret.

After setting the following connection properties, you are ready to connect:

• OAuthClientId: Set this to the client Id that you specified in your app settings.

• OAuthClientSecret: Set this to the client secret that you specified in your app settings.

• CallbackURL: Set this to the Redirect URI you specified in your app settings.

• InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to manage the process to obtain the OAuthAccessToken.

When you connect, the provider opens the OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process.

1. Extracts the access token from the callback URL and authenticates requests.

2. Obtains a new access token when the old one expires.

3. Saves OAuth values in OAuthSettingsLocation to be persisted across connections.

Connecting to Jira

To connect set the URL to your Jira endpoint; for example, https://yoursitename.atlassian.net.

Accessing Custom Fields

By default the provider surfaces only system fields. To access the custom fields for Issues, set IncludeCustomFields to true. Or, you can extend the provider schemas to configure access to custom fields; Please note that the server response time can be significantly slower when custom fields are included.

Set the IncludeCustomFields property to True to expose access to all custom fields.

Authenticating to Jira

OAuth 2.0

You can leverage Jira's "three-legged" OAuth 2.0 support (3LO) to connect to data without providing your login credentials.

AuthScheme must be set to OAuth in all OAuth flows.

To obtain the OAuth client credentials, consumer key, and consumer secret:

1. Log in to your JIRA Cloud site.

2. Navigate to application management at https://developer.atlassian.com/apps/ (not your OAuth credentials at yoursitename.atlassian.net/secure/admin/oauth-credentials, which is for self-hosted tools.)

3. Select Create new app, then name the application. This creates the application.

4. If missing, add OAuth 2.0 functionality to your application by navigating to APIS AND FEATURES > + Add > Add OAuth 2.0 (3LO).

5. From APIS AND FEATURES > + Add, add the Jira platform REST API to your application .

6. From APIS AND FEATURES > + Jira platform REST API, add the desired scopes to your application .

7. You'll additionally need to set up your Callback URL. Navigate to APIS AND FEATURES > OAuth 2.0 (3LO). Enter a URL that is accessible to your application and save the changes.

After setting the following connection properties, you are ready to connect:

• OAuthClientId: Set to the consumer key in your application details.

• OAuthClientSecret: Set to the consumer secret in your application details.

• CallbackURL: Set to the callback URL found in your application details under APIS AND FEATURES > OAuth 2.0 (3LO).

• InitiateOAuth: Set to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken connection property.

• OAuthVersion: Set to 2.0.

• Url: The URL to your JIRA endpoint; for example, https://yoursitename.atlassian.net.

When you connect, the provider opens Jira's OAuth endpoint in your default browser. Log in and grant permissions to the application. The provider then completes the OAuth process:

• The provider obtains an access token from Jira and uses it to request data.

• Extracts the access token from the callback URL and authenticates requests.

• Saves OAuth values in the path specified in OAuthSettingsLocation. These values persist across connections.

The provider refreshes the access token automatically when it expires.

OAuth 1.0

To connect to Jira you have to follow the steps below:

1. Generate an RSA public/private key pair. In your terminal, run the following commands:
2. Create application links in your account. Go to Settings > Applications > Application links.

3. Enter a test URL for the url field, click Create new link.

4. Ignore the error and click continue. You need only configure incoming calls (from the application to Jira).

5. In the Link applications window, filling in the fields is optional, since they are not relevant to this task. But make sure to select Create incoming link. Click Continue. to go to the next page.

6. Fill in the required fields:

   • Consumer Key: Use any string you want. This is required for the OAuthClientId connection property.

   • Consumer Name: Use any string you want.

   • Public key: Enter the key from the jira_publickey.pem file you generated earlier.

7. Click Continue.

To connect set the following properties:

• URL (for example: https://yoursitename.atlassian.net).

• OAuthClientId to the Consumer Key of your application.

• OAuthClientSecret to any value (such as 'testClientSecret').

• CertificateStore to the location of your private key file.

• CertificateStoreType to the appropriate option based on the private key file being used. If using the generated PEM key file, set CertificateStoreType to PEMKEY_FILE.

• InitiateOAuth to GETANDREFRESH.

API Token

You can establish a connection to any Jira Cloud account by setting the AuthScheme to APIToken and providing the User and APIToken. An API token is necessary for basic authentication to Cloud instances. To generate one, log in to your Atlassian account and navigate to Security > Create and manage API tokens > Create API token. The generated token will be displayed.

Basic

You can establish a connection to any Jira Server instance by setting the AuthScheme to Basic. To connect to a Server Instance provide the User and Password. (Note: Password has been deprecated for connecting to a Cloud Account and is now used only to connect to a Server Instance.)

LDAP

You can establish a connection to any Jira Server instance by setting the AuthScheme to LDAP. Additionally provide the URL, User and Password of the Jira instance. (Note: LDAP Authentication is not currently supported for Cloud accounts.)

Crowd

Set the AuthScheme to Crowd. The following connection properties are used to connect to Crowd:

• User: The CROWD user account.

• Password: The password associated with the Crowd account.

• SSOLoginURL: The login URL associated with the Crowd account. You can find the IDP URL by navigating to your application -> SSO -> SSO information -> Identity provider single sign-on URL.

• SSOAppName: The name of the application in which SSO is enabled.

• SSOAppPassword: The password of the application in which SSO is enabled.

• SSOExchangeUrl: The URL used used to exchange the SAML token for Jira cookies. This URL may have the following formats:

  • https://<authority of Jira instance>/plugins/servlet/samlconsumer

  • https://<authority of Jira instance>/plugins/servlet/samlsso

The following is an example connection string:

Okta

Set the AuthScheme to Okta. The following connection properties are used to authenticate through Okta:

• User: Set to your Okta user.

• Password: Set to your Okta password.

• SSOLoginURL: Set to the login URL used by the SSO provider.

• SSOExchangeUrl: The URL used used to exchange the SAML token for Jira cookies. This URL may have the following formats:

  • https://<authority of Jira instance>/plugins/servlet/samlconsumer

  • https://<authority of Jira instance>/plugins/servlet/samlsso

If you are:

• using a trusted application or proxy that overrides the Okta client request

• configuring MFA

then you need to use combinations of SSOProperties input parameters to authenticate using Okta. Otherwise, you do not need to set any of these values.

In SSOProperties when required, set these input parameters:

• APIToken: When authenticating a user via a trusted application or proxy that overrides the Okta client request context, set this to the API Token the customer created from the Okta organization.

• MFAType: Set this if you have configured the MFA flow. Currently we support the following types: OktaVerify, Email, and SMS.

• MFAPassCode: Set this only if you have configured the MFA flow. If you set this to empty or an invalid value, the provider issues a one-time password challenge to your device or email. After the passcode is received, reopen the connection where the retrieved one-time password value is set to the MFAPassCode connection property.

• MFARememberDevice: Okta supports remembering devices when MFA is required. If remembering devices is allowed according to the configured authentication policies, the provider sends a device token to extend MFA authentication lifetime. This property is, by default, set to True. Set this to False only if you do not want MFA to be remembered.

Example connection string:

1 Connecting to ServiceNow

Before you can connect to data, you will need to ensure the authenticating user has the following permissions assigned at minimum, required for listing metadata. Before you can do this, the administrator of the account must elevate their role by navigating to User menu -> Elevate Roles -> check the security_admin box -> OK. For the tables listed below, the user must have both row-level permission, such as sys_db_object, as well as field-level permission, such as sys_db_object.*. For additional tables which the user wishes to access, they must have at least row-level permission.

The connection property Url is a required property on all connections.

1.1 READ sys_db_object

Access to sys_db_object is required to connect to data. You can enable access to this as follows:

1. Navigate to the System Security -> Access Controls (ACL). Select New to create an access control object.

2. For Type, select record.

3. For Operation, select read.

4. For Name, select Table [sys_db_object] in the first drop-down and --None-- in the second drop-down.

5. In the Requires role section, double-click the text box that says Insert a new row.... Search for and select your desired role.

6. Click Submit to create the ACL object.

7. Assign the role which has the created ACL to the authenticating user. To do this, navigate to User Administration -> Users -> Select authenticating user -> Roles -> Edit... -> add your role from collection.

1.2 READ sys_glide_object

Access to the sys_glide_object is required for certain ServiceNow table metadata. You can enable access to this by repeating the above procedure, but instead selecting Field class [sys_glide_object] for the ACL's name.

1.3 READ sys_dictionary

Access to sys_dictionary is required to retrieve schema information from ServiceNow. You can enable access to this by navigating to User Administration -> Users -> Select authenticating user -> Roles -> Edit... -> add "personalize_dictionary" role from collection.

2 Authenticating to ServiceNow

2.1 Authenticate using Basic Authentication

In order to authenticate using Basic Authentication you will need to provide your ServiceNow User and Password.

After setting the following connection properties, you are ready to connect:

1. AuthScheme: Set this to BASIC.

2. User: Set this to your username.

3. Password: Set this to your password.

4. Url: Set this to the base URL of your ServiceNow instance site. For example: https://MyInstance12345.service-now.com/.

5. InitiateOAuth: Set this to OFF to avoid entering the OAuth Authorization process.

2.2 Using OAuth

ServiceNow uses the OAuth 2.0 authentication standard. To authenticate using OAuth, you will need to register an OAuth app with ServiceNow to obtain the OAuthClientId and OAuthClientSecret. In addition to the OAuth values, you will need to specify the Url, User, and Password.

For more information about connecting via OAuth authentication, refer to our Using OAuth Authentication guide.

2.3 Authenticating with ADFS

Set the AuthScheme to ADFS. The following connection properties need to be set:

• User: Set this to the ADFS user.

• Password: Set this to ADFS password for the user.

• SSOLoginURL: Set this to the login url used by the SSO provider.

The following SSOProperties are needed to authenticate to ADFS:

• RelyingParty: This attribute is the value of the Relying Party Identifier on the ADFS server for ServiceNow.

Below is an example connection string:

2.4 ADFS Integrated

The ADFS Integrated flow indicates you are connecting with the currently logged in Windows user credentials. To use the ADFS Integrated flow, simply do not specify the User and Password, but otherwise follow the same steps in the ADFS guide above.

2.5 Authenticating with Okta

Set the AuthScheme to Okta. The following connection properties are used to connect to Okta:

• User: Set this to the Okta user.

• Password: Set this to Okta password for the user.

• SSOLoginURL: Set this to the login url used by the SSO provider.

The following SSOProperties are needed to authenticate to Okta:

• APIToken (optional): Set this to the API Token that the customer created from the Okta org. It should be used when authenticating a user via a trusted application or proxy that overrides OKTA client request context.

• MFAType (optional): Set this only in case you have configured MFA flow. Currently we support only the follwoing types: OktaVerify,Email and SMS.

• MFAPassCode (optional): Set this only in case you have configured MFA flow. If this is set to empty/invalid the driver will initially issue a MFA challenge which will trigger the platform to send you an one-time password on your device or email, based on the configured MFA type. You need to re-issue another connection where the retrieved one-time password value is passed to MFAPassCode connection property.

The following is an example connection string:

2.6 Authenticating with OneLogin

Set the AuthScheme to OneLogin. The following connection properties are used to connect to OneLogin:

• User: Set this to the OneLogin user.

• Password: Set this to OneLogin password for the user.

The following SSOProperties are needed to authenticate to OneLogin:

• OAuthClientId: Set to the OAuthClientId, which can be obtained by selecting Developers > API Credentials > Credential > ClientId.

• OAuthClientSecret: Set to the OAuthClientSecret, which can be obtained by selecting Developers > API Credentials > Credential > ClientSecret.

• Subdomain: Set to the subdomain of the OneLogin user accessing the SSO app. For example, if your OneLogin URL is splinkly.onelogin.com, enter splinkly as the subdomain value.

• AppId: Set to the ID of the SSO app.

• Region (optional): Set to the region your OneLogin account resides in. The OneLogin API operates in multiple regions and this property is used to find the correct domain. It can take one of the following values:

• • US (default)

  • EU

The following is an example connection string: The following connection string uses an API key to connect to OneLogin:

2.7 Authenticating with PingFederate

Set the AuthScheme to PingFederate. The following connection properties need to be set:

• User: Set this to the PingFederate user.

• Password: Set this to PingFederate password for the user.

• SSOLoginURL: Set this to the login url used by the SSO provider.

The following SSOProperties are needed to authenticate to PingFederate:

• AuthScheme (optional): The authorization scheme to be used for the IdP endpoint. The allowed values for this IdP are None or Basic.

Additionally, you can use the following SSOProperties to configure mutual SSL authentication for SSOLoginURL, the WS-Trust STS endpoint:

• SSLClientCert

• SSLClientCertType

• SSLClientCertSubject

• SSLClientCertPassword

Below is an example connection string:

The following are the connection properties for ServiceNow. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

3 Tables

The provider gets the metadata model in ServiceNow into a list of tables that can be queried using standard InitializeSource or Lookup activities.