More trouble with Authorization Policies

I’m using UD version 4.5.3, and attempting to deploy a dashboard to a server running IIS. I’ve got two pages in the dashboard, and have configured a login page using the Windows auth method. I have an authorization policy using a group claim attached to one page and none to the other. When I visit the dashboard I can load the page that does not have an authorization policy, but the page with a policy does not load.

I have tested the group claim in the design terminal like this:

$ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-2640144-4251154575-3834474851-6258")

This evaluates to $true so I’m not sure why the page would not be authorized. Is there a way to troubleshoot this a bit further using the design terminal? Is the UD dashboard object available in any way to inspect the pages or other elements that have been added to it? Thanks!

On a side note, I noticed that the help for New-UDPage does not include the -AuthorizationPolicy parameter details. I’m wondering if I should be using -Authorizedrole instead?

Hello @mattmcnabb good to see you back. I know you got proper skills, but this is kind of being discussed here:- Multi-layer authorization on forms || UD 2.5.3
I am using Windows Active Directory authentication, then dynamically displaying menus based on AD security group. Hopefully this might give you a different approach. I never used the method you are using. Peace

1 Like

@psDevUK thanks for pointing out the other post! I might take a look at using the AuthorizedRole instead of policies, but regardless, I need to figure out a better way to troubleshoot or debug these issues. My problem is that I develop locally without auth and then push my dashboard to source control where it is then deployed to web servers. So I generally have to push new commits to perform any testing of changes.

I think for next steps I’ll try to enable logging to see if I can find anything there to indicate the problem.

1 Like

Ok, I think I found my problem. I was building authorization policies dynamically like this:

New-UDAuthorizationPolicy -Name "Affliate" -Endpoint {
param ($ClaimsPrincipal)

$ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", $Sid)
}

Which doesn’t actually seem to work. I’m guessing that this scriptblock is read in explicitly, and I suppose $Sid will evaluate to $null at runtime. Changing to an explicit SID string instead of using a variable fixed the issue.

So here’s a script to demonstrate the issue:

$Explicit = New-UDAuthorizationPolicy -Name "Explicit" -Endpoint {
param ($ClaimsPrincipal)

$ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-2640144-4251154575-3834474851-6234")
}

$Sid = "S-1-5-21-2640144-4251154575-3834474851-6234"
$Implicit = New-UDAuthorizationPolicy -Name "Implicit" -Endpoint {
    param ($ClaimsPrincipal)

    $ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", $Sid)
}

$Explicit.Endpoint
$Implicit.Endpoint

This gives the following output:

Notice the difference in the Scriptblock and Variables properties of the object. I’m not sure exactly what this means, but there is definitely a different end result.

1 Like

Nice find! Yeah, I bet it’s just losing scope of that variable since it’s running in a background runspace. Can you open a GitHub issue for this? We can get that fixed.

1 Like

@adam Submitted here

Thanks!