Azure Ad SSO login does not capture User context

[sarthik]

I am monitoring a JAVA application using Elasticsearch APM which user Microsoft SSO login using Azure AD on top of simple user password based login.
While using normal login (user password based), the user context i.e user.name, user.email etc were being captured in the transactions, but while using SSO login through azure AD, the user name which is captured for every transaction is "AzureAd", which is constant irrespective of the user logged in.

I need to get some information about the user through user context to differentiate the transactions.

If somebody could help me for the same or has faced similar issue.

Kibana version: 8.1.2

Elasticsearch version: 8.1.2

APM Server version: 8.1.2

APM Agent language and version: Java Apm Agent [1.32.0]

Browser version: Chrome 109.0.5414.120

[Jonas_Kunz]

Hi @sarthik ,

Our agent simply captures the value from HttpServletRequest.getUserPrincipal() as username. I therefore presume that the SSO integration you are using either doesn't setup this value properly or simply does not have access to the username. Is the username accessible from your application code? If yes, how?

In case you have access to the username from within your application code you can use our public API to manually set the username on your transactions.

[sarthik]

We do get a valid JWT access token containing a unique 'sub' field along with 'unique_name', 'name' fields.

But ELK APM captures the user.name as 'AzureAd' which is no where in the authorization header or in the JWT token.
The value 'AzureAd' is however present in another header named 'Auth-Type'.

While using normal login (user password based), the header 'Auth-Type' is set as 'JWT', but at that time the user context is being captured in the transactions

[Jonas_Kunz]

But ELK APM captures the user.name as 'AzureAd ' which is no where in the authorization header or in the JWT token.

Our agent does not read / decode the authorization header itself. It assumes that the ServletAPI spec is followed properly and that the username is available via HttpServletRequest.getUserPrincipal(). It looks like the Azure integration your are using in your application for SSO does not setup the Servlet-API value for it properly.

Because we are currently not planning on adding dedicated support for your usecase, you therefore have to use our public API in your application as I previously said to manually set the username on the transactions.

[sarthik]

Thanks @Jonas_Kunz for resolving my query.