Best Practices for multiple permission sets for single script

Product: PowerShell Universal
Version: 4.1.8

Searched and didn’t find anything, although I was not certain what to search for. Testing out Powershell Universal in our org as a centralized place to manage automations with Powershell. Very new and likely missed something, but trying with the 14-day trial.

Question:
How can I execute a script with a different set of secrets or variables, based on the signed in user’s role?

Example:
A secret is created, servicePrincipalID.
A secret is created, servicePrincipalSecret.
For users with the Helpdesk role servicePrincipalID = “abc123”, servicePrincipalSecret = “def456”
For users with the Administrator role servicePrincipalID = “123abc”, servicePrincipalSecret = “456def”

A script runs and uses the servicePrincipal information that is available to the role the user is in.

This service principal is used to access resources and downstream services, any of them could provide a permission error if a helpdesk user tried to perform an action that only an Administrator can perform. (Specific example, changing an HR Employee’s password requires an Administrator service principal, the helpdesk one would fail)

You may be overthinking this. As long as both credentials are stored in the PSU Variables and thus available through the Secret scope, you can handle the Credential selection on the page itself. At the page load have a script section that checks the built-in $Roles variable. That will contain the roles the user is authorized for.

Depending on the match, you can then set a page specific credential variable to the stored Secret variable to be used as the authentication object throughout the page.

I would also look into the Protect-UDSection cmdlet if you have not already. As hiding options that do not apply to the user is usually better than having them fail with the wrong credentials.

Thanks, I appreciate the reply.

The issue I’ll have is some users that will have limited sets of permissions to systems (Ex Active Directory) but will need to be able to upload and edit scripts and pages. They could potentially be able to modify the script/page to change the role check and which secret to use for the page.

From my understanding we could get around this by using Git sync and having reviewers on the code to validate, which is probably the better idea anyway.

I will continue experimenting, thanks!

I have not used these personally besides reading about them, but I think it fits your scenario exactly. Use tags and scope the roles in such a way that the security pages are protected separately.

Honestly though, if they can edit the page that contains the references to the credentials, there is not much you can do about it. Only thing I could think of was to separate those actions out to another page or function perhaps and lock those down. Having a second set of eyes on the code commits and restricting access to the server itself would help there as well.