Security by Roles for Add in Button- HTTP request (low code)

Carol Grant

I have an Add In Button application tied to a Constituent Record. It then sets off a Power Automate flow which merges to a Word document. I have it validating a user token in the flow.

My supervisor wants this limited to only users that have a certain security role. I have seen the Authorized Users part of Glen's AIO flow but I would have to list each person that is authorized which would take some time and maintenance.

Can this be done somehow and if so what do I need to do? I need a “low code” option. Or something I can paste into my flow even though I made not understand it. ?

Tagging @Glen Hutson and @Ben Lambert in case you can help me

Any help would be appreciated!

Carol Grant

Middlebury College

Glen Hutson

@Carolyn Grant:

I have an Add In Button application tied to a Constituent Record. It then sets off a Power Automate flow which merges to a Word document. I have it validating a user token in the flow.

My supervisor wants this limited to only users that have a certain security role. I have seen the Authorized Users part of Glen's AIO flow but I would have to list each person that is authorized which would take some time and maintenance.

Can this be done somehow and if so what do I need to do? I need a “low code” option. Or something I can paste into my flow even though I made not understand it. ?

Tagging @Glen Hutson and @Ben Lambert in case you can help me

Any help would be appreciated!

Carol Grant

Middlebury College

Hi Carolyn. Right now, the only option we have is to identify the users individually. Though my examples have the authorization in-flow, @Dan Snyder has discussed a way of using a Sharepoint list to track authorizations. Though you will need to still list people individually, it means that you don't always have to be accessing the flow to update permissions.

Carol Grant

@Glen Hutson and @Dan Snyder - I should have known to ask Dan for a solution! ?

Thanks Glen- I think that will work using a Sharepoint list. I'll get with Dan.

-Carolyn

Dan Snyder

@Carolyn Grant @Glen Hutson While I would love to take credit for the SharePoint idea, I think that was @Alex Wong.

Alex Wong

@Carolyn Grant
This is what I do:
I created a SharePoint list, which has the following columns:

The main one to worry about is “Access Grant To” and "Access To Group". Access Grant To is of type Person or Group, which is defined to be People Only, while Access To Group is same concept but is defined as People and Groups.

The reason for 2 is, I have not fully figure out how to know if someone belong in a group (office 365 group), so for now for ease of use, I am only using Access Grant To and able to list multiple users.

In flow, I have the follow actions prior to adding to the AuthroizedUsers variable in Glen's AIO:

the expression used in AuthorizedUser variable is:
join(body('Select_Only_Email_of_Access_Grant_To'), ',')

Carol Grant

@Alex Wong- You rock!! Thank you!!

Actually quick question- did you manually keep this up to date? Add new users, etc?

Alex Wong

@Carolyn Grant
I am also the admin of all tech systems so I keep the responsibility of who get access to what, meaning yes I update the SharePoint list on who get access to various apps I built.

if you want someone else to control who have access, you only need to give access to the SharePoint list to that person and they can manage the adding removing of access. The flow does not need to be edited/updated so no one need access to the flow.

Alex

Ben Lambert

@Carolyn Grant In addition to the (good) responses given on this thread, make sure Blackbaud gets your feedback on how you'd like to incorporate security into this concept. For example, if you knew up front that the button should only be visible for users in a role named “Special Users”, then maybe Blackbaud could implement the ability for you (as the author of the add-in) to express that as a configuration option via a new query param when configuring the addin. For example, &securityRole=Special%20Users. This approach would result in the Blackbaud “host application” having enough info to know to hide the button at runtime. There are other approaches I can envision as well, but this is where it's important for BB to get your feedback to evaluate the most appropriate implementation.

Carol Grant

@Ben Lambert- love the feedback Ben. That would be great approach if I could do it right in the app permissions. I actually was hoping for a separate section in the app which lists out our specific security roles I could check which ones can access the button.

What would be the best way for me to give this kind of feedback? Idea bank, email someone directly?

Ben Lambert

@Carolyn Grant I would file it in the Idea Bank, something like:

I'd like an admin-facing mechanism in-product to express “only show <this add-in> for users in <these roles>”.

That is one of the other approaches that has been discussed in the past. A developer registers a SKY application that includes add-ins, an org-admin-user connects the application to an environment, and a security-admin-user can then configure add-ins visibility in-product on a per-role basis (lot of moving pieces Blackbaud would need to build but sounds like that's your preferred approach).

tagging @Ben Wong and @Chris Rodgers just for visibility.

Chris Rodgers

@Ben Lambert Thanks for the tag, Ben!

@Carolyn Grant, as Ben mentioned, this is an idea that we collected in our backlog as an enhancement to explore this year. @Ben Wong and I will discuss our timeline next week.

Ben Regier

@Chris Rodgers @Ben Lambert

I'm a big fan of this idea!

Ben Wong

@Ben Regier this is definitely on our radar and we're hoping to focus on it later this year. We'll definitely reach out to the folks on this thread to get input into the design process. Thanks!

Carol Grant

@Ben Wong- Thanks all !!