Product: PowerShell Universal
I’ve got PSU and a UD running in IIS with Windows Authentication working.
Prior to this I was using the Authetication.ps1 and Roles.ps1 files to authenticate access to PSU and the UD - I could assign users to the PSU roles (Administrator/Operator/Reader) based on whether they were in certain AD groups (via the Roles.ps1 file). Then in the UD pages I was seting access based on which PSU role you were a member of. That was all good.
I want to achieve the same but now that I have single-sign-on happening via Windows Authentication I don’t think the Roles.ps1 files is referenced?
So my question is how do I assign the logging in user to a PSU role, when using Windows Authentication via IIS?
The $User variable is DOMAIN\User.Name
The $Roles variable is a list of all the SIDs of AD groups that the user is a member of
I’ve been going around in circles on the forums trying to suss it out but I think I might be looking at a lot of info related to v2 of UD.
Roles.ps1 is used for all authentication types. When using Windows Authentication, the claims will contain a list of SIDs (like you are seeing in the $Roles variable). You can use the HasClaim method on to access those SIDs and validate group membership to assign a role.
Here’s an example of using the SID directly: Security - PowerShell Universal
You can also look up the SID based on the group name to perform this comparison as well.
Thanks for the reply, Adam. I had some Out-File going on in the Roles.ps1 files to check what output was being generated - and after changing to Windows Auth I wasn’t seeing those files being generated/updated … and I think I’ve worked out why - after making changes to the Roles.ps1 file I need to recycle the app pool in IIS before the changes are reflected and I see the test output files being updated when I hit the dashboard.
I don’t think I needed to do that when using the forms authentication.
Now I can easily use the HasClaim to assign PSU role membership, woohoo!
Ahhh. You know, this is actually an documentation\behavior issue with PSU and you are entirely right that recycling the pool would work around it.
With forms auth there is a clear place to check claims: during the forms authentication. With Windows Auth in particular there is no great place to check claims in the ASP.NET Core authentication and authorization flow. We taken advantage of a Claims Transformation to allow for the roles.ps1 to execute and apply the new claims to the user object. The problem is the Claims Transformation happens on every web request. This is obviously a huge performance problem so we cache claims for certain amount of time so we can transform the claims based on the cache.
Most of the time this isn’t a problem since the cache time is short (10 minutes or something) and people’s groups don’t change much. This IS a problem when developing roles.ps1 and it seems like your changes aren’t taking effect…
EDIT: I will try and find a good place to put this in the docs. I think others are likely running into this.
Ohhh, ok yeah exactly exactly - that makes sense. Thanks for the super quick response and details.