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("", "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("", $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("", "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("", $Sid)


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


Hi all, has it been solved?

Looking at the github issue raised for this. It was solved on October the 14th.

Ok Great. Thanks.

I got the authorization policy working however it is a bit strange that I get “404 Page Not Found” when a user is not authorized to access certain pages/endpoints.

Could we get something like “401 - Not authorized” instead? Or can I redirect the user to another page?
At least to me it makes more sense.


Hello @Brunogr great to hear you got it working. I guess this would be best to raise on guthub as an enhancement request on the issue page…Or create a new thread on the UD Requests/Features page in this forum, just this particular thread is pretty old…Although I am sure on my dashboards I get “Not Authorised” maybe I customised that in a file…?
On a separate note…I use menus so that the user only has the menu items they can access on login,that way you do not run into this issue of users clicking on menu items they don’t have access too. Peace

If you don’t have an explicitly defined menu, you can’t see pages you don’t have access too.

And i have to disagree with a page that says Not Authorized from a security standpoint. By saying Page Not Found, you are not giving any clues as to if that page exists.

If you say Not Authorized, you are basically telling someone (who may or may not have nefarious intent) that something is there.

Just my 2 cents. :slight_smile:

1 Like

Agreed. This is by design.

Hi -

Were you able to use $SID variable in AuthorizationPolicy?