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?
Yes, exactly, those upstream applications initiate a SAML login.
Sure, ideally, it would be best to disable SAML/OIDC on them and rely on the attestation header, but there are several legacy upstream applications that are frozen, and getting the budget for any new development is tricky.
Additionally, we are considering introducing Pomerium gradually at our company, starting with tests for one or two teams, so different login system would need to coexist for a while.
Hi,
Ok I understand. Yes I can see how that would be necessary. AFAIK initiating a login from the upstream application can still work, but there can sometimes be issues around URLs changing. Without knowing the details of those issues its hard to comment on how to fix them.
Pomerium does not support rewriting HTML or Javascript, so if code is referencing hard-coded addresses which are now located at a different URL, that could easily fail. Is that what’s happening in this case? If modifying upstream applications is not an option, I’m not sure what could be done to fix this.
