AD Federated login, claims, and API login

I’m currently testing shifting to AD FS based login instead of Windows Auth on my IIS based UD page. I’ve finally got login working appropriately, and I can even look at $ClaimsPrinciple to see the Issuance transform rules to show AD membership and role relation. However, when I attempt to setup any type of AuthorizationPolicy to utilize $ClaimsPrinciple it is not pulling the data in. I know that this has been an issue with recent versions of UD, but I’m also not seeing any data stored in the $User variable to utilize either.

I’m also attempting to determine the proper login process for API access when utilizing Federation. attempted to pass a body with Username and Password is only returning ‘bad username or password’ errors.

Any insight would be appreciated.

Do you have are you running a nightly build of the 2.8 that is out on the Gallery? Are you seeing a $ClaimsPrincipal object at all or is it just missing the claims that you assigned via the transforms?

As for a REST API, I haven’t actually tried to configure that with ADFS. I will have to investigate how that should work.

I pulled down 2.8 from PowerShell gallery, not using nighties.

if i pull up admin terminal on the system after logging in, I can do get-variable and see both $claimsprinciple and $claimsprincipal. The data under .claims looks identical on both, and i can see it all from that Admin Terminal without issue. If i attempt to reference that data in my authorization policy though, it’s like $claimsprincipal/$claimsprinciple is empty. Looks like when utilizing ADFS, no data is stored in $user.

That’s bizarre. I’ll have to look into why that would be the case. Seems like it’s evaluating the policy before the claims are actually populated.

Can you please file an issue for this?


1 Like