Skip to main content

Introduction

Occasionally, various external applications need to rely on Curator to authenticate users for them. Curator provides a simple interface to determine which user is currently authenticated to Curator, and provide information to your external application about that user. This is particularly helpful for applications that need to keep user authentication in sync with Curator, such as custom applications embedded within Curator. Retrieving information about the currently authenticated user requires two API calls to Curator:
  1. First, your application must forward the user to Curator’s /fetchUser endpoint, with a redirect_url parameter. Curator returns the user to the redirect_url with a payload GET parameter containing a JSON wad containing an identifier token.
  2. Next, use the token value from this JSON wad to call Curator’s /user/getUser endpoint to retrieve the user’s information.

Important Setup

In order for the redirect to work, you must whitelist your domain in the Curator Portal Settings. Navigate to the Settings > Curator > Portal Settings section from the left-hand menu. Under the General tab, expand the Security section.

Whitelisted Redirect Hosts

The Whitelisted Redirect Hosts setting lists the external hosts Curator is allowed to send users to. Curator compares the target host against that list before issuing a redirect, and refuses any host the list does not cover. Each row of the repeater holds one Host value, entered as the host portion of the URL, for example https://www.example.com. Add a row for every domain you send users back to.
Delete any repeater row you are not using. A saved row with a blank Host permits every host, which turns the whitelist off.
Curator permits some hosts without any configuration:
  • The host of the current request.
  • The Forced Curator Domain setting, when one is set.
  • The root URL Curator has stored for itself.
  • localhost and 127.0.0.1.
  • The APP_URL value from the server environment. On-Prem administrators set this value, and InterWorks manages it on SaaS.
  • Tableau Server URLs and their alternate URLs, from each active Tableau connection.
  • https://login.microsoftonline.com, when Power BI is configured.
  • The SAML sign-on, alternate sign-on, logout, and ACS URLs, when SAML authentication is in use.
  • The OAuth domain, when OAuth authentication is in use. Curator also permits the identity provider’s end-session endpoint while signing a user out.
Matching follows these rules:
  • Both http:// and https:// are allowed for every row, so one row covers both protocols.
  • The www form and the bare domain are paired in both directions. Adding example.com also permits www.example.com, and adding www.example.com also permits example.com.
  • Subdomains are not included. example.com does not permit reports.example.com, which needs a row of its own.
  • Only the host is compared. A port in a row is ignored, so example.com is permitted on any port.
A blocked redirect raises an error instead of sending the user on, and Curator records a Blocked redirect to <URL> warning. Read it in the backend Event Log, or on disk in the System Log at storage/logs/system-YYYY-MM-DD.log (On-Prem only). See Server Logs for the path on each operating system.

/fetchUser

HTTP REDIRECT [your_domain]/fetchUser?redirect_url=[group_name_here]

/user/getUser

Returns the currently logged in user’s information. POST [your_domain]/api/v1/User/getUser?apikey=[your_api_key_here]&token=[token_here] Returns: array

Example Authentication Script

API Rate Limiting

Curator rate limits every API request that includes an apikey parameter. Requests that do not send an apikey parameter are not rate limited. When a request is refused, Curator responds with HTTP 429 Too Many Requests and this body:
The same message is returned no matter which limit was reached, so the response never reveals whether the API key that was supplied is a valid one.

Two limits apply

Curator tracks two separate counters, and a request must pass both: The global counter is checked first, on every request. It is incremented even when the API key turns out to be invalid, so repeated calls with a bad key still consume the site-wide allowance.
The global counter is shared by the whole site rather than tracked separately per caller. A single busy integration can therefore use up the allowance that every other API consumer depends on.

Global settings

To customize the global limit, navigate to Backend > Settings > Security > Authentication Settings > Customization section. With the default values, Curator allows 500 API calls per minute across the whole site.

Per-API key override

An individual API key can use its own limits instead of the global ones. Navigate to Settings > Curator > API Keys, edit a key, and find the Rate Limiting section:
  • Rate Limit - Max Calls (override global)
  • Rate Limit - Timeframe (minutes, override global)
Leave either field blank and that key falls back to the matching global value. Because both counters are enforced, the lower of the two limits is the one a caller reaches first. Raising a key’s limit above the global limit does not allow it to exceed the global allowance.

When a counter resets

A counter resets once a full timeframe passes with no calls counted against it. Continuous traffic does not roll the count back, so a caller that keeps making requests keeps accumulating until it reaches the limit. Once a limit is reached, further calls are refused until the timeframe has elapsed since the limit was hit.