Authentication and Skuid¶

No Authentication¶

Select this option if your service is publicly available and does not need any type of credentials for access. This method could also be relevant for services that are behind a firewall and the data source has Use Apex Proxy unchecked.

Basic HTTP Authentication¶

While OAuth is the recommended authentication flow for most data sources, Skuid also allows for basic HTTP authentication—in short, sending encrypted user credentials to a data source to login.

Skuid encrypts all usernames and passwords using AES-256 symmetric encryption. Credential records are stored in Protected Custom Settings which are inaccessible to querying through any API—only Skuid internal code can access this information, and Skuid does so only when making authentication requests to data sources. Your company’s Salesforce administrator can change the encryption key from the Skuid Settings page.

With Basic HTTP Authentication, credentials are sent Base64 encoded as a header with every request. If you select this authentication method, Skuid will automatically construct the Authorization as shown below. For example, if a username of Aladdin and a password of open sesame were provided, Skuid would construct the following header.

1

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

When configuring basic HTTP authentication for a data source, you must specify a credential source. This can either be:

• Shared by all Site Users (Skuid NLX) / Shared Org-wide (Skuid SFX): If you want all end users to share the same username and password to access the external data system, select this option and enter the credentials on the form that appears below the picklist.
• Shared Per-Profile, with optional Org-wide Defaults: If you want end users to share a login based on a Salesforce profile, enter the credentials on the form that appears below the picklist. You may also enter default org-wide credentials.

Note

This credential source is not currently available on Skuid NLX.

• Per-User, with optional shared Site-wide Defaults (Skuid NLX) / Per-User, with optional Profile / Org-wide Defaults (Skuid SFX): Allows users to enter their own individual credentials for a data source, with optional default credentials available if needed.

  End users manually add their own credentials within the Skuid UI:

  • In Skuid NLX, credential management is done in My Settings > Username / Password Credentials.
  • In Skuid SFX, credential management is done in My Credentials.

API Key Authentication¶

Some services authenticate by requiring a special key be passed along in each request—this key being associated with certain permissions in the service. By selecting this authentication type, the API key field appears, which stores the given API key as an encrypted piece of data in Skuid. This key can then be used within any common HTTP header or body request data for the data source—where it will be securely injected server-side to prevent end users from seeing the key should they observe their network traffic.

• API key: The key to store

Once entered and saved, use the {{$Auth.API_Key}} merge variable to set up a common request header or body data in the format required by the service.

1

Authorization: Bearer <API_KEY>

Separate Authentication URL¶

With the Separate Authentication URL option, Skuid will first make a request to a separate authentication URL, which is expected to return an access token after successfully authenticating. This token can then be used on subsequent requests by updating the data source’s Common request headers and/or Common request body data to use the {{$Auth.Response.Body}} and {{$Auth.Response.Headers}} merge variables. You can also access nested parameters/headers through those merge variables. For more information, see the Authentication Merge Variables section

When configuring a Separate Authentication, you can (but are not required to) specify a credential source. This can either be Shared: Org-Wide, Shared: Per-Profile, or Per-User.

• If the Shared: Org-Wide setting is selected, then you will be prompted to enter the shared username and password.
• If the Per-Profile, or Per-User settings are selected, then the credentials need to be entered on a separate screen.

Authentication Provider (OAuth, Custom, etc.)¶

Authentication Providers in Skuid allow for the use of specialized protocols (like OAuth) or custom Apex Code to handle Authentication. Using Authentication Providers, Admins can configure OAuth connections or Custom Apex code.

Custom Apex Authentication¶

This option is currently only used internally to support the Sharepoint data source type’s custom authentication process.

OAuth 2.0 / Open ID¶

OAuth is an open source standard for authentication. It allows a third party (Skuid) to create models on services where Skuid never actually receives or knows the username or password required to access that service. The OAuth spec describes several different grant types (or flows) that can be used to gain access to a resource server (External Web Service).

1
2
3
4

Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
 "example_parameter":"example_value"
}

1

Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA

1
2
3

Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

AWS: Assume Role with ARN¶

This authentication method allows you to use the ARN of an assumable role instead of hard-coded AWS access keys. When a Skuid user makes a request using this authentication method, Skuid makes a secure server-side request to assume the configured role. If this request is successful, Skuid receives temporary access credentials, which Skuid caches until the credentials expire after 60 minutes.

Requests made through an assumed role are traceable via the AWS console. From there, you can see both the Skuid site and Skuid user who initiated the request, which provides AWS administrators full visibility into who requested access credentials and from what Skuid site.

Due to this method’s security and ease-of-management after initial setup, we typically recommend it over the access keys method. However, it does require some technical knowledge to configure. Be sure to read all of the instructions below.

Before you begin

Skuid can only access roles that have a defined path containing the string /skuid-assumable-role/ . This is different from the role’s name. Role paths can only be set when first created, so it isn’t possible to update an existing role with a new path.

In order to create a role with a path, you’ll need to use either the AWS IAM API or the AWS CLI.

The instructions below assume you are using AWS CLI (version 2) and that you’ve already configured an access key ID and secret access key for use with the CLI. Ensure these credentials have the iam:CreateRole permission. Command line examples are also tailored for Linux or macOS operating systems; commands for command line programs on Windows may differ.

Finally, because IAM roles require a trust relationship policy upon creation, you’ll need to save the JSON that Skuid provides when creating an authentication provider. Because of this you’ll need to navigate between your browser window, your computer’s file explorer, as well as the command line.

In Skuid

1. From the Skuid navigation bar, navigate to Data Sources > Authentication Providers.
2. Click Create.
3. Configure the authentication provider’s basic properties:
   • Name: Enter a name, such as AWSAuth.
   • Authentication Method: AWS: Assume Role with ARN
4. In the Trust Relationship Policy, click Copy to Clipboard.

This copied policy will enable your role to grant proper access to your Skuid site.

"sts:ExternalId": "09583eba-de0e-49d3-ae42-61b3927a61b1"

"sts:ExternalId": [
   "09583eba-de0e-49d3-ae42-61b3927a61b1",
   "e354e60f-5a80-4024-b01a-4cae13d0948c"
]

On your local machine

1. With the policy copied to your clipboard, paste the policy into a text editor.
2. Save the file to an easily accessible directory (for example, your desktop) on your machine with a recognizable name and the JSON file extension, like trust-policy.json

In a command line interface

With the trust policy saved to your machine, you can now use the AWS CLI to create an assumable role.

1. Open your command line program of choice and navigate to the directory containing your policy JSON file. For example, if you saved the file on your desktop:

   1	cd ~/Desktop

2. Use the AWS CLI’s iam create-role command to create the role with the proper path value and trust relationship policy:

   1	aws iam create-role --role-name Skuid-S3-Access --path /skuid-assumable-role/ --assume-role-policy-document file://trust-policy.json

   Note

   While role-name can vary from this example, the path must contain /skuid-assumable-role/

   The CLI creates the role, outputting its ARN and other related metadata. Because of the configured path, your ARN should look similar to this: arn:aws:iam::1234567891011:role/skuid-assumable-role/Skuid-S3-Access.

3. Copy this created ARN, either from the command line output or the AWS console.

In Skuid

1. Return to the authentication provider window.
2. Paste the copied ARN into the AWS Role ARN to assume field.
3. Click Save.

AWS: Access Keys¶

This authentication method utilizes an Amazon Web Service (AWS) IAM role’s access keys to authenticate to an AWS system.

If you are not the manager of your AWS services, follow along with Amazon’s steps for creating access keys with your IT administrator. You’ll need to do the following:

In AWS

1. Create a new group and select the appropriate policies for that group.
   • These should align with your intended Skuid use. Ensure your access policies match the services (S3, DynamoDB, or SNS) you’ll be using.
2. Create a new user in AWS Identity and Access Management (IAM) within the newly created group.
3. Retrieve the access credentials generated for that user:
   • The secret access key is only displayed once, immediately after the access key is generated, and cannot be found later. Be sure to copy it to a safe place.

In Skuid

With your access credentials handy, you can now use them to configure a Skuid authentication provider that will work with all AWS data sources.

1. Navigate to Configure > Data Sources > Authentication Providers.
2. Click New Authentication Provider.
3. Configure the authentication provider’s basic properties:
   • Name: Enter a name, such as AWSAuth.
   • Authentication Method: AWS: Access Keys
4. Enter your IAM role’s credential information:
   • AWS Access Key Id: The access key ID to use when authenticating.
   • AWS Secret Access Key: The secret access key to use when authenticating.
5. Click Save.

Removing stored OAuth access credentials¶

To remove stored OAuth access credentials for a particular service, call the following method:

skuid.oauth(provider_type_or_name).logout();