[quote]
View in #support on Slack
Ashley Collinge Oct 12th at 7:15 AM
Hi everyone! I have a question, when going to authenticate.domain.com/.pomerium the image doesn’t pull through. I’m using MS Azure AD as my IDP, it’s missing the access_token to access https://graph.microsoft.com/v1.0/me/photo/$value does anyone know how to pass that through properly? Thanks!
I don’t have the answer, but I can at least confirm that this happened to me too when I was testing/updating our Azure AD doc.
I assumed it was a transient issue with my config.
Hey @Ashley Collinge – confirming this is a bug. Candidly, I’m not sure if this is on Pomerium’s side or Azure’s. Azure is the only provider that uses that $value syntax which is really peculiar.My understanding is instead of just linking to a hot-linkable image like the other providers, the expectation is that the application itself would hit that endpoint and base64 decode the payload which is… really weird.Get profilePhoto - Microsoft Graph v1.0 | Microsoft Learn
I get this error: “{“error”:{“code”:“InvalidAuthenticationToken”,“message”:“Access token is empty.””, I’m not sure if Pomerium would normally get that from Azure and pass it on, just the token and identity headers (name, email etc.)
I think it’s expecting Pomerium do a round trip GET to that endpoint with the original authorization token as a bearer token.
According to their docs, the User.Read.All API permission should give Pomerium’s service account the access needed.
Ah, I haven’t specifically setup a service account for Pomerium, I do have that permission set though. I’ll do that and report back
TIA. If that’s the missing key I’ll update the docs to specify it.
Just to quickly clarify, though Pomerium would definitely have access to pull back user’s image it would not be very helpful.Azure is responding with a base64 blob of the image (vs all other identity providers just respond back with a image url that can be hotlinked). To make this usable for folks behind Pomerium would be a pretty big change and probably wouldn’t help upstream applications actually use that image.
Does that make sense?
If you are using Google for example, an upstream application can take our assertion header / picture header and just embed that png directly into their application if they want.In azure, no such url exists. So we’d either need to set the picture url to some base64 value that could be decoded by the upstream application, or serve that image directly (not a fan of). In either case, we’d have to now cache a very large image file and add it to the assertion JWT. This also runs the risk of breaking header size limits some load balancers have.
I think the way Azure imagined folks would use it is by the upstream application directly querying the image endpoint with their access token, cache it locally, then use it.
@Bobby are you sure about that? The doc you linked reads to me that the endpoint gives you a binary, and they’re suggesting converting to base64 to use as an email attachment.
So, normally Pomerium wouldn’t be sending the access_token for Azure along to the upstream application?
(I just tried adding the service account and it’s the same (makes sense)). So even if access_token was there, Chrome isn’t going to automatically decode and whatnot
So, normally Pomerium wouldn’t be sending the access_token for Azure along to the upstream application?
Pomerium cache’s all the user data during login, and session/directory refreshing.Per OIDC spec, there is only the user_info endpoint which should return the user’s image url. Azure does it’s own thing here which I don’t understand. They’ve added a whole-nother flow to the process.
URL of the End-User’s profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-User suitable for displaying when describing the End-User, rather than an arbitrary photo taken by the End-User.
So, normally Pomerium wouldn’t be sending the access_token for Azure along to the upstream application?
Pomerium only uses the access_token to hit the OIDC user_info endpoint which does usually contain a link to the user’s profile image.Yes, we intentionally does not pass the access_token to the upstream application to prevent information leakage.There’s an issue tracking if we should change that however.option to pass oAuth access token as authorization header to upstream · Issue #1915 · pomerium/pomerium · GitHub (edited)
@Bobby are you sure about that? The doc you linked reads to me that the endpoint gives you a binary, and they’re suggesting converting to base64 to use as an email attachment.
Sure about which aspect of it?They do have an endpoint where you can grab a user’s image with Pomerium’s access token. It’s just not practical for us to use because it’s base64 data, would need to be cached, and still wouldn’t be hot-linkable which is what I think most folks expect (since spec) when given a profile claim.
Sure about which aspect of it?
The part about it being base64-encoded data.
I’m not sure that they don’t support directly image linking now. It’s possible they do. But my understanding is that URL still requires a bearer token.
ahh
