We are facing issue under Okta auth for Octopus deploy. We have multiple users with same name in Okta, but with different email id. All those users are getting clubbed under 1 user account if we use “name claim type” as “name”. This results in all users having same permission which is equivalent to clubbing permissions of all those users in 1.
The work around to this is to use, ‘email’ as ‘name claim type’, but with this display name changes to email. It seems we are clubbing the accounts based on display name, which in my opinion, should be done based on email id which is unique in nature.
Thanks for getting in touch! I’m sorry about the confusion you’ve stumbled on here. I’ve recently had a deep dive into the code, and discussed with my team (part of the reason for the late reply, and my apologies about that), and I think I can see what might be happening here. I suspect it comes down to a change to your default claim type setting. Running a test in my instance as shown in the screenshot below works as expected.
This is expected to be a username, which would be unique. Using name property will be fine until you have two with the same name. So I’d reckon changing this back in this way would fix it up for you in your case?
Side note in case you’re interested: you can refer to the open sourced code that might help clarify how this works. The following two links shows some of the code I’ve looked at.
I hope this helps! Let me know how you go or if you have any further questions going forward.
Thanks for replying back. It’s the same setting at our end which you mentioned.
There is an additional property named “Name Claim Type” which is causing the issue.
If Name claim type is set to “name”, accounts for 2 users having same name gets clubbed.
The ‘Role and Username claim type’ is working as expected, its just “https://x.y@z/app#/Spaces-1/configuration/users” provided accounts based on “Name Claim Type” as we are displaying names over there, not username. If I change “Name claim Type” to email or “preferred_username” (which is pointing to email id only), display name on “https://x.y@z/app#/Spaces-1/configuration/users” page changes from name to email, and every user gets it own separate account which resolves the issue. But it defeats the purpose of having name attribute to any user-account and is not human readable. Also, I am able to create 2 different accounts manually with same name, its just while auto-creation, this is observed, that we are not able to create 2 different accounts with same name.
I appreciate you getting back in touch! I get what you mean here, and while this might result in us considering this a limitation, or by design, I’d like to bring this up with the engineers behind this area of Octopus to get some more insightful thoughts on this. I’ll make sure to keep you in the loop!
Just to add to this, if we are going to stick with the design, we should restrict it to unique values only, otherwise it can lead to incorrect authorization issues. As in our case, Person A (name: ABC, email: wxy@abc.com) has permissions X, and Person B(name: ABC, email xyz@abc.com) has permissions Y;
they both will end up with same permissions Z (Combined set of X and Y).
Thanks for expanding a bit on this, and for your patience. I’ve had a good read through this thread again and talked to an engineer here to try to form a better understanding of this behavior, and that’s raised a couple more questions, if you don’t mind.
The Name Claim is used to get the username, and not the display name. It sounds like you have multiple users with the same username?
The default in Octopus for that field is preferred_username, and I’d be interested in why that’s not being used in your situation. Would you be willing to elaborate a bit on that aspect?
Sorry for the delay in reverting back. Is it possible to schedule a call for next week after Monday (India holiday), where we can go through the settings and see what is wrong?
Few days back we upgraded our staging instance, where we have noticed that “Name claim type” is not part of settings anymore. And it is working as per your description. I am validating more on this once we have upgraded our prod instance in next few days.
Thanks for keeping in touch! My apologies for the delay in getting back to you on this one, but great to hear it seems to be working as intended in your staging instance. Please don’t hesitate to reach out if you come across any questions or concerns with your prod instance once you’re able to upgrade it!
