[MGNLSSO-73] Username is randomly modified that makes it unreadable Created: 26/Jul/21  Updated: 08/Sep/23  Resolved: 27/Oct/21

Status: Closed
Project: Single Sign On
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Boris Faniuk Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File image-2021-07-26-19-56-17-537.png    
Issue Links:
Relates
relates to MGNLSSO-82 User Details configurable Closed
relation
is related to MGNLSSO-85 Provide UserDetailsProvider implement... Open
supersession
is superseded by MGNLSSO-82 User Details configurable Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Steps

  • Login as Azure user boris.faniuk@idealo.de -> Look at user icon
  • Modify any page -> Search for this page

Actual

  • Username is modified to unreadable borisfaniukidealode at both search results and user icon

 Expected
Username is not randomly modified.
Both dot and @ symbols are allowed when creating user via security interface.
If some users need this behavior this should be configurable.

Development Note
This happens on this line
SsoModule object is already here, we could easily add property for this.



 Comments   
Comment by Maxime Michel [ 27/Oct/21 ]

Closing because it appears superseded by MGNLSSO-82 to me.

Comment by Maxime Michel [ 27/Oct/21 ]

Both dot and @ symbols are allowed when creating user via security interface.

Thank you for bringing this up. In such a case, we have a difference with the baked in security interface (you mean Security app, right?) and the ExternalUserManager being used by the module. Because such characters in its username actually prevent the user from logging in when using the SSO module. This is the reason we filter them out out of the box, in the case where the IDP ships an email as user ID.

Comment by Boris Faniuk [ 27/Oct/21 ]

Hello!

You're right, that both MGNLSSO-72 and MGNLSSO-73 will be covered by MGNLSSO-82.

 

such characters in its username actually prevent the user from logging in

Can you please give a bit more details on this.
I've been testing SsoLoginFilter with this transformation removed and everything worked fine.
Username was just email in this case.
Our production version currently overrides SsoLoginFilter with the following line:

Map<String, String> userDetails = Map.of(NAME, profile.getDisplayName());

So, NAME attribute is not a good alphanumeric value and we had no complains yet.
Is there something we are missing and that can give us side effects later?

Comment by Maxime Michel [ 28/Oct/21 ]

Hi bfaniuk, it has been a while since I last ran into this. Now that I think about it, it might be that it's the user ID rather than display name that doesn't tolerate special characters. In any case, you shouldn't worry about side-effects, no. When this issue happens, the user is faced with a blank page after login and it's immediately obvious something is not right.

Now that it's possible to have different UserDetailsProvider, though, I will file a follow-up so that default implementations are available for Azure, Okta, Keycloak, etc. Those would be more efficient at solving each individual case based on available fields than the default all-around solution.

Best,
Maxime

Generated at Mon Feb 12 10:50:51 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.