Authentication variables limited to just username?

TL;DR - are $result and $user vars limited to just username?

Hi
Is it possible to pass more variables from authentication.ps1 to roles.ps1?

Currently I think I can only pass SAM to roles and then for each role I have to query AD to see if user is part of security group.

To reduce the amount of calls going to AD, I would like to do a single query to AD to pull all user’s security groups (and other stuff like displayName, Title, etc) during authentication stage and then pass their SAM as username. This way, when roles are checked, I could quickly compare each role to the array of security groups in said variable, speeding up the process quite a bit.

I tried to use $Session scope, but it returns $null for me.
I haven’t tried to use $cache scope, but I really don’t want to use that unless absolutely necessary.

edit: hmm, I see that claims object contains a list, can I add more claims to the list during authentication?

Claims                           Identity
------                           --------
{Security.Claim, Security.Claim} Security.Identity


Type       : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
Value      : Admin
ValueType  : http://www.w3.org/2001/XMLSchema#string
Issuer     : https://www.poshtools.com
Properties : {}

Type       : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/hash
Value      : 41695d25-e6e4-48ed-8f95-e3be12c69d37
ValueType  : http://www.w3.org/2001/XMLSchema#string
Issuer     : https://www.poshtools.com
Properties : {}

Not at the moment but we will be adding support for this in 1.4. We’ll also be adding some cmdlets to make auth a little easier.

Then you’ll be able to auth and look up groups in the authentication.ps1 and then just use the Claims array to validate claims in your roles.ps1.

Here’s what I’m thinking for the cmdlets.

New-PSUAuthenticationResult -Success -UserName 'test' -Claims @( 
    New-PSUAuthorizationClaim -Type 'role' -Value 'group'  
)

Yep, that’s straight forward and easy to understand cmdlet, I think you should go for it.

Will those claims be accessible from UD or just PSU?

They’ll be available in UD as well. We’re working on unifying the PSU environments (API, Automation, Dashboard) so you have more consistency between the variables that are available in each runspace.