Jump to content

Restricting Access to Datasources Based on Authentication Mechanisms

Recommended Posts

  • Seeq Team

Seeq administrators often limit the access of people to Seeq based on an external authentication system. Some examples of this are Windows Authentication, LDAP Authentication, or the built-in Seeq authentication. These mechanisms only limit access to Seeq, not access to the datasources or items within Seeq. Here, we'll discuss how to restrict access to datasources based on user groups developed through authentication mechanisms.  

Step 1: Creating the group in Seeq

First, we'll have to ensure the group is brought into Seeq. If using Seeq Authentication, please refer to https://support.seeq.com/space/KB/239304838/Users%20and%20Groups#Creating-Groups. If not, the external authentication mechanism will only bring in the groups that are the children of the groups that are allowed access. For example, if "Seeq_Users" and "Seeq_Admins" are two groups underneath "Seeq" and "Seeq" is the group allowed by the authentication mechanism, then "Seeq_Users" and "Seeq_Admins" will be brought in as groups. Note that "Seeq" will not be brought in as a group, only its members will be brought in.

In the case that "Seeq" would also want to be brought in as a group, as of Seeq version R22.0.45.00, you can modify the IdentitySynchronization parameter to specify bringing in the "Seeq" group. An example configuration is shown below where the "DOMAIN\\Seeq" is being brought into Seeq as a group too. More information can be found in https://support.seeq.com/space/KB/554041498/Identity%20Synchronization%20using%20Windows%20Authentication%20Connector

  "Version" : "com.seeq.link.connectors.windowsauth.config.WindowsAuthConnectorConfigV1",
  "Connections" : [ {
    "Name" : "Windows Auth: grant access to only specified Windows groups",
    "Id" : "7393a87e-611a-4f43-b4a5-20e56f28f5d3",
    "Enabled" : true,
    "Indexing" : {
      "Frequency" : "1w",
      "OnStartupAndConfigChange" : true,
      "Next" : "2020-03-13T16:55:31.050979100Z[UTC]"
    "Transforms" : null,
    "VerboseLogging" : false,
    "AllowGroups" : [ "DOMAIN\\Seeq" ],
    "AllowUsers" : null,
    "IdentitySynchronization" : {
      "Enabled" : true,
      "GroupsToSync" : [ "DOMAIN\\Seeq" ]
  } ],
  "Help" : "For examples and documentation, see https://telemetry.seeq.com/support-link/wiki/spaces/KB/pages/420053401"


Step 2: Datasource Permission

After the group is available in Seeq, we can restrict who has access to the datasource. The steps listed below discuss the connector property transform approach but additional methods are discussed in https://support.seeq.com/space/KB/596607096/Datasource%20Permissions.

The connector property transform is applied on the connector json file located on the Seeq server or remote agent. In the example below, we are modifying all items within the datasource so the "Everyone" group has read access. Note that this security is appended to existing access control, not replacing it. 

"Transforms" : [ {
    "Inputs" : [ {
      "Property" : "Name",
      "Value" : ".*"
    } ],
    "Outputs" : [ {
      "Property" : "Security String",
      "Value" : "Auth/Seeq/Everyone:r,rd",
      "UnitOfMeasure" : null
    } ],
    "Enabled" : true,
    "Log" : false
  } ]

The value of Security String can be applied to any group where "Auth" is the datasouceClass of the authentication mechanism, "Seeq" is the datasourceID of the connection, and "Everyone" is the dataID of the group. For Built-in Seeq Authentication, these items are based on readable names but for external authentication mechanisms these tend to be GUIDs.

The datasourceClass tend to stay the same without any purposeful modifications. The table below outlines the typical configuration and their mappings.

Authentication Mechanism datasourceClass
Built-in Seeq Authentication Auth
Windows Authentication Windows Auth
LDAP Authentication LDAP
OpenID Connect OAuth 2.0

The datasouceID will vary based on the connection specified in the json connector file. You can access this in the connector json file through the ID of the connection or by going to the Seeq API Reference and querying the endpoint GET /datasources with a filter for the datasourceClass. 

The dataID will also change for each group. There is a two part process for accessing this dataID. First, you will have to get the Seeq ID from the endpoint GET /usergroups . You can filter the query by the name of the group you're looking for. There you can copy the id. This id is located in the group json section, not in the datasource. This id should be a Seeq ID, meaning it contains uppercase alphanumeric characters. Second, you paste this id in the GET / usergroups/{userGroupId} to get the dataID of the user group, which will be located towards the bottom of the response body.

With these items, you can modify the security string value and specify the level of access with r,rd being read, read data, w,wd being write and write data and m being manage. Additional groups can be separated using |  

  • Thanks 1
Link to comment
Share on other sites

  • 10 months later...

Not exactly similar to this topic, but i was enabling the kerberos authentication on the windows based Seeq system. The guidelines mentioned in the article for authenticiation has been completely followed, including getting SPN registered, service account and NTLM has been working fine so no issue of trust. After getting the SPN done, the browser is still asking for a login credentials. Is there anything else that need to be done to make it SSO, as the steps mentioned on Seeq article does not seem to fulfil the task? Any help will be good. Thanks! 

PS. i am trying to use a different computer in the network to test the kerberos and not the seeq machine as suggested in the article.

Link to comment
Share on other sites

  • Seeq Team

Hi Muhammad, I'd recommend emailing support@seeq.com for further assistance so a member of our System Reliability team can schedule a meeting with you to look over the issue. Feel free to copy and paste exactly what you've wrote here and suggest times for a potential meeting.

Link to comment
Share on other sites

  • Seeq Team

Hi Muhammad,

After configuring the SPN there are two more steps required to enable Single Sign On.  The Windows Authentication KB article links to these steps.  I have also included them here.

First you must configure a default Login Directory.  Secondly you must enable Auto-Login.

If Single Sign On does not work after these configuration changes are applied (or if you would like support enabling them) please email support@seeq.com to open a ticket.


Very Respectfully,


Mike Cantrell

Link to comment
Share on other sites

Thanks a lot for the response. Yes the same article I used to configure. Even after getting all the steps done, auto login and default id as well set, and testing from my separate machine, it is still prompting username password to login. will try to raise a ticket for the matter, in the meanwhile if you can direct anything i can check, i have checked the SPN setting and service account used, it is correct, what else could be checked?




Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...