Open yohny opened 1 week ago
Sounds nice, cc @Y-Sindo
You can use userId: {headers.X-MS-CLIENT-PRINCIPAL-NAME}
to get the principle name, and {headers.X-MS-CLIENT-PRINCIPAL-ID}
to get the principle ID. Is that enough for you?
We use a third party Identity Provider and in JWT token issued by it, the user identifier claim is named account_id
, but there are of course also other more standard claims present there like email
and name
. Which claims will be propagated into those automatically populated headers (X-MS-CLIENT-PRINCIPAL-ID
, X-MS-CLIENT-PRINCIPAL-NAME
)? Or is it somehow configurable?
Because if its name
or email
claim, than it does not help. We need the claim account_id
to be used as the user identifier for SignalR.
Currently the header can't be customized to be account_id
. We will support this feature in SignalR extensions.
Currently there are limited ways to specify user identity to be used for SignalR in Azure functions when using Node.js runtime. One can use input binding property
userId
to only specify that it should be extracted from header field or query parameter. However these days the APIs are commonly called with JWT tokens, that already contain verified user identifier and this is also common case when calling SignaRnegotiate
endpoint. It would be helpful to extenduserId
to support also specifying the claim name from incoming JWT token to be used as user identifier for SIgnalR, for example:With combination of
idToken
andclaimTypeList
it is already possible to propagate claims from incoming JWT token into SignalR access token, but there is no way to specify which one is supposed to be used as user idemtity, therefore SignalR does not pick it up, even if identiy claim is propagated. Thats where the enhancement ofuserId
possibilities would help - you could explicitly specify which claim is to be used as user identity for SignalR. This would allow to solve the use cases like this