feat(multi-tenancy): differentiate tenant-scoped user creation (#7613) - #7637
feat(multi-tenancy): differentiate tenant-scoped user creation (#7613)#7637Gaetan Santucci (GaetanSantucci) wants to merge 3 commits into
Conversation
|
📖 Documentation check — ✅ Passed 5 functional file(s), 0 doc file(s) changed. No documentation gaps detected. |
|
✅ Container vulnerability scan — Passed Previously reported findings are no longer present.
View workflow run · Standard JSON report · UBI9 JSON report Updated from CI run attempt 1. |
d5526a9 to
8953ad6
Compare
There was a problem hiding this comment.
Pull request overview
This PR fixes multi-tenancy user provisioning so that users created from within a tenant do not receive platform-scope “auto-assign” groups, addressing issue #7613 and preventing cross-scope privilege leakage.
Changes:
- Added an explicit tenant-scoped user creation entry point in
UserServicethat skips platform-scope auto-assign group assignment. - Updated
TenantUserService#createOrAttachto use the tenant-scoped creation path. - Added integration tests to assert platform auto-assign groups are not applied during tenant user creation and that tenant IDs provided in input are ignored.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| openaev-api/src/test/java/io/openaev/service/tenants/TenantUserServiceTest.java | Adds regression tests ensuring tenant-created users don’t join platform auto-assign groups and that input tenant IDs are ignored. |
| openaev-api/src/main/java/io/openaev/service/UserService.java | Introduces createTenantUser(...) and threads an includePlatformScope flag to prevent platform auto-assign groups during tenant-scoped creation. |
| openaev-api/src/main/java/io/openaev/service/tenants/TenantUserService.java | Switches tenant user creation to userService.createTenantUser(...) to enforce tenant-only scope on creation. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
| /** Creates a user for internal/technical purposes (SSO login, connector provisioning). */ | ||
| @Transactional(rollbackFor = Exception.class) | ||
| public User createInternalUser( |
There was a problem hiding this comment.
TODO: since every method calling this one are calling attachTenant just after, I am wondering if we need to put a false on createUser, OR do a little refacto and having just two way to create a user: tenant or platform, not internal.
| } | ||
|
|
||
| @Transactional(rollbackFor = Exception.class) | ||
| public User createTenantUser(UserInput input) { |
There was a problem hiding this comment.
todo: seems weird to have createTenantUser inside userservice to call just after createUser. Why not call direclty createUser ?
Proposed changes
Testing Instructions
tenant-aandtenant-b) with appropriate admin/operator roles.tenant-acontext, create a new user and verify:tenant-a,tenant-b.tenant-bcontext, create a new user and verify equivalent tenant isolation behavior.Related issues
Checklist
Further comments
This change focuses on making tenant boundaries explicit at user creation time to reduce accidental cross-tenant coupling and improve predictability in multi-tenant environments.
The implementation favors explicit scope propagation and validation over implicit inference, which makes the behavior easier to reason about and safer for future extensions.