[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:
Key
Summary
Type
Status
Assignee
MGNLSSO-246 Implementation Technical task Completed Nguyen Phung Chi  
MGNLSSO-247 Review Technical task Closed Evzen Fochr  
MGNLSSO-248 PiQA Technical task Completed Thai Chi Minh  
MGNLSSO-249 Final QA Technical task Completed Evzen Fochr  
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: AdminX
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

  1. Create a group in Magnolia and assign a role to it
  2. Create a SSO group mapping, so that a user gets the Group created in #1 assigned
  3. Login with the user and test role membership using User#hasRole

Expected results

should 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 results

returns false

Workaround

Assign direct roles and groups only, which

  • defeats the purpose of Role based Security
  • unrealistic in an SSO environment (or any environment at all)

Development notes

A 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:
Whatever the fix, it is my understanding, that MgnlUser (i.e. local Magnolia Authentication) and SSOUser should behave in the same way - they share the common Interface info.magnolia.cms.security.User.
I fully understand, that changing ACL/Security related code is always a bit of a concern. But in essence, the PR simply

  • makes data available, that is already assigned and bound to the logged-in user
  • makes SSOUser behave in the same way as MgnlUser
  • does not introduce new functionality, but fixes an existing bug.

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. 

  • enable/disable the display of SourceCode Button in CKEditor in a dialog based on a role
  • read-only vs edit availability of certain (but not all) properties in a specific dialog

Magnolia Groups are then used to group those roles into business specific user groups.
Users are assigned to one or more Magnolia 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.
When using SSO Authentication, functionality, which relies on info.magnolia.cms.security.User#hasRole fails.

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.

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