User Session Note Mapper no longer adds IMPERSONATOR_USERNAME as SAML attribute

[kenwark]

Area

saml

Describe the bug

I created a User Session Note Mapper for a Client that adds an attribute to the SAML token holding the impersonator username in order to distinguish a real user login from an "impersonation login". This was working in Keycloak 17.x but is no longer working in Keycloak 19.0.3.

I'm adding the mapper using the Keycloak Java API as follows:

final ProtocolMapperRepresentation impersonatorMap = new ProtocolMapperRepresentation();
impersonatorMap.setName("impersonator.map");
impersonatorMap.setProtocol("saml");
impersonatorMap.setProtocolMapper("saml-user-session-note-mapper");
final HashMap<String, String> configMap = new HashMap<>();
configMap.put("attribute.name", "impersonatorUsername");
configMap.put("attribute.nameformat", "Basic");
configMap.put("note", "IMPERSONATOR_USERNAME");
impersonatorMap.setConfig(configMap);
  
final ClientRepresentation clientRepresentation = new ClientRepresentation();
// etc.
protocolMappers.add(impersonatorMap);
// etc.

I can see the mapper in the Keycloak admin console. However, when I use the "impersonate" feature and go to the application, the attribute is not present.

Version

19.0.3

Expected behavior

If an admin is using the Keycloak "impersonate" feature to log in to an application, the SAML token includes an attribute with the name impersonatorUsername whose value is the admin user.

Actual behavior

No such attribute is present

How to Reproduce?

Create an application that uses SAML to integrate with Keycloak and create the User Session Note Mapper as described above.

Anything else?

It would be wonderful to have a built-in mapper for this attribute like there is for OIDC as requested in #11610

[mposolda]

Looks like a regression (even if minor and very corner-case functionality, but it's documented here in the OIDC docs - https://www.keycloak.org/docs/latest/server_admin/index.html#_protocol-mappers_oidc-user-session-note-mappers ), so we should try to fix this in Keycloak 22 if possible.

[rmartinc]

@kenwark I have been investigating this and I discovered another issue with impersonation #19687. But once that I fixed the new issue I cannot reproduce your behavior. I have done the following:

• Created a SAML client that is using a Jboss EAP 7.4 with the adapters installed.
• In the client I created a mapper with the following data:
  Mapper type: User Session Note
  Name: IMPERSONATOR_USERNAME
  User Session Note Attribute: IMPERSONATOR_USERNAME
  Friendly Name: IMPERSONATOR_USERNAME
  SAML Attribute Name: IMPERSONATOR_USERNAME
  SAML Attribute NameFormat: Basic
• And when doing an impersonation with the admin user over a normal santi user, then going to the SAML client I see the note attribute is in the SAML response:

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="ID_efda67f9-ced7-418e-8e59-28e718753a09" Version="2.0" IssueInstant="2023-04-13T07:33:23.575Z">
  <saml:Issuer>http://localhost:8080/realms/master</saml:Issuer>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">santi</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData InResponseTo="ID_3c164066-e712-4136-9e90-f52645b6c2b3" NotOnOrAfter="2023-04-13T07:34:21.575Z" Recipient="http://localhost:8081/sample-rhsso-saml/saml"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2023-04-13T07:33:21.575Z" NotOnOrAfter="2023-04-13T07:34:21.575Z">
    <saml:AudienceRestriction>
      <saml:Audience>sample-rhsso-saml</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2023-04-13T07:33:23.576Z" SessionIndex="b1813739-2566-4c78-9f37-9b621619136a::b780cea4-9281-4b4f-9ab4-78b2d4b4c5f1" SessionNotOnOrAfter="2023-04-13T15:33:23.576Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute Name="IMPERSONATOR_USERNAME" FriendlyName="IMPERSONATOR_USERNAME" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
      <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">admin</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
      <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">uma_authorization</saml:AttributeValue>
    </saml:Attribute>
    ...
  </saml:AttributeStatement>
</saml:Assertion>

As you see the subject is santi while the impersonator_username is admin. Besides I see that the two specific notes added by impersonation are checked in the tests here. So the session notes are for sure there when doing an impersonation.

Don't know if I'm missing something.

[warkentyne]

Thanks for the comment @rmartinc . I was experiencing this issue with Keycloak 19. I haven't checked the latest release and I'm not sure if I'll be able to do so in the near future.

[rmartinc]

I also tested with 19.0.0 and it was the same for me (even better because the other bug I found was introduced in 22.0.2 and it didn't happen in that version). I just added a user session note mapper and the attribute was in the SAML assertion.

[warkentyne]

To be precise, I was using 19.0.3.

[rmartinc]

Nothing, I cannot reproduce it either (I'm just adding the User Session Note mapper and the attribute is there in the SAML assertion). I will close the issue if I don't receive more feedback in a few days. Note that current version is affected by #19677. Regards!

[warkentyne]

Thanks for looking into this. @sventorben have you seen this issue?

[rmartinc]

Closing the issue. If you see how to reproduce it just reopen it or file a new one. Thanks!