Allow Role Hierarchy in the SAML app
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 970
- Forks
- 486
- Avg merge
- 3d 33m
- Merged PRs (30d)
- 170
Description
User Story
As a backend SSO user,
I want to be able to define and pass roles with hierarchical naming (e.g., Designer.Manager, Developer.Manager)
So that I can reuse role names under different parent contexts while maintaining distinct role identities.
This will allow SAML to correctly assign and map roles based on both their name and their parent group or category.
Example:
Designer.Manager – Represents a Manager within the Designer group
Developer.Manager – Represents a Manager within the Developer group
Despite sharing the same sub-role (Manager), the prefix (Designer, Developer) ensures these are treated as separate roles in SSO role mapping.
Acceptance Criteria
Allow for role hierarchy to be accepted in the assertion so it matches the hierarchy setup in the dotCMS backend
Proposed Objective
Customer Support
Proposed Priority
Priority 3 - Average
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
https://dotcms.freshdesk.com/a/tickets/30780
Assumptions & Initiation Needs
No response
Quality Assurance Notes & Workarounds
No response
Sub-Tasks & Estimates
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the SAML assertion role handling and the dotCMS backend role hierarchy described in the issue, using support ticket 30780 for additional context. Define completion as accepting hierarchical role names such as Designer.Manager and Developer.Manager and matching them to the corresponding backend hierarchy during role mapping.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- authentication, authorization, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100