Working with Access Keys
Access Keys allow users to authenticate scripts and OData when using Windows, LDAP, or OpenID Connect authentication. Note that Windows Authentication and LDAP support OData export to Power BI and Excel, but users working with OData receivers that are not a Windows product will be able to authenticate with the Access Key and associated password.
Access Keys are associated with only one user each and can be created and destroyed from the user’s profile or from the Admin Panel. An Access Key’s permissions are inherited from the user that owns it: i.e. anything a user can do, their Access Key can also do, with the exception of logging in to Seeq Workbench via the browser.
The password for an Access Key will only be displayed to the user upon creation and can never again be accessed. If a user loses their password, they can create a new Access Key and delete the old one.
Creating Access Keys
To create an Access Key, navigate to the user profile drop down and select Access Keys.
Provide a useful label for the Access Key that indicates its purpose. You and the administrators will be able to view this label.
Use the copy buttons beside the Access Key and Password text fields to save them somewhere safe. You will not be able to view the password again.
Use these in lieu of username/password when authenticating in Seeq for OData, scripts, and non-Seeq Data Lab use of the SPy module: The Access Key should be supplied as the username, and the Password as the password. If given a choice, you must specify the Seeq Directory when using an Access Key.
Delete Access Keys that you do not use through the Manage Access Keys pop up.
Note: Access Keys will only work if the associated user remains relatively active in Seeq. By default, Access Keys will only successfully authenticate with Seeq if the associated user has an active session or has logged in via the browser in the last 24 hours. However, this session duration can be configured by a Seeq administrator as needed within an organization’s security guidelines.
Coming soon in R61: access keys remain active based only on when the associated user last logged in, default to 14 days, and do not rely on a user having an active session.
Using Access Keys via the REST API
If using SPy from outside of DataLab, access keys can be used to login by following the documentation here: https://python-docs.seeq.com/user_guide/spy.login.html#access-keys.
Access Keys can also be used to log in via the REST API. Regardless of the authentication provider, the key is the username, and the password is the password. Therefore the payload to POST auth/login would be:
{
"password": "<accessKey>",
"username": "<password>"
}Make sure to note the AccessKeyValidityDuration as this can impact the duration of successful authorization.
Access Key Administration
Managing Access Keys
Administrators can view all access keys from the Access Key tab on the Admin Panel. This panel will show the user, Access Key label, date created, and date last used. It also indicates if the access key has admin privileges. Administrators can delete keys from this panel.
Administrators can adjust the amount of time after a user's login that an Access Key is valid. Due to the nature of single sign-on authentication, Access Keys are not interfacing with Windows Authentication or OAuth2 on behalf of the user when invoked. Instead, a default validity period is established and can be changed in the Configuration tab of the Admin Panel at Authentication/AccessKey/ValidityWithoutUserLogin. By default this is 1 day, requiring users to log into Seeq within the past 24 hours prior to using an Access Key.
Coming soon in R61: access keys remain active based only on when the associated user last logged in, default to 14 days, and do not rely on a user having an active session.
The system-wide duration configuration can be overridden on individual users by setting the AccessKeyValidityDuration property via the POST /users/{id}/update endpoint to the desired duration (in minutes). The user can be reset to use the system configuration by setting that property to -1.
Upon deletion of a user, Access Keys will be deleted and will not pass to a new user. This is to prevent deleted users from retaining access as a different user. If scripts or OData queries are operating on behalf of a user that is now deleted, new Access Keys will need to be generated and provided where the deleted keys were previously used.
Disabling Access Key Usage
Access Keys can be effectively disabled by overriding Authentication/AccessKey/ValidityWithoutUserLogin to 0 days in the administration panel as depicted below.
Access Keys can be disabled on individual users by setting the AccessKeyValidityDuration property via the POST /users/{id}/update endpoint to 0 minutes. This configuration takes priority over the system-wide Authentication/AccessKey/ValidityWithoutUserLogin configuration. Users will still be able to create access keys, however, they will not be able to use them.
Best Practice: Preventing Previously Authorized Usage
If a user is removed from a group or an authentication directory, then the best way to ensure that any active usages of Access Keys by that user (such as long running scripts) would be terminated is by removing that user from Seeq.