We want to try Pomerium with our internal services, but many of our upstream applications use SAML for SSO authentication. We haven’t found a good way to get the SAML authentication working through the Pomerium proxy. Is there any good way to do this or any known workarounds?
Typically during the SAML flow the idp will trigger the browser to do a POST to the local IP (192.168…) of the services.
Pomerium does not currently have support for SAML. We do support OIDC, and it may be possible to use something like dex to bridge the gap, though I have never tried this.
Thanks for your answer.
I already tried dex and could link it to our saml idp.
But dex act a service provider, so during the pomerium authentication, dex initate a login to the internal SAML, and it work, I get a session cookie.
But then when I access the actual internal resources, it still have to do a saml sso login and I get redirected to the internal ip of the service.
Actually even if our internal idp would be oidc I don’t see how it could work? So in the company people when they access an internal service get first redirected to the internal idp to do login via oidc then get redirected to the internal service
Now I’m adding a pomerium, make our internal idp public and use it for pomerium. I don’t know much about OIDC but won’t I get redirect to the internal IP in the end?
I’m not sure I understand the issue in question.
With Pomerium the backend, upstream application should not be using SAML nor should it be using OIDC. Rather it should rely on the attestation header we pass to upstream applications. Pomerium is responsible for authenticating and authorizing users.
It sounds like the backend upstream application is initiating a SAML login for requests proxied by Pomerium? Is there a way to disable this and rely solely on the attestation header?
