[MGNLSSO-230] SSOUser does not correctly use transitive groups and roles Created: 13/Jan/23 Updated: 19/Apr/23 Resolved: 18/Apr/23 |
|
| Status: | Closed |
| Project: | Single Sign On |
| Component/s: | None |
| Affects Version/s: | 3.0.0, 2.0.6 |
| Fix Version/s: | saas, 3.1.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Philipp Gaschuetz | Assignee: | Nguyen Phung Chi |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | quickwin | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | 3d 5h | Time Spent: | 3d 5h |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Sub-Tasks: |
|
|||||||||||||||||||||||||
| 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)
|
|||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
|||||||||||||||||||||||||
| Date of First Response: | ||||||||||||||||||||||||||
| Epic Link: | SSO maintenance | |||||||||||||||||||||||||
| Sprint: | AdminX 33, AdminX 34 | |||||||||||||||||||||||||
| Story Points: | 2 | |||||||||||||||||||||||||
| Team: | ||||||||||||||||||||||||||
| Work Started: | ||||||||||||||||||||||||||
| Approved: |
Yes
|
| Description |
|
The SSOUser class of the SSO Module does not override the hasRole() and inGroup() methods. According to the interface description, as well as the default implementation (MgnlUser), both of the above mentioned methods should return whether a User has a transitive assignment of the given Group or Role. SSOUser only takes directly assigned Groups and Roles into consideration. Steps to reproduce
Expected resultsshould return true, as the user has the transitive role assigned. should behave in the same way as a Magnolia installation with local user authentication. Actual resultsreturns false WorkaroundAssign direct roles and groups only, which
Development notesA merge request has been created to fix this issue: https://git.magnolia-cms.com/projects/ENTERPRISE/repos/magnolia-sso/pull-requests/188/overview |
| Comments |
| Comment by Philipp Gaschuetz [ 28/Feb/23 ] |
|
Hi, the bugfix MR, which I have created at https://git.magnolia-cms.com/projects/ENTERPRISE/repos/magnolia-sso/pull-requests/188/overview has been declined due to inactivity. Is there any news on this? Many thanks Philipp |
| Comment by Nguyen Phung Chi [ 01/Mar/23 ] |
|
Hi pgaschuetz , Sorry for late response in your PR. At the moment, I would say we would like to review your PR and your concern or use cases (as this comment). By the way, do you have more details to add regrading the use case? regarding the use case - we have several areas in our Magnolia system, where the availability of certain functionality is bound to a role. In our development system, we're using local user authentication. In our live environment, we're using SSO. Due to the different implementation in MgnlUser and SSOUser those environments are not behaving in the same way. I will let you know if we have the result. Thanks. |
| Comment by Philipp Gaschuetz [ 01/Mar/23 ] |
|
Hi, regarding the PR in general/concern:
I can't imagine a scenario in which this PR breaks existing functionality or broadens a users privileges in the system.
Regarding the use-case: It's a typical RBAC design. All of our functionality (on the Author instance) is eventually bound to roles (i.e. access to workspaces, apps, availability of actions, etc.). We're also controlling access to some specific functionality on the Author instance, i.e.
Magnolia Groups are then used to group those roles into business specific user groups. In total we have around 60 roles and 25 groups at the moment (not counting Magnolia default roles and groups). When using local Authentication everything works just fine. Of course, a workaround would be to assign roles directly to users - but this contradicts the paradigm of separating application privileges (roles) and business user groups. |
| Comment by Nguyen Phung Chi [ 01/Mar/23 ] |
|
Hi, thanks for your clarification. It's much clearer for me now, so we will try handle it as soon as possible. |