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!September 19, 2017 at 4:43 pm #18901
I’m not sure what’s going on, but I’ve tried to submit a new post to this thread for the last 3 days and it will not show up. I actually made a comment on the General Discussion forum but no responses so far.September 20, 2017 at 11:11 am #18900
Just wanted to start with “thank you”, your recommendation to use the SAML2-Bearer Grant Type got the ball rolling to a final solution. That said, I was unfortunately not able to use the SAML2-Bearer flow because of a known issue with ADFS 3.x where the Recipient attribute is missing from the SAML2 token issued by ADFS.
That said, I was able to leverage the same technique to acquire a JWT from ADFS 3.x and have successfully been able to use the JWT-Bearer Grant Type in OpenAM to acquire an access token issued by OpenAM. Upon inspection though, it seems like I have a different problem which is that I can establish an Account Mapper for the SAML entity, and an Account Mapper for the OAuth2 module, but there doesn’t seem to be a way to define/invoke an account mapper from the JwtBearerGrantTypeHandler.
Is there any guidance you could provide in this regard, or is this effectively an enhancement which would need to be developed?
[admin-note: this got caught by the spam filter, sorry about that – Marius G]
You must be logged in to reply to this topic.