PingFederate’s JSON string array; using SAML token to fulfill access token contract


In the advanced settings section of the access token management page for JWT tokentypes, note the option (at red 1 below) to serialize scopes as a space-separated string (rather than as a javascript string array). Obviously, this issue hit us yesterday – where the decoder happened to use very simple assumptions about the array: being a name-value pair set representable as a dotNet dictionary<string, string>. We fixed it by amending the decoder. We realize now we could have fixed it by reconfiguring ping to simplify its token formatting for simpler (almost trivial) decoders.

image

At red (2) above we see our attempts to expose some “contextual” parameters, usable in mapping.

Below, we also note the contract we  formally disclose about the tokens content (one day in OAUTH metadata, presumably, once the “new” standard catches up with “old”  SAML). We add petername.

image

Now when fulfilling that  contract, why can we not fulfill petername from any of the inbound SAML assertion’s attributes/claims? Why are things restricted to the SAML subject? This makes no sense (though I can see lots of dogma reasons, for it).

image

I think the answer is to first extend the attribute contract – thinking now of the “OAuth SAML Grant Attribute Mapping” much as one thinks of an SP adaptor contract definition.

image

Advertisements

About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in oauth, pingfederate, SAML, SSO. Bookmark the permalink.