Skip to Main Content
Spotfire Ideas Portal
Status Future Consideration
Product Spotfire
Categories Library
Created by Guest
Created on Jul 19, 2016

Library Permissions Requiring Multi-Group Membership

Currently - if I have three groups on a folder, a user only has to be a member of one to access the analyses inside.  So it is a Group A OR Group B type configuration.

We would like to be able to set it up as an AND arrangement so must be in Group A AND Group B.  This is essential when you re-use your groups in a security matrix type approach (so combinations of groups provide access)... otherwise... we have to either nest folders in folders in folders to achieve the same outcome which is not great... difficult to manage in a large enterprise like ours... OR we need to triple the number of AD groups we use... our help desk would murder me.. also difficult to manage.

So if you had a check box or toggle button on the permissions sections for access/browse/etc to make the list of groups either AND or OR ... that would be a fantastic addition.

 

  • Attach files
  • Guest
    Reply
    |
    Nov 14, 2016

    Thanks Christian, we have already written a work around through a custom web portal that replaces the Spotfire BI portal and uses a custom authenticator and various library services to extend our AD model. We have done this so that our AD access matrix persists over our data warehouse and spotfire and other technologies (such as SAP, SAS, etc) without maintenance and is effectively agnostic of the accessing system. Spotfire is the only one that is a little messy because of the simple library folder level security.

    Our requirement is additive in that we want users to be in all groups to access a folder - it should be more than one group one folder IMHO.

    The easiest approach is as per this idea but appreciate your feedback. it's not that we can't do what we're describing, we certainly have - its that this feature would provide greater flexibility to using multi-group membership to secure assets rather than multiple groups over multiple folders.

    Thanks again for your suggestions, appreciate the ideas.

    Cheers.

    Sent from my Samsung Galaxy smartphone.

    -------- Original message --------

  • Guest
    Reply
    |
    Nov 14, 2016

    BTW is your security matrix is already stored/maintened on another system (as it is in our case) you could avoid having to duplicate this data in the Spotfire metadata DB and use official APIs to replicate the permissions in Spotfire

    The UserDirectoryService API will let you create groups and add/remove members from them. And the  LibraryService API will let you create folders and set permissions on them:

    https://docs.tibco.com/pub/spotfire_server/7.7.0/doc/api/TIB_sfire_server_WebServices_API_Reference/index.html

     

  • Guest
    Reply
    |
    Nov 14, 2016

    OK I see. The problem I got with your idea is that it goes against how most permissioning systems work. In most systems permissions are always additive. You seem to have a very edge case which perhaps needs a custom solution. The way I would do it will be like this:
    - Continue to define your AD groups in the way you do it now as this is the most effective way to minimise the numebr of AD groups you need to use/create.

    - Create new local groups in Spotfire which will map to security roles in your security matrix.

    - Store your security matrix in the Spotfire metadata DB.

    - Develop a procedure which will add/remove users to the new local groups. This proc will read the security matrix stored Spotfire metadata DB and only add a user to a group if the user is a member of all the AD groups for that role as per the matrix mapping, not just some of them. Adding and removing users to Spotfire groups can easily be done by inserting/deleting from the GROUP_MEMBERS table.

    - Execute the procedure at defined intervals to match your LDAP group sync schedule.

    - Amend your library permissions to use the new local groups removing all the nested layers and complex permissions.

     

    By creating an abstraction layer between the AD groups and your security roles you can achieve what you want. With this model new roles or AD groups will simply need to be setup in the security matrix in the Spotfire metadata DB reducing your overhead considerably. There will be no changes to the Spotfire library permissions. AD groups should be created automatically in Spotfire as long as you are using the group-search-filter property and use wildcards on the group names in your LDAP configuration.

  • Guest
    Reply
    |
    Nov 14, 2016

    Thanks Christian. Because of the complexity of our organisation we definitely can't get away with mostly single groups. Our AD access and security model is complex and filters data and access by LOC (location), SYS (system), AM (role), COL (data collection).

    Therefore to access a report through spotfire (SYS-SFR) that is around Emergency Department Activity (COL-ED) and it relates to Country Hospitals (LOC-COUNTRY) ... currently we have to nest the folders with different. groups on each folder. u necessarily messy.

    We do apply real-time filtering of data too within a spotfire analysis so it only shows the user data based upon users LOC membership but ... currently ... folder permissions are too simplistic and the option for AND/OR group permissions would be very useful.

    Sent from my Samsung Galaxy smartphone.

    -------- Original message --------

  • Guest
    Reply
    |
    Nov 14, 2016

    We use AD groups in a large enterprise setup and never found the need to use them they way you describe. We have two types of AD groups, functional and access. Functional groups determine what you can do, so give licenses to Web Player or Spotfire Client and the like. Access groups determine what you can see woth in terms of reports and data. We re-use all AD groups in a security matrix for each Spotfire application. For example you can have the Web Player AD group with access to App1 and App2 or the Prof Client AD group with access to App2 and App3. I don't see how this would require us to triple the number of AD groups.