Proxy on top of OIDC IdP provider to accept SAML requests from service provider for SSO











up vote
0
down vote

favorite












Context:
We have an OIDC IdP that we don't have control over but we need to support SAML requests from Service Provider (SP) for SSO.



Idea:
Build a proxy (an app) that sits between SP and OIDC Identity Provider. Requests from SP are sent to the proxy app (that acts as SAML IdP for SP) and the proxy app converts the requests to OIDC requests and forwards them to OIDC provider. The results from OIDC provider are returned to the proxy app which translates them into SAML responses and forwards them to SP.



Questions:



I've very limited knowledge on SAML IdP (implementation wise). The approach seems very hackish to me :) Feels there are a lot of things I'm missing to consider. So, wanted some help and guidance as for where I'm doing things wrong. Few things I wanted to ask are:




  • Does this approach even make any sense?

  • What would be the security implications of this approach?

  • Are there other simpler/better solution to it or a similar use case?


Any sort of help will be highly appreciated.



Thanks!










share|improve this question


























    up vote
    0
    down vote

    favorite












    Context:
    We have an OIDC IdP that we don't have control over but we need to support SAML requests from Service Provider (SP) for SSO.



    Idea:
    Build a proxy (an app) that sits between SP and OIDC Identity Provider. Requests from SP are sent to the proxy app (that acts as SAML IdP for SP) and the proxy app converts the requests to OIDC requests and forwards them to OIDC provider. The results from OIDC provider are returned to the proxy app which translates them into SAML responses and forwards them to SP.



    Questions:



    I've very limited knowledge on SAML IdP (implementation wise). The approach seems very hackish to me :) Feels there are a lot of things I'm missing to consider. So, wanted some help and guidance as for where I'm doing things wrong. Few things I wanted to ask are:




    • Does this approach even make any sense?

    • What would be the security implications of this approach?

    • Are there other simpler/better solution to it or a similar use case?


    Any sort of help will be highly appreciated.



    Thanks!










    share|improve this question
























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      Context:
      We have an OIDC IdP that we don't have control over but we need to support SAML requests from Service Provider (SP) for SSO.



      Idea:
      Build a proxy (an app) that sits between SP and OIDC Identity Provider. Requests from SP are sent to the proxy app (that acts as SAML IdP for SP) and the proxy app converts the requests to OIDC requests and forwards them to OIDC provider. The results from OIDC provider are returned to the proxy app which translates them into SAML responses and forwards them to SP.



      Questions:



      I've very limited knowledge on SAML IdP (implementation wise). The approach seems very hackish to me :) Feels there are a lot of things I'm missing to consider. So, wanted some help and guidance as for where I'm doing things wrong. Few things I wanted to ask are:




      • Does this approach even make any sense?

      • What would be the security implications of this approach?

      • Are there other simpler/better solution to it or a similar use case?


      Any sort of help will be highly appreciated.



      Thanks!










      share|improve this question













      Context:
      We have an OIDC IdP that we don't have control over but we need to support SAML requests from Service Provider (SP) for SSO.



      Idea:
      Build a proxy (an app) that sits between SP and OIDC Identity Provider. Requests from SP are sent to the proxy app (that acts as SAML IdP for SP) and the proxy app converts the requests to OIDC requests and forwards them to OIDC provider. The results from OIDC provider are returned to the proxy app which translates them into SAML responses and forwards them to SP.



      Questions:



      I've very limited knowledge on SAML IdP (implementation wise). The approach seems very hackish to me :) Feels there are a lot of things I'm missing to consider. So, wanted some help and guidance as for where I'm doing things wrong. Few things I wanted to ask are:




      • Does this approach even make any sense?

      • What would be the security implications of this approach?

      • Are there other simpler/better solution to it or a similar use case?


      Any sort of help will be highly appreciated.



      Thanks!







      single-sign-on saml oidc idp






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 9 at 14:43









      bikashp

      193312




      193312
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote



          accepted










          It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.



          As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.



          If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.



          Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.



          Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.



          As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.



          In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.






          share|improve this answer





















          • Thanks, @codebrane. This is really helpful.
            – bikashp
            Nov 13 at 11:40











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














           

          draft saved


          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53227919%2fproxy-on-top-of-oidc-idp-provider-to-accept-saml-requests-from-service-provider%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          1
          down vote



          accepted










          It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.



          As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.



          If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.



          Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.



          Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.



          As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.



          In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.






          share|improve this answer





















          • Thanks, @codebrane. This is really helpful.
            – bikashp
            Nov 13 at 11:40















          up vote
          1
          down vote



          accepted










          It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.



          As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.



          If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.



          Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.



          Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.



          As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.



          In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.






          share|improve this answer





















          • Thanks, @codebrane. This is really helpful.
            – bikashp
            Nov 13 at 11:40













          up vote
          1
          down vote



          accepted







          up vote
          1
          down vote



          accepted






          It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.



          As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.



          If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.



          Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.



          Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.



          As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.



          In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.






          share|improve this answer












          It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.



          As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.



          If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.



          Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.



          Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.



          As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.



          In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 10 at 16:43









          codebrane

          1,4261914




          1,4261914












          • Thanks, @codebrane. This is really helpful.
            – bikashp
            Nov 13 at 11:40


















          • Thanks, @codebrane. This is really helpful.
            – bikashp
            Nov 13 at 11:40
















          Thanks, @codebrane. This is really helpful.
          – bikashp
          Nov 13 at 11:40




          Thanks, @codebrane. This is really helpful.
          – bikashp
          Nov 13 at 11:40


















           

          draft saved


          draft discarded



















































           


          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53227919%2fproxy-on-top-of-oidc-idp-provider-to-accept-saml-requests-from-service-provider%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Schultheiß

          Verwaltungsgliederung Dänemarks

          Liste der Kulturdenkmale in Wilsdruff