Hello! After upgrading to 5.6.1, there are no more role names in the $Roles variable (only SSIDs). In previous versions, in addition to the SSIDs, there were also role names. It seems to me that something is broken. We are using an installation on IIS.
While I see several issues with 5.6.1, this one I can’t confirm.
A made an app page that shows me all relevant variables and ENV and script vars.
$Roles is populated for me as it was before.
How do you assign roles?
I guess that would be related.
We use SAML2 and I have a script under security/roles for each role that checks the claims and returns true or false.
Hello! Thank you for your reply and willingness to help. I would like to point out the following:
This method of assigning roles works completely in both PU3 and PU4 (tested on 4.4.1). On them I see both group SSIDs and role names in Powershell Universal. On version 5 only SSIDs remain.
For example, with Windows authentication, if you wanted to map a group to a role, you could configure it such that the group SID maps to the administrator role.
Copy
New-PSURole -Name Administrator -ClaimType 'http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid' -ClaimValue 'S-123-123-123'
Mapping roles to claims in this manner is faster than Policy scripts because it does not require PowerShell to be run when the user is logging in.
We have authorization on the portal itself (i.e. if I go to %portalname%/admin, the required role is assigned). The role is not forwarded inside the dashboard\application only.
It seems to me that this is still a bug in version 5. I tried to install 5.6.0 - the problem is still there.
We just upgraded to v5.6.7 and we’re experiencing this issue. The contents of the $Roles variable is SIDs. We are mapping on-prem AD claims. Roles are not mapping to SIDs so in our App page when using “if ($Roles -contains “Role Name“)” it’s not working (i.e., card is not appearing on the page).
I just tried in v5.6.6 and we’re seeing the same issue. We are having to do “if ($Roles -contains “”)” to get it to work, but this defeats the purpose of defining a role.
My previous screenshot only shows a small subset of the roles that are output by the code you provided. It’s actually a very long list of SIDs. Where are all the SIDs coming from?
In addition to the long list of SIDs, $Roles only contains the following named roles. I can’t figure out why the latter two still appear.
Administrators (this one does exist and my account in PSU is a member of it.
PSU-ADAccountUnlockTool - ROLE DOES NOT EXIST
Test - ROLE DOES NOT EXIST
Controlling component visibility is not working for the following reason:
Claim Value - S-1-5-21-1000589339-1611067580-1395766070-97068
When I run the new-udtypography you provided, “AD Unlock Tool Access” does not appear in the list of roles for my account.
When I use the if statement in the code below, the card does not appear. When I change “AD Unlock Tool Access” to the SID of the AD group (i.e., the Claim Value) in the if statement then the card is becomes visible. I confirmed that my user account is a member of the AD group with that SID.
Additionally, using role names in the if statement worked in PSU v2, but it stopped working when we upgrade to v5.6.6 and v5.6.7.