Is there a way to determine whether a StringCollection contains a particular claims' value? StringCollectionContains only appear to work with fixed string input parameters.
Hypothetical example:
<ClaimsTransformation Id="HasRole" TransformationMethod="StringCollectionContains">
<InputClaims>
<InputClaim ClaimTypeReferenceId="roles" TransformationClaimType="inputClaim1"/>
<InputClaim ClaimTypeReferenceId="currentRole" TransformationClaimType="inputClaim2"/>
</InputClaims>
<InputParameters>
<InputParameter Id="ignoreCase" DataType="string" Value="true"/>
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="hasRole" TransformationClaimType="outputClaim"/>
</OutputClaims>
</ClaimsTransformation>
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@sgdesmet Thanks for your feedback! We will investigate and update as appropriate.
Sorry, we don’t have this feature coming up in the next while. I'm filing a feature request for you.
There is a _COMPLETE HACK_ that works, but seriously, consider using a REST Technical profile and send the string claim value and the string collection and ask the REST operation to figure it out.
Otherwise (and again, this is a HACK), if you can tolerate modifying the collection, then you can add your claim to the collection using a AddItemToStringCollection Claims Transformation. If the item value is already in the collection, the collection will stay the same. If not, a new element is added to the collection. BUT, in order to compare the collections, you need to serialize them.
So:
StringJoinclaims transformation to serialize the collection to a _before_ String ClaimAddItemToStringCollection claims transformation to add your claim value to the collectionStringJoinclaims transformation to serialize the collection to an _after_ String ClaimCompareClaims transformation (or perhaps a AssertStringClaimsAreEqual transformation) to check the _before_ and _after_ claims values.But remember, doing this modifies your stringCollection claim, which may or may not be a problem. You could always use a StringSplittransformation and the before claim to restore the collection to where you were initially.
I have a degenerate example that shows this, if needed. But it is a HACK.
@yoelhor thank you!
@dotnetgator we were indeed planning on using a REST profile as a fallback. I've got to admit though, that is a very inventive hack :D
@sgdesmet I'll close this one out for now, but do let us know if you feel that's been done so prematurely.
@dotnetgator Thanks for the workaround!