Working with Access Keys
Access key creation is disabled by default but existing keys will continue to work.
Administrators can allow non-admin users to create their own access keys by enabling the Authentication/AccessKey/Creation/Enabled configuration parameter. Once enabled, users can create and delete access keys from their profile. Additionally, administrators manage access keys on behalf of other users in the Administration Panel.
If access key creation is enabled by your administrator, those access keys can 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 a single user (the owner of the key) and inherit that user’s permissions. Anything the user can do can also be done with their Access Key, with the exception of interactive access to Seeq via the web 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 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. However, this session duration can be configured by a Seeq administrator as needed within an organization’s security guidelines.
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:
{
"username": "<accessKey>"
"password": "<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 14 days, requiring users to log into Seeq within that period to using an Access Key.
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.
Enabling Access Key Creation
The enable the ability for non-administrator users to create their own access keys, override the value in the Authentication/AccessKey/Creation/Enabled parameter setting it to true.
When false, users can view and delete their Access Keys in the Profile > Access Keys menu but cannot create new keys. Administrators can still create them on their behalf in the Access Keys tab of the Admin Panel.
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.