Jump to content
  • To Search the Seeq Knowledgebase:

    button_seeq-knowledgebase.png.ec0acc75c6f5b14c9e2e09a6e4fc8d12.png.4643472239090d47c54cbcd358bd485f.png

Search the Community

Showing results for tags 'access controls'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community Technical Forums
    • Tips & Tricks
    • General Seeq Discussions
    • Seeq Data Lab
    • Seeq Developer Club
    • Seeq Admin Forum
    • Feature Requests

Categories

  • Seeq FAQs
  • Online Manual
    • General Information

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Company


Title


Level of Seeq User

Found 3 results

  1. There are instances where it's desirable to add or remove Access Control to a user created datasource. For instance, you may want to push data from Seeq Datalab to a Datasource that is only available to a sub-set of users. Below is a tip how to add additional entries to a Datasource Access Control List (ACL) using `spy.acl`. 1) Identify Datasource ID If not already known, retrieve the ID for the Datasource. This can be done via the Seeq REST API (accessible via the "hamburger" menu in the upper right corner of your browser window). This is different from the datasourceId identifier and will contain a series of characters as shown below. It can be retrieved via the `GET/datasources` endpoint under the `Datasources` section. The response body will contain the ID: 2) Identify User and/or Group ID We will also want to identify the User and/or Group ID. Below is an example of how to retrieve a Group ID via the `UserGroups` GET/usergroups endpoint: The response body will contain the ID: 3) Use `spy.acl()` to add group to the Datasource Access Control List (ACL) Launch a Seeq Datalab Project and create a new ipynb Notebook Assign the two IDs to a variable datasource_id='65BDFD4F-1FA3-4EB5-B21E-069FA5A772DF' group_id='19F1B7DC-69BE-4402-AD3B-DF89B1B9A1A4' (Optional) - Check the current Access Control List for the Datasource using `spy.acl.pull()` current_access_control_df=spy.acl.pull(datasource_id) current_access_control_df.iloc[0]['Access Control'] Add the group_id to the Datasource ACL using `spy.acl.push()` spy.acl.push(datasource_id, { 'ID': group_id, 'Read': True, 'Write': True, 'Manage': False }, replace=False) Note I've set `replace=False`, which means the group will be appended to the current access list. If the desire is to the replace the entire existing ACL list, this can be toggled to `replace=True`. Similarly, you can adjust the read/write/manage permissions to fit your need. For more information on `spy.acl.push`, reference the `spy.acl.ipynb` document located in the SPy Documentation folder or access the docstring by executing help(spy.acl.push) (Optional) - To confirm the correct ID has been added, re-pull the ACL via `spy.acl.pull()` current_access_control_df=spy.acl.pull(datasource_id) current_access_control_df.iloc[0]['Access Control']
  2. 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 |
  3. Hello, creating comments in View-Only mode seems not to be possible, the "New Comment" button is missing in the Comments area.
×
×
  • Create New...