Serialize StringCollection claim in the cookie

[izzulhaziq]

I have the following setup for my B2C custom policy:

<TechnicalProfile Id="SM-AAD">
      <DisplayName>Session Mananagement Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <PersistedClaims>
        <PersistedClaim ClaimTypeReferenceId="objectId" />
        <PersistedClaim ClaimTypeReferenceId="signInName" />
        <PersistedClaim ClaimTypeReferenceId="email" />
        <PersistedClaim ClaimTypeReferenceId="groups" />
        <PersistedClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" />
      </PersistedClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
      </OutputClaims>
    </TechnicalProfile>

Notice one of the persisted claim is of StringCollection <PersistedClaim ClaimTypeReferenceId="groups" /> type. The original values are like:

"groups": ["guid1", "guid2", "guid3", ...]

All the claims are persisted fine in the session (cookie) except the groups claim. Instead of properly serializing/deserializing the values, on the next token request retrieve from the b2c session cookie without going back to idp, we've gotten the following in the JWT instead:

"groups": ["System.Collections.Generic.List1[System.String]"],`

Is there a way to properly serialize StringCollection claim type?

[jpalo]

Any comments on this?

[katie199]

Is there any update on this? We have the same issue.

[izzulhaziq]

We haven't been able to solve this as well, but we work around it by hooking up to azure function to serialize/deserialize in our b2c user journey. Not ideal, but that's the best one rather than having to go back to AAD for every token request, which were the original issue we had.

[katie199]

@izzulhaziq would it be possible for you to share the userjourney you used? I have been struggling with figuring out which journey is called when the user is reauthenticating and not logging in again. If you could, that would be awesome!!

[yoelhor]

Until this issue is fixed, as a temporary solution, you can use StringJoin and StringSplit claims transformations to serialise/deserialise the string collection to another string claim type.

[katie199]

Only the first claim is output when there are multiple claims with the same PartnerClaimType. We tried splitting the string collection into multiple role claims but only the first role claim was output and the others were not. We are using RoleClaimType = ClaimTypes.Role in our Startup.Auth so they claim must come over with the specific partner claim type in order to work correctly. If you output multiple claims with different ClaimReferenceId’s but the same PartnerClaimType, only the first one is sent in the claims bag. Is there a way to output multiple claims with the same PartnerClaimType? Thanks, Katie Barulsen, CMB Crescent Mortgage Company 770-508-2061 | [email protected]<mailto:[email protected]> NMLS ID 1112092 | CMC NMLS ID 4247 From: Yoel Horvitz <[email protected]> Sent: Thursday, February 6, 2020 3:08 AM To: Azure-Samples/active-directory-b2c-advanced-policies <[email protected]> Cc: Katie Barulsen <[email protected]>; Comment <[email protected]> Subject: Re: [Azure-Samples/active-directory-b2c-advanced-policies] Serialize StringCollection claim in the cookie (#46) Until this issue is fixed, as a temporary solution, you can use StringJoin<https://review.docs.microsoft.com/en-us/azure/active-directory-b2c/string-transformations?branch=pr-en-us-103425#stringjoin> and StringSplit<https://review.docs.microsoft.com/en-us/azure/active-directory-b2c/string-transformations?branch=pr-en-us-103425#stringsplit> claims transformations to serialise/deserialise the string collection to another string claim type. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#46?email_source=notifications&email_token=AIVBZUVJLXDUS54FNF4GNVDRBPAPXA5CNFSM4G3XNCE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK6JMBA#issuecomment-582784516>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIVBZUULBSFZDXCKARKEBNTRBPAPXANCNFSM4G3XNCEQ>.

…

________________________________ CONFIDENTIALITY NOTICE: This message is covered by the Electronic Communications Privacy Act, Title 18, United States Code, §§ 2510-2521. This e-mail message and any attached documents are the exclusive property of Crescent Mortgage Company and they are regarded as privileged and confidential. This communication is intended for the exclusive use of the person or entity to which it is addressed. Using this e-mail for any unauthorized use, disclosure, or distribution, is strictly prohibited. If you are not the intended recipient of this communication, please contact the sender by reply phone and destroy all copies of the original message.

[CodyMorris]

Update on this please?

[Wessie1991]

i think its solved on the 6 march

[CodyMorris]

@izzulhaziq are you still experiencing this issue? about to take a second stab at solving it for my implementation.

[izzulhaziq]

@izzulhaziq are you still experiencing this issue? about to take a second stab at solving it for my implementation.

@CodyMorris As mentioned in one of my replies, we ended up having Azure Function (basically calling a rest api) just to help with serializing and deserializing.

[michiproep]

I had a similar issue where a stringCollection could not be used in a refreshToken journey. The claim could not be read from the original accessToken and did result in an error.
Microsoft has deployed a fix for this today. and it seems to work:
" enabling "ResolveStringCollectionClaim" should resolve the problem according to the backend team "
Just curious if that also fixes your problem?