Migration to SAML authentication

SonarQube
,
1

I’m testing the SAML authentication on a (docker based) instance of version 10.0.
The authentication is work basically. But, I faced some issues I would like to clarify.

  1. Why a migration is needed for all users individually?
    I’ve a server with more than 100 users. Do I really need to “curl” all users to /api/users/update_identity_provider manually?

  2. The login identification seems to be case-sensitive. Is this really necessary and by design?
    I have users in the system which are currently identified with a name like lukas but in the Azure AD they are named like Lukas.
    Would it be possible to make the identification case-insensitive?

  3. Why the email address is checked while login?
    I have a local administrator (no SAML!) which I would like to configure with my personal email address.
    The same email address is configured in my personal AD account.
    If I have configured both SQ users with the same email address I cannot login anymore with SAML with the following error message:

This account is already associated with another authentication method.
Sign in using the current authentication method,
or contact your administrator to transfer your account to a different authentication method.

This is confusing because the configured identity is the domain user name (onpremisessamaccountname).

  1. I started testing with version 9.9. There I configured the attribute http://schemas.microsoft.com/ws/2008/06/identity/claims/groups as “SAML group attribute”.
    After migration to version 10.0 this attribute disapeared from configuration.
    Why?
2

Hi,

We try to keep it to one topic per thread. Otherwise it can get messy, fast.

  1. Yes, you’ll have to do this individually. Should be automatable…?

  2. By design? Fair question. Could you create a separate thread for this point?

  3. Could you create a separate thread for this too, please?

  4. We reworked SAML integration in 10.0, so it’s not surprising that some values got shuffled around or disappeared.

 
Ann

3
  1. How about an option to migrate interactively in the UI?
  2. I’ll do.
  3. I’ll do.
  4. Do you think this property MUST not be configurable while many others are configurable?
4

Hi,

  1. This sounds like a ‘Product Manager for a Day’ thread
  2. I have no opinion. What I’m telling you is that SAML configuration was completely reworked.

 
Ann

5

This sounds like a ‘Product Manager for a Day’ thread

What are you trying to tell me?

I have no opinion. What I’m telling you is that SAML configuration was completely reworked.

Who can answer my question?

6

Hi,

I’m trying to tell you that you’re “How about”-ing a feature that doesn’t exist. It will be more effective if you create a new thread for it in the Product Manager for a Day category.

What exactly is the question? You started with a statement: this setting disappeared. Then you asked whether I (personally?) think the property must not be configurable.

Are you having a problem or did your integration stop working?

 
Ann

7

It will be more effective if you create a new thread for it in the Product Manager for a Day category.

I’ve not seen this category before. That is why I had completely misunderstood your statement!

Are you having a problem or did your integration stop working?

No. I was wondering and would like to understand.

1 Like
8

Hi,

To clarify, you configured the SAML group attribute when testing SAML integration with 9.9 and after upgrade to 10.0 that attribute went away.

And the question is:

Did the property go away because it’s no longer needed?

?

 
Ann

9

I’m not so familiar with all the options of Azure AD. So, I’m not sure whether it could be possible, that the groups are configured in a different property than the default.

All other options, like email address - which is unexpected to be configured differently, are configurable.

For me, SAML is working fine. I added the question to ensure it is working fine for everyone.

10

Hi,

My assumption is that the first implementation in 9.9 was the naive one, and the re-working was done after thorough study. So there’s probably not another option for groups. But if there is, I’m sure the users who can give solid use cases will speak up and tell us we messed up.

 
:sweat_smile:
Ann

11

Just now I found out, that the configuration sonar.auth.saml.group.name is used from sonar.properties, but (anymore) available in the UI.
Without this setting the synchronization of user groups is not working.
So, the configuration is implemented und functioning but disappeared in the UI!?

1 Like
12

And now I found that it is listed in the current documentation as “UI Name”:

image
image1415×868 73.6 KB

So, I’m quite sure that it should be in UI, isn’t it?

13

Hi,

At this point, I’m thoroughly confused. I’m going to flag this for other eyes.

 
Ann