0

I am currently working on modifying a HRD policy to fit our needs. I have a claim 'domainParameter' that contains the email domain portion of the user login. I'm using a transform of LookupValue to map different domains. We have multiple groups who will be using our policy, some of which have multiple domains their users may sign up with. So our lookup shows something like the following:

<ClaimTransformation Id="GroupLookup" TransformationMethod="LookupValue">
    <InputClaims>
        <InputClaim ClaimTypeReferenceId="domainParameter" TransformationClaimType="inputParameterId" />
    </InputClaims>
    <InputParameters>
        <InputParameter Id="company1.domain1" DataType="string" Value="company1" />
        <InputParameter Id="company1.domain2" DataType="string" Value="company1" />
        <InputParameter Id="company2.domain1" DataType="string" Value="company2" />
        <InputParameter Id="errorOnFailedLookup" DataType="boolean" Value="false" />
    </InputParameters>
    <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="domainGroup" TransformationClaimType="outputClaim" />
    </OutputClaims>
</ClaimsTransformation>

This obviously works great when the domain is one of the listed domains, however we also want to allow local accounts to sign up/in and have them grouped into a group called "local", though name doesn't matter. From what I can find, I can't figure any way to have the claim assigned to a specific value if it fails the lookup. I can have it error on lookup by changing that parameter, but having it assign a value I see no way to do so. I have tried the DefaultValue attribute on 'domainGroup' both as an InputClaim and an OutputClaim, and neither work. I also see no option for wildcard selectors in the LookupValue.

Does anyone have a clue about how to get this done? I've scoured the documentation for a couple days now and have yet to find anything valuable.

D3_JMultiply
  • 1,022
  • 2
  • 12
  • 22

1 Answers1

1

The output is null for your claims transform when the lookup fails. No it cannot be set to something else directly, but can be indirectly:

I explain it in the sample how when the output of your claimsTransform is null, we do a Boolean comparison and the final value is FALSE for isKnownCustomer. That sends the user to the local account sign in page.

The capabilities of the transform are defined here

https://learn.microsoft.com/en-us/azure/active-directory-b2c/string-transformations#lookupvalue

The sample explains in detail how I get it do the logic you request. “ we also want to allow local accounts to sign up/in ... if it fails the lookup”

https://github.com/azure-ad-b2c/samples/blob/master/policies/home-realm-discovery-modern/readme.md

“The first step of the user journey presents a page to collect the users email address. The page uses input validation such that a valid email is provided.

The next step of the journey runs multiple output claims transforms to check if the domain is known.

First an output claims transformation called ParseDomain extracts the email domain name for the provided email address and copies it into the domainParameter claim.

Using the DomainLookup output claims transform, the domainParameter is looked up against a list of known domain names. If the domain name matches, DomainLookup will output a claim knownDomain = True, or otherwise it will be null.

To return a final True or False value for whether the domain was known, the CheckDomainParameterValue output claims transform is called, which compares the knownDomain with dummyTrue (which holds a True value inside it). Finally we obtain a claim isKnownCustomer which is either True or False. This prevents having a null value in the case of knownDomain.

Steps 3 and 4 handle the scenario where the domain was unknown, and mimic the steps to sign in via Local Account.”

Jas Suri - MSFT
  • 10,605
  • 2
  • 10
  • 20
  • I think you misunderstand what I'm looking for. People are already being sent to the local signup page properly when they enter in a domain that's not found. The HRD itself is working fine. We are adding an additional claim called "groups" to the token. As we are with multiple partners accounts from those partners need different permissions on our app compared to anyone who signs up from the wider world. We need the claim "domainGroup" to be populated because we then add the value of the claim to a string list, similar to how the domain is added to the providers list. – D3_JMultiply Nov 18 '20 at 14:00
  • The ability to have a value assigned if a lookup falls through in my opinion should be a basic requirement for any system like this. Ignore the HRD aspect, as that is already working. What we need is some way to say "Set the value of a claim to these values if a claim match these items, otherwise set it to this value". If you think about it like most programming languages what we need is similar to a switch statement with a default clause. If something like this isn't available in policies, to me that's a serious lapse in functionality. – D3_JMultiply Nov 18 '20 at 14:10
  • Why not initialise the `domainGroup` at the point of localAccount auth using a default value in `SelfAsserted-LocalAccountSignin-Email`? ``` ```. This technical profile only executes if domainGroup is null. – Jas Suri - MSFT Nov 18 '20 at 16:33
  • I had thought about that and it's likely this is the way I'll end up going, but if I do that, i need to move the transform that adds the group to the list via an AddItemToStringCollection transform until after that in some step that runs on both provided and local accounts. That's now what I'm trying to figure out. – D3_JMultiply Nov 18 '20 at 18:01
  • Alright, I ended up just adding a new OrchestrationStep to the user journey. Putting any OutputClaimsTransformations on the SelfAsserted-LocalAccountSingin-Email was causing an internal server error, so I had to add it to a separate orchestration step. – D3_JMultiply Nov 18 '20 at 20:53