<div style="font-family: Arial, sans-serif; font-size: 14px;">Hi Gianluca,</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">our keycloak config contains this:</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><code><span><span><</span><span>nameOfUsernameAttribute</span><span>></span></span><span><code>email</code></span><span><span></</span><span>nameOfUsernameAttribute</span><span>></span></span></code><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">Maybe that will solve this issue</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">Kind regards,</div><div style="font-family: Arial, sans-serif; font-size: 14px;">Markus</div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block">
    
            <div class="protonmail_signature_block-proton protonmail_signature_block-empty">
        
            </div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div class="protonmail_quote">
        On Wednesday, 24 June 2026 at 22:57, Gianluca Bisi via midPoint <midpoint@lists.evolveum.com> wrote:<br>
        <blockquote class="protonmail_quote" type="cite">
            <div dir="ltr"><div><p>Hi everyone,</p><p>We are currently working on integrating midPoint v4.8 with Microsoft Entra ID using the OIDC authentication module.</p><p>During our implementation, we ran into a structural constraint: it appears that midPoint’s OIDC (and SAML2) authentication modules strictly use the incoming claim to match against the user's <b><code>name</code> </b>attribute (the core username field) in midPoint.</p><p>We looked into alternative mechanisms such as <code>attributeVerification</code> or <code>focusIdentification</code> modules, but according to our analysis and documentation, these flexible authentication components seem to only apply to password-reset or user-recovery flows.</p><p>In our specific use case, we need to map the incoming OIDC claim to a different unique attribute within midPoint instead of the default <code>name</code> field.</p><p>Has anyone encountered this specific requirement before? If so, how did you resolve or work around it? Is there an advanced or hidden configuration within the security policy that allows matching external IdP claims against custom or alternative user attributes?</p><p>Any insights, workarounds, or documentation pointers would be greatly appreciated.</p><p>Best regards,</p></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div><div dir="ltr"><div dir="ltr"><font><div style="color:rgb(80,0,80)"><b><font face="tahoma, sans-serif" color="#666666">Gianluca Bisi</font></b></div><div style="color:rgb(80,0,80)"><font color="#999999" face="tahoma, sans-serif">Developer | Rakkau</font></div><div style="color:rgb(80,0,80)"><font color="#999999" face="tahoma, sans-serif"><a href="mailto:gbisi@rakkau.com" target="_blank" rel="noreferrer nofollow noopener">gbisi@rakkau.com</a></font></div><div style="color:rgb(80,0,80)"><font color="#999999" face="tahoma, sans-serif"><a href="http://www.rakkau.com" target="_blank" rel="noreferrer nofollow noopener">www.rakkau.com</a></font></div></font></div></div></div><div style="margin:2px 0px 0px;color:rgb(80,0,80)"></div></div></div></div></div></div>

        </blockquote><br>
    </div>