value of variable not populating into SAML

[mark_hammelman]

Here's a high-level flow to explain the context:

1) client sends request to our proxy with a JWT.

2) proxy uses decode jwt ("DJ-GetClaims") policy to extract each element of JWT into variables. This generates variables with names like "jwt.DJ-GetClaims.claim.{something}" where {something} is whatever they named the field in the JWT.

3) proxy uses "generate SAML Assertion" policy and creates <saml:Attribute> elements for SAML assertion.

4) SAML assertion is sent to target system.

A variable with a name like "jwt.DJ-GetClaims.claim.issuer" works fine and the "Generate SAML" policy will put the value of that field into the XML.

However, I'm seeing that we receive variables that have a URL in the name, like "jwt.DJ-GetClaims.claim.http://schemas.mycompany.com/identity/claims/username". These do not work.

When the variable name is like this, the value of that variable doesn't get resolved. The SAML just shows it exactly like we code it into the policy, so in this case it would show

<saml:AttributeValue xsi:type="xs:string">{jwt.DJ-GetClaims.claim.http://schemas.mycompany.com/identity/claims/username}</saml:AttributeValue>

It seems to recognize it as being a valid variable name because when I try URL encoding the variable name or escaping the special characters with \ , then the policy fails and shows a message "Unresolved variable".

My next thought is to use a javascript to rename these variables, but is there something I could do in the 'generate SAML' policy instead?

[dchiesa1 · Accepted solution]

Hmmm, I think you will need to use JS to extract the value with that name. We apparently did not foresee that type of variable name.

In the future you will be able to do things like jsonPath in a variable expression.

So you would be able to do something like

{jsonPath(pathExpression, stringContainingJson)}

...to get the variable. But that's not YET available to you.

BTW this really has little to do with the SAML policy. It's really about variable resolution in general.

[dchiesa1]

Oh Mark, one more comment

It seems like you're using DecodeJWT to get the claims in an inbound JWT without verifying the signature on those claims. That means your proxy will be susceptible to a malicious client that modifies the payload of the encoded JWT and passes along an invalid signature.

Be careful about using DecodeJWT. There is one key scenario in which it is useful: when you need to extract something from the JWT itself in order to get a key that will be used for the verification of the JWT. For example

• DecodeJWT
• extract subject
• call VerifyApiKey, on the value of subject
• get the public key attacked to the app (as a custom attribute)
• use that public key to verify the signature on the inbound JWT (VerifyJWT)

If you are using DecodeJWT without calling VerifyJWT, you are probably doing something risky.

[mark_hammelman]

Hi @Dino-at-Google, Thank you for your comment. We do validate the tokens and have a similar flow to what you've described, I was just trying keep my initial post brief by omitting all the gory details 🙂

I've now added a JS to rename the variable and it works like a charm!