September 6, 2017 at 6:00 pm #18775
I have been looking over all the documentation that I can find on the STS, with the goal to prove or disprove that I can convert a SAML token from a remote IDP to an OIDC/OAuth2 token, which I could then use to call protected resources which are rp’s of my OIDC provider (OpenAM). Eerything I find so far leads me to the believe that this is not a supported feature
SAML2 -> OIDC, while the reverse does seem like it is
OIDC -> SAML2.
Is that a correct assessment, or am I missing something?
Documentation I found so far:
– https://forum.forgerock.com/2016/02/openam-v-13-rest-sts-openam-token-translation/September 7, 2017 at 1:02 pm #18786Peter MajorModerator
It is possible to use the saml2-bearer OAuth2 grant type to obtain access_tokens, but as far as I can see it cannot be used to obtain OIDC tokens.
If you really want to implement this using the STS, then you should be able to write some custom code that deals with that kind of token translation.September 12, 2017 at 3:37 pm #18849
Thanks for the feedback Peter, I just had a quick followup on this topic. Your reply suggests that there might be alternative to the STS in the FR suite…
If you really want to implement this using the STS, then you should be able to write some custom code that deals with that kind of token translation.
I’m I just reading too far into that, or is there something I am not aware of that would allow me to do WS-Trust type flows with SAML2 remote IDPs?September 12, 2017 at 4:12 pm #18854Peter MajorModerator
Token translation is implemented by OpenAM’s STS. If you write your own translation implementation then you can convert a token type of your choice to a different token type of your choice.September 12, 2017 at 4:13 pm #18855
Disregard the previous message, now that I’ve done a little research and learned what the Saml2-Bearer grant type was, I now realize that it IS the alternative to using the STS. I will prototype this out and see if it will work for us since what we need is really OAuth2 access tokens and not OIDC tokens as previously identified.
Thanks again, hope this works!
You must be logged in to reply to this topic.