[MGNLSSO-82] User Details configurable Created: 27/Sep/21  Updated: 18/Aug/22  Resolved: 04/Aug/22

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

Type: Improvement Priority: High
Reporter: Niels Natzke Assignee: Thai Chi Minh
Resolution: Fixed Votes: 2
Labels: discovery, ready-for-grooming
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: 10d 5.5h Time Spent: 10d 5.5h
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Java Source File DefaultUserDetailsProviderImpl.java     Java Source File SsoLoginFilter.java     Java Source File UserDetailsProvider.java    
Issue Links:
Problem/Incident
Relates
relates to MGNLSSO-73 Username is randomly modified that ma... Closed
relates to MGNLSSO-72 External user has no display name Closed
causality
relation
is related to MGNLSSO-85 Provide UserDetailsProvider implement... Open
supersession
supersedes MGNLSSO-73 Username is randomly modified that ma... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLSSO-150 Implementation Technical task Completed Thai Chi Minh  
MGNLSSO-151 Review Technical task Completed Evzen Fochr  
MGNLSSO-152 PiQA Technical task Closed Nguyen Phung Chi  
MGNLSSO-153 Final QA Technical task Completed Thai Chi Minh  
MGNLSSO-154 DOC: document the new configuration Documentation Task Closed Alex Mansell  
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: SSO support for custom IdPs
Sprint: AdminX 14, AdminX 15
Story Points: 5
Team: AdminX

 Description   

Currently the user details are not configurable. This results in the name being displayed illegibly(See MGNLSSO-73). In addition, the language cannot be passed. This could be solved by outsourcing the assignment of the user details to an interface. This gives everyone the possibility to set the user name and other attributes themselves. The current implementation could be implemented as a default implementation of the interface.

Discovery

  • The PR is still valid for SSO v2.x, so just need to provide support for the language property and wrap up the PR.
  • Implement the approach from Mika's comment below for SSO v3.
  • Provide How-to guideline in the documentation

 



 Comments   
Comment by Maxime Michel [ 28/Sep/21 ]

Thank you for providing code! This is a good suggestion and indeed we allow no flexibility as of today.

Comment by Boris Faniuk [ 28/Sep/21 ]

Hello!
That's definitely a great step forward and would solve our problems linked to this ticket!
(currently we just overwriting SsoLoginFilter with our own implementation as a workaround)

Comment by Maxime Michel [ 02/Feb/22 ]

Unassigning myself now that module is owned by a different team. I had a PR ready but never found the time to wrap it up.

Comment by Khoa Nguyen [ 08/Jun/22 ]

Hey

We need this functionality as well. 

+1 from our side!

Comment by Mikaël Geljić [ 15/Jul/22 ]

All info should be available in the profile, we just need to know where (which attribute key) to get it from, and optionally if we need to apply some transformations.
Contemplating describing this declaratively in config, instead of by pluggable implementation. Actually similarly to the fieldMappings you pointed to viet.nguyen.

I have now retrieved my previous input on mmichel's PR, apologies for not putting it into the ticket before:
https://git.magnolia-cms.com/projects/ENTERPRISE/repos/magnolia-sso/pull-requests/57/overview?commentId=87773

Not arbitrary text filters perhaps, but the effect observed here is actually a result of two workarounds: GCP not giving a user name, and both us and Azure putting email instead.
As such, the DefaultUserDetailsProviderImpl could have some domain-driven configuration to reflect that (on top of mappings).
Mappings could just tap into OidcProfile#getAttribute directly, since all other explicit methods already do that under the hood, and fallback to current explicit methods if unspecified.

userDetails:
  nameField: "email"
  nameField.inferFromEmail: true # removes trailing @domain from given field
  nameField.trimSpecialCharacters: true # depending on where constraint comes from
  displayNameField: "name"
  emailField: "email"
Generated at Mon Feb 12 10:50:56 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.