[MGNLCT-32] Security setup for content-types Created: 23/Apr/18  Updated: 28/May/18  Resolved: 22/May/18

Status: Closed
Project: Content Types
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Task Priority: Neutral
Reporter: Mikaël Geljić Assignee: Oanh Thai Hoang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1.5d
Time Spent: 0.5d
Original Estimate: 2d

Issue Links:
relation
is related to MGNLCT-3 Create editor and base-permissions fo... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: Content types foundation
Sprint: Saigon 145, Saigon 146
Story Points: 5

 Description   

Content-types 0.5 and 0.6 was bringing two roles:

  • content-base (RO)
  • content-editor (RW)

We want to evaluate how to move forward with the security/role setup for custom content types (and ensure a smooth transition if that was used before in Magnolia Cloud).



 Comments   
Comment by Ngoc Nguyenthanh [ 14/May/18 ]
Current implementation
  • Provided 2 roles
    • content-base: Read only
    • content-editor: All permissions
  • Whenever a workspace is created, the module will add an ACL: Everything under the root '/' of the workspace respectively for each roles mentioned above.
  • CLOUD usages
    • Some generated workspaces: studies, partners, references, jobs, news, events, navigations, boilderplates, holders, speakers, teasers, etc
    • But they don't actually need them. Have no user is belong to these roles.
  • Limitation:
    • User need to became a member of content-type roles.
    • When user became a member of content-type roles, they will have permissions to access all of auto-generated workspaces.
    • ACL is harcoding. Only "Everything under the root" is supported.
What's next?

New implementation need to take care of some aspects as bellow:

So far, we're discussing the JCR security aspects. For other Data Sources they need to have their implementation and customization.

TBC

Comment by Mikaël Geljić [ 18/May/18 ]

Great research:

  • We keep this ticket to make sure we grant superuser role RW access to newly created workspaces
  • We clone it to keep the discussion going re: giving control from YAML config over the security setup
  • Ideally we remove the two former role assignments on anonymous and system user.
    • We rather give workspace ACLs to superuser role directly
    • And we don't give any access to anonymous by default (will be revisited lated, maybe with a flag)
Generated at Mon Feb 12 00:36:29 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.