Restricting add-ins to specific users

Ben Regier
Ben Regier
Sixth Anniversary Kudos 5 Name Dropper Participant
in SKY Developer General Discussions
Just curious about the best way to restrict add-ins to specific users in RE NXT.  The documentation mentions whitelisting specific User IDs and using that to determine whether or not an add-in is displayed.  Is that the recommended method, or is there a way to set access to specific add-ins in the Security or Roles areas?

Comments

  • Ben Lambert
    Ben Lambert
    Ninth Anniversary Kudos 5 Name Dropper Participant
    HI Ben,


    Great question - add-ins are instantiated before being made visible, which provides a hook for you to perform some logic on your end before reporting "ready" to the host application.  You can leverage the context available at that point to determine if the add-in should be shown.  That context includes the environment ID and user identity token as well as the values in the context object defined by the extension point.  You can even make API calls (if you already have a SKY API access token) and use those results to determine if the add-in should be shown.


    That's what is supported today - but we'd be very interested in getting more details about what you'd ultimately like to accomplish to help inform how we might expand what we have today to accommodate other scenarios.  For example, you mention controlling add-in visibility using the security/roles functionality - any more details/thoughts you could articulate around how you'd envision that working?  
  • Ben Regier
    Ben Regier
    Sixth Anniversary Kudos 5 Name Dropper Participant
    The end goal is to add a button to RE NXT on constituent pages, that, when clicked, would trigger a process that would update that constituent's information on a SharePoint list that we use for a web application.


    However, there are only 4-5 RE users who will be using this button, and I think its presence would confuse the other users, so I'd like to hide it for everyone else. 


    At first I thought that adding applications was something that was done by a user-by-user basis, so it would be as simple as having only the relevant users add the application.  But of course I quickly learned that applications are added for the whole environment, not on a user basis.  Then I checked in the Security section because I know there are some parts of the constituent page (such as gifts) that can be hidden based on security roles.  But I didn't see anything there for applications.


    Using the user identity token can certainly work for what I need.  Only downside is that it's a bit more difficult to manage when there are changes.  I'd need to create some internal documentation so the rest of our IT team will know where and how to make updates when there are staffing changes.
  • Ben Lambert
    Ben Lambert
    Ninth Anniversary Kudos 5 Name Dropper Participant
    Thanks Ben, this is helpful.


    Yes - as you discovered, an application is "connected" at an environment-level (and is thus, an admin-level operation).  Any add-ins defined by the application are provisioned for the environment, and will be seen (meaning, instantiated) for all users.


    I definitely recognize the challenges with white-listing user IDs though - what would be a simpler/better solution?  Would you prefer more of a developer-facing approach, where your add-in could get the current user's roles at runtime (maybe provided via additional context, or returned along with the user identity token)?  This would allow your code to perform some evaluation like "if user in <role 123> then show me otherwise hide me".


    Or would you envision this being more of an admin-facing choice, where an admin-user would have the ability to configure add-in visibility in the Security/Permissions area?  
  • Steven Cinquegrana
    Steven Cinquegrana
    Tenth Anniversary Kudos 2 Name Dropper Participant
    Hi Ben‍. I'm 1000% in favor of some means of user-contextualizing a lot of things, including add-ins, but also general integrations where user access/permissions can be controlled in code. I think this is very sorely needed.


    This could be part of a Utility API, I would think, where a user's permissions, roles, etc can be checked.


    Having only admin-facing configuration options would be a bit limiting, I think, if it was determined per-user (rather than, say, per-role) but would be better than nothing.


    Cheers,

    Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

     
  • Ben Regier
    Ben Regier
    Sixth Anniversary Kudos 5 Name Dropper Participant
    Being able to restrict add-in visibility by role rather than by user would be nice.  As to the choice between putting it in an admin-facing vs. developer-facing space, I'm not sure I have the most valuable feedback.  I work for an org where I'm the only person doing this type of development, so for that reason an admin-facing option would be nice for us because it would allow others on the team to help manage things without digging into the code.  But I'm not sure this is a decision that should be made based on our specific use-case.  I can see that there could be strong arguments that a developer-facing approach could be more flexible and powerful in the long run.


    In short, I trust your judgement on this more than my own.


     

Categories