SAML plugin sync issue

[Kiran Shinde]

Hello all,

We’re using the SAML plugin for MFA along with Azure AD groups to manage project access in Gerrit. However, we’ve noticed a synchronization issue between Azure AD groups and the corresponding local Gerrit groups.

When we add a user to an Azure AD group, they are correctly added to the matching local Gerrit group (with the prefix saml/). But when a user is removed from the Azure AD group, they still remain in the corresponding local Gerrit group.

Our setup:

• Gerrit version: 3.11.2

• SAML plugin: master branch

Is this a known issue or some configuration that we could have missed?

Best Regards,

Kiran

[Andrew Grimberg]

Groups do not get updated until the next UI based login event with SAML
based access. The reason is that SAML has no sort of events outside of
the login where the SAML authentication and authorization server is
communicated with. Logout events don't even talk to the server in most
cases.

On 8/28/25 00:42, Kiran Shinde wrote:
> Hello all,
>
> We’re using the SAML plugin for MFA along with Azure AD groups to manage
> project access in Gerrit. However, we’ve noticed a synchronization issue
> between Azure AD groups and the corresponding local Gerrit groups.
>
> When we add a user to an Azure AD group, they are correctly added to the
> matching local Gerrit group (with the prefix saml/). But when a user is
> removed from the Azure AD group, they still remain in the corresponding
> local Gerrit group.
>
> Our setup:
>

> *
>
> Gerrit version: *3.11.2*
>
> *
>
> SAML plugin: *master branch*

>
> Is this a known issue or some configuration that we could have missed?
>
> Best Regards,
>
> Kiran
>

> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en <http://
> groups.google.com/group/repo-discuss?hl=en>
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to repo-discuss...@googlegroups.com <mailto:repo-
> discuss+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/repo-
> discuss/e53729d8-d970-47ad-a6f7-3ec46a962dben%40googlegroups.com
> <https://groups.google.com/d/msgid/repo-discuss/e53729d8-d970-47ad-
> a6f7-3ec46a962dben%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Kiran Shinde]

On Sunday, 31 August 2025 at 22:32:44 UTC+2 Andrew Grimberg wrote:

Groups do not get updated until the next UI based login event with SAML
based access. The reason is that SAML has no sort of events outside of
the login where the SAML authentication and authorization server is
communicated with. Logout events don't even talk to the server in most
cases.

 

I can see how this might cause problems in a couple of cases:

1. When someone switches teams: If they move to a team that doesn’t use Gerrit, they’re removed from the Azure AD groups. But since they never log back into Gerrit, they end up staying in the local Gerrit groups.

2. When someone leaves the company: Their Azure AD access gets removed, but their Gerrit account and group memberships remain since they’ll never log in again. And if Gerrit is exposed on the internet, they could still use their HTTP credentials to get in.

Is there a way to work around these issues?

Best Regards,

Kiran

[Luca Milanesio]

Hi Kiran,

On 1 Sep 2025, at 13:47, Kiran Shinde <kkiran...@gmail.com> wrote:

On Sunday, 31 August 2025 at 22:32:44 UTC+2 Andrew Grimberg wrote:

Groups do not get updated until the next UI based login event with SAML 
based access. The reason is that SAML has no sort of events outside of 
the login where the SAML authentication and authorization server is 
communicated with. Logout events don't even talk to the server in most 
cases.

 

I can see how this might cause problems in a couple of cases:

1. When someone switches teams: If they move to a team that doesn’t use Gerrit, they’re removed from the Azure AD groups. But since they never log back into Gerrit, they end up staying in the local Gerrit groups.

Yes, exactly. I recall to have objections when the “automation of creating Gerrit groups” from SAML was merged.

My feedback was exactly that one: you are granting permissions without the ability to remove them automatically.

2. When someone leaves the company: Their Azure AD access gets removed, but their Gerrit account and group memberships remain since they’ll never log in again. And if Gerrit is exposed on the internet, they could still use their HTTP credentials to get in.

The situation is even worse: if the user is authenticating with SSH, he may be even disabled completely but will still be able to authenticate and access the projects.

IMHO the Group integration with SAML is very risky and incomplete and should not be used as-is.

Luca.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/6690a17f-e448-4c0e-9934-f4eafa1afa13n%40googlegroups.com.

[Matthias Sohn]

On Mon, Sep 1, 2025 at 2:58 PM Luca Milanesio <luca.mi...@gmail.com> wrote:

Hi Kiran,

On 1 Sep 2025, at 13:47, Kiran Shinde <kkiran...@gmail.com> wrote:

On Sunday, 31 August 2025 at 22:32:44 UTC+2 Andrew Grimberg wrote:

Groups do not get updated until the next UI based login event with SAML 
based access. The reason is that SAML has no sort of events outside of 
the login where the SAML authentication and authorization server is 
communicated with. Logout events don't even talk to the server in most 
cases.

 

I can see how this might cause problems in a couple of cases:

1. When someone switches teams: If they move to a team that doesn’t use Gerrit, they’re removed from the Azure AD groups. But since they never log back into Gerrit, they end up staying in the local Gerrit groups.

Yes, exactly. I recall to have objections when the “automation of creating Gerrit groups” from SAML was merged.

My feedback was exactly that one: you are granting permissions without the ability to remove them automatically.

2. When someone leaves the company: Their Azure AD access gets removed, but their Gerrit account and group memberships remain since they’ll never log in again. And if Gerrit is exposed on the internet, they could still use their HTTP credentials to get in.

The situation is even worse: if the user is authenticating with SSH, he may be even disabled completely but will still be able to authenticate and access the projects.

IMHO the Group integration with SAML is very risky and incomplete and should not be used as-is.

we use accountDeactivation with this configuration

[accountDeactivation]

interval = 1 day

startTime = 05:00

[auth]

autoUpdateAccountActiveStatus = true

gitBasicAuthPolicy = HTTP

httpEmailHeader = X-SAML-EmailHeader

httpExternalIdHeader = X-SAML-ExternalId

httpHeader = X-SAML-UserName

type = HTTP_LDAP

...

[gerrit]

installModule = com.googlesource.gerrit.plugins.saml.Module

...

]ldap]

server = ldaps://<ldap server backed by Azure AD>

...

[saml]

forceAuth = true

...

with the SAML plugin and Azure AD, this ensures that users losing their Azure AD account are deactivated in gerrit at the latest on the next day.

We set saml.forceAuth = true in gerrit.config to force reauthentication with the IDP when the gerrit session expires.

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/557F6A1E-87B9-407E-A9A3-C79C35D3956A%40gmail.com.

[Luca Milanesio]

> On 1 Sep 2025, at 15:27, Matthias Sohn <matthi...@gmail.com> wrote:
>
>
>
> On Mon, Sep 1, 2025 at 2:58 PM Luca Milanesio <luca.mi...@gmail.com> wrote:
> Hi Kiran,
>
>> On 1 Sep 2025, at 13:47, Kiran Shinde <kkiran...@gmail.com> wrote:
>>
>>
>> On Sunday, 31 August 2025 at 22:32:44 UTC+2 Andrew Grimberg wrote:
>> Groups do not get updated until the next UI based login event with SAML
>> based access. The reason is that SAML has no sort of events outside of
>> the login where the SAML authentication and authorization server is
>> communicated with. Logout events don't even talk to the server in most
>> cases.
>> I can see how this might cause problems in a couple of cases:
>> • When someone switches teams: If they move to a team that doesn’t use Gerrit, they’re removed from the Azure AD groups. But since they never log back into Gerrit, they end up staying in the local Gerrit groups.
>
> Yes, exactly. I recall to have objections when the “automation of creating Gerrit groups” from SAML was merged.
> My feedback was exactly that one: you are granting permissions without the ability to remove them automatically.
>
>> • When someone leaves the company: Their Azure AD access gets removed, but their Gerrit account and group memberships remain since they’ll never log in again. And if Gerrit is exposed on the internet, they could still use their HTTP credentials to get in.
>
>
> The situation is even worse: if the user is authenticating with SSH, he may be even disabled completely but will still be able to authenticate and access the projects.
> IMHO the Group integration with SAML is very risky and incomplete and should not be used as-is.
>
> we use accountDeactivation with this configuration
> [accountDeactivation]
> interval = 1 day
> startTime = 05:00
> [auth]
> autoUpdateAccountActiveStatus = true

The above settings is managed by the AccountDeactivator which check for every active account if they still belong to a realm.

AFAIK, that’s implemented only for LDAP, not for SAML.

> gitBasicAuthPolicy = HTTP
> httpEmailHeader = X-SAML-EmailHeader
> httpExternalIdHeader = X-SAML-ExternalId
> httpHeader = X-SAML-UserName
> type = HTTP_LDAP
> ...
> [gerrit]
> installModule = com.googlesource.gerrit.plugins.saml.Module
> ...
> ]ldap]
> server = ldaps://<ldap server backed by Azure AD>

The above does the trick: basically, Azure AD is connected via LDAP for fetching the account details and, possibly, also the groups.

> ...
> [saml]
> forceAuth = true
> ...
> with the SAML plugin and Azure AD, this ensures that users losing their Azure AD account are deactivated in gerrit at the latest on the next day.

Sure, but only if Azure AD is exposed via LDAP IMHO.

> We set saml.forceAuth = true in gerrit.config to force reauthentication with the IDP when the gerrit session expires.

Yes, but what about the Git/SSH or Gerrit/SSH connections?
AFAIK that won’t force any reauthentication via SAML.

HTH

Luca.

[Matthias Sohn]

Yes, this works for us in this setup. I didn't claim this is a general solution.

 

> We set saml.forceAuth = true in gerrit.config to force reauthentication with the IDP when the gerrit session expires.

Yes, but what about the Git/SSH or Gerrit/SSH connections?
AFAIK that won’t force any reauthentication via SAML.

SAML only works via http connections, ssh uses different authentication mechanisms and separate sessions.

When a Gerrit account is deactivated InactiveAccountDisconnector.onAccountDeactivated(int id) 
ensures that the account's existing SSH sessions are disconnected.

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/A623CEFC-FEB8-4EEF-9E48-9E82EB502A6A%40gmail.com.