View in #support on Slack
@Rayane_BELLAZAAR: Hi everyone,
I have an application exposed behind pomerium proxy which are waiting for a header: Authorization Bearer and when I set my route with the properties pass_identity_headers: true its not enough and I don’t see any Authorization Header. I know that its not a new subject for you (I see a lot of messages about this problem) but, can we do something or do you have a workaround for this problem ?
Thanks
@Caleb_Doxsey: The identity headers are:
• X-Pomerium-Jwt-Assertion
• X-Pomerium-Claim-*
We don’t pass an Authorization header
@Rayane_BELLAZAAR: @Caleb_Doxsey thanks your your reply so there is no way to rewrite this header by using https://www.pomerium.io/reference/#jwt-claim-headers ?
Settings | Pomerium
@Caleb_Doxsey: I’ve not tried setting the Authorization header in this way. It seems like it wouldn’t be very useful because the claim would need to include Bearer ... and there’s no way to use string manipulation to add the prefix.
It is possible to add an Authorization header that doesn’t change via set_request_header: https://www.pomerium.io/reference/#set-request-headers
Settings | Pomerium
@Rayane_BELLAZAAR: @Caleb_Doxsey Yes but The solution behind is waiting for the JWT and it changes when it is expired so I think we can’t use this
@Caleb_Doxsey: So you want the X-Pomerium-Jwt-Assertion header to be in Authorization instead? (prefixed with Bearer?)
@Rayane_BELLAZAAR: @Caleb_Doxsey exactly. The application exposed behind is waiting for this header name :https://kiali.io/docs/configuration/authentication/header/#http-header
Kiali: Header strategy
@Caleb_Doxsey: we typically support a use case like this via a service account. For example with Kubernetes:
https://www.pomerium.io/guides/kubernetes.html#pomerium-service-account
The JWT we generate is Pomerium-specific and not the same JWT that an identity provider would give us. I’m not sure that even if we had a mechanism for constructing the header in this way it would actually work, because the token wouldn’t be in the format the application expected it.
It looks like this Kiall product supports impersonation with headers. We have a special Kubernetes integration to construct headers like this. Maybe it would also work for this product?
Kubernetes API / Kubectl | Pomerium
This strategy:
https://kiali.io/docs/configuration/authentication/token/
Basically we use a single account for the app, but use impersonation headers to specify the user
Kiali: Token strategy
@Rayane_BELLAZAAR: @Caleb_Doxsey the main paint point is we are using okta and our user should be authenticated through this provider.
@Caleb_Doxsey: We don’t support forwarding the JWT directly to a downstream application. In general we don’t want to expose the identity token because we can’t restrict access to the IdP if we forward it. We also are merging additional information that’s not available in the identity token. For example groups are synchronized separately with a service account
@Rayane_BELLAZAAR: @Caleb_Doxsey Ok I understand thanks you for your reply!
