Migrate accounts to OAUTH authentication from LDAP authentication

[kirank....@gmail.com]

Hi Team,

as per our company policies, we need to make our application authentication using oauth instead of ldap.

We have done testing for gerrit using Oauth, where we can use for authentication but not for authorization. We can't add AD groups in gerrit. So, we will use internal groups in gerrit.

LDAP accounts in gerrit are based on username. 

Oauth accounts are based on email ID.

As per the requirements, we need to remove ldap config and start using oauth.

But, When we try this, gerrit tries to create new account-ID instead of using old accounts.

We receive email-id is already occupied.

If anyone tried to migrate accounts from LDAP to Oauth, please let us know steps to make this migration simple.

Regards

Kiran M

[Andrew Grimberg]

Greetings Kiran,

It's not simple. That's really the basic bit of this.

Let me give an example on a Gerrit system we're in the middle of
transitioning authentication backends on. What follows is being done on
a Gerrit 3.x system. Gerrit 2.x systems pre-NoteDB are all going to be
database modifications and since I don't have any of those systems
anymore I can't give a good overview of it.

We're taking a Gerrit system that is currently doing OpenID connect
against Ubuntu's Launchpad service and migrating it to use SAML against
Auth0.

In our setup, SAML is handing out usernames just like LDAP does, and
groups too, though those end up getting replicated in Gerrit as native
groups prefixed with saml/ instead of dynamically looked up the way LDAP
does it.

Since this is a public server we don't have a lot of hard control over
accounts in the system, particularly how many are essentially abandoned
or dead since it's for open source development. Here's the process that
we're going to be going through with a large maintenance window tomorrow:

0) Some time back we setup a survey to get a match against people's
Launchpad ID and their ID in our Auth0 system. This gives us a baseline
to work with in our transformation process

1) OpenID accounts end up with an external-id of the form:
https://login.launchpad.net/+id/<someID>

2) SAML / LDAP accounts in our setup all map to a 'gerrit:<username>'
NoteDB object in the All-Users repository under meta/external-ids wheras
the OpenID object.

So for a conversion for us what we have to do is a multi-step process
wherein we do something like this:

Using our mapping information we lookup the accountID for each user
object so that we can easily find all the external-id NoteDB records.

We convert the openID records to 'gerrit:<username>' records. This is
done basically as follows:

newrecord=$(echo -n "gerrit:${uid}" | sha1sum | cut -f1 -d' ' | \
sed 's/^\(.\{2\}\)/\1\//')

git mv $openid_record $newrecord

edit $newrecord and replace the openid URL with the gerrit:${uid}
information.

commit and send up to gerrit. You'll basically need to do that for _all_
of the accounts in one shot though and for an admin account you would
have to do it with gerrit offline, and directly on disk initially.

There's some additional NoteDB mucking around that will likely be a fall
out of all of this.

Now, for your systems, you're going to need to find out what the master
record looks like in noteDB. This is going to be easiest with a test
instance hooked up to your authentication backed end. You'll want to
example the All-Users repository and look over the meta/external-ids
branch to sort of figure this all out.

Normally I use the following sort of search to find records I'm
interesting in:

grep -Rm1 "${uid}"

Take a look at one of the returned files and then lookup all of the
records for the account:

grep -Rm1 'accountId = <accountID>$'

As an FYI that trailing $ is sort of important I've found.

That will return all of the external-id records related to the account
in question. Now you can look them over.

The _primary_ record will likely be of the form:

[externalId "<some_identifier_for_auth_system>"]
accountId = NNN
email = <an_email_address>

So, for instance, in LDAP backed systems, and SAML based systems
configured like ours, it looks like

[externalId "gerrit:<userid>"]
accountId = NNN
email = <an_email_address>

There will also be a mailto record for any non-primary email address
that looks like:

[externalId "mailto:<email_address>]
accountId = NNN
email = <email_address>

Additionally you may find username records of the form

[externalId = "username:<username>"]
accountId = NNN

In any case, what you're going to end up having to do is make sure that
the primary record matches the correct sharded sha1sum of the record
name and has an email address in it _and_ that a mailto record of the
same email address _does not_ exist.

-Andy-

> Regards
> Kiran M
>
> --
> --
> 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...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/repo-discuss/4ea15f64-3cd8-4327-8b8c-53bb1c1070f2n%40googlegroups.com
> <https://groups.google.com/d/msgid/repo-discuss/4ea15f64-3cd8-4327-8b8c-53bb1c1070f2n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Matthias Sohn]

Instead of scripting this you may consider to implement the migration as another site program similar

to what Thomas did for converting externalIds to compute their sha1 case insensitive [1].

[1] https://gerrit-review.googlesource.com/q/topic:case-insensitive-usernames

 

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/81d0b827-9f1b-41cd-8480-693f5267f70a%40gmail.com.

[kirank....@gmail.com]

Thanks for taking your time to guide me. This is really great community.

I will try both options and update my status here.

[Andrew Grimberg]

On 7/13/21 1:35 AM, Matthias Sohn wrote:
--[snip]--

> Instead of scripting this you may consider to implement the migration as
> another site program similar
> to what Thomas did for converting externalIds to compute their sha1 case
> insensitive [1].
>
> [1] https://gerrit-review.googlesource.com/q/topic:case-insensitive-usernames

> <https://gerrit-review.googlesource.com/q/topic:case-insensitive-usernames>

--[snip]--

Don't have the time, nor inclination to write a bunch of java for
something that I and my team can do more quickly with some bash and
python. Especially since pretty much every time I've had to look at
doing something like this it's a one off. This is only the second time
in over 7 years of managing Gerrit systems that I've had to work through
a major conversion of authentication backends.

Besides, our maintenance window is today ;)

-Andy-