STS Token Transformation SAML to OIDC

This topic contains 6 replies, has 2 voices, and was last updated by  carlos_usg 2 months ago.

  • Author
    Posts
  • #18775
     carlos_usg 
    Participant

    Hi guys,

    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://backstage.forgerock.com/docs/openam/13.5/admin-guide/index.html#chap-sts
    https://backstage.forgerock.com/docs/openam/13.5/dev-guide/#chap-sts
    https://forum.forgerock.com/2016/02/openam-v-13-rest-sts-openam-token-translation/

    #18786
     Peter Major 
    Moderator

    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.

    #18849
     carlos_usg 
    Participant

    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?

    #18854
     Peter Major 
    Moderator

    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.

    #18855
     carlos_usg 
    Participant

    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!

    #18901
     carlos_usg 
    Participant

    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.

    #18900
     carlos_usg 
    Participant

    Hi Peter,

    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?

    Regards,

    Carlos

    [admin-note: this got caught by the spam filter, sorry about that – Marius G]

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

©2017 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?