Best way to use Variables/Secrets in Security (Authentication and Roles)

Product: PowerShell Universal
Version: 5.6.13

Hello! I am trying to integrate/use AD Groups for Authentication and Setting Roles. I have found the claims that are passed in for the user, so I can get the SID’s of the groups that the user is a member of. I have a Dev and a Prod PSUniversal server, and I am using different AD Groups for each one as I am being much stricter on who has access to my prod installation. I am hoping to re-use as much code as I can, so I don’t want to hardcode the SID’s into the Role checking code, so I was hoping to load the SID information into a HashTable and then store that as a variable (or a secret) that I could then use in the Role script to check against. Ideally I would like to do something like this:
foreach ($Claim in $User.Claims) {
if ($Claim.Value -eq $Roles.Administrator) {
return $true
}
}
The idea is that I can have that same code block in the Administrator Role Script for both environments, but I could just update the $Roles.Administrator value to the SID of the AD Group for Prod or Dev. I tried creating a variable, but it doesn’t seem to be accessible from the Security functions. I thought about setting up Windows Environment Variables, but that would require Admin Rights on the box and I was hoping to do this all through the app. I did see one thread about configuring security to run in a separate PowerShell environment that I could then inject the variables in to, but I feel like that would add a lot of overhead if we had to wait for a PowerShell environment to spin up every time someone logged in?

Hopefully that makes sense.

Let me know if you have any questions on what I wrote and if you have any thoughts on how to accomplish what I am trying to accomplish efficiently! I can also provide some more code for clarity, but didn’t want to bog the thread down too much.

Thanks in advanced!

-Jeff

Hey Jeff, not quite sure I understand youre requirement.
But basically I use Strict mode (an app setting) and apply roles to my variables which restricts specific variables to specific individuals/roles. (same as other resources like apps and api’s etc)
I use OIDC and the entra group ID’s to define the entra groups to roles in PSU (but equally you could use SAML and define the groups/members in entra instead)
It’s been fine for me, though my only gripe has been that schedules and triggers cannot access variables that have roles/permissions assigned to them, but I’ve just seen in a recent comment this will be coming in the next update.

Potentially if you want to use the same roles behaving differently in different environments you could have those persisted to the database, (havent tried but I assume this will work)
see database resource persistance: Repository | PowerShell Universal

Hi, thanks for the Response! I am working a little earlier in the process when the users are logging in and they are getting their Roles assigned to them, and I think that is my problem. The variables file is getting loaded into PSU after the Security Files are loaded, and possibly loaded in a seperate thread/environment so they aren’t accessible in the Security Scripts since they are loaded earlier in the application startup sequence. I just attached a screenshot of my possible work around for my issue, and hopefully that will explain what I am trying to do better? I might be able to add it in the Initialize.ps1 that I just found a reference to, so I might wander down that path for a bit and see if it’s worth pursuing, or maybe just stick with what I have now.

Thanks again for your response!

-Jeff