feat(config-api): feature wise admin scope for endpoints#11633 #12736
Conversation
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
…12374 Signed-off-by: pujavs <[email protected]>
…12374 Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
…oints#11633 Signed-off-by: pujavs <[email protected]>
…oints#11633 Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
Signed-off-by: pujavs <[email protected]>
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java (1)
244-257: You better think twice - details() endpoint is still missin' the admin scope!The OpenAPI security requirements at lines 246-248 include
SCOPE_LICENSE_ADMIN, but the@ProtectedApiannotation at line 257 does not include it insuperScopes. This means a token with onlylicense.adminscope will be rejected by enforcement, while the API documentation says it should be accepted.This was flagged in a past review and marked as addressed, but the fix appears to not have been applied to this endpoint.
Apply this diff to align
@ProtectedApiwith the OpenAPI security requirements:- @ProtectedApi(scopes = {SCOPE_LICENSE_READ}, groupScopes = {SCOPE_LICENSE_WRITE}, superScopes = {AppConstants.SCOPE_ADMINUI_READ}) + @ProtectedApi(scopes = {SCOPE_LICENSE_READ}, groupScopes = {SCOPE_LICENSE_WRITE}, superScopes = {SCOPE_LICENSE_ADMIN, AppConstants.SCOPE_ADMINUI_READ})
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java(11 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
- GitHub Check: run-tests (PGSQL)
- GitHub Check: run-tests (MYSQL)
- GitHub Check: prep-matrix
- GitHub Check: sonar scan (jans-linux-setup)
- GitHub Check: sonar scan (jans-fido2)
- GitHub Check: sonar scan (jans-pycloudlib)
- GitHub Check: sonar scan (jans-auth-server)
- GitHub Check: sonar scan (jans-config-api)
- GitHub Check: sonar scan (agama)
🔇 Additional comments (7)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java (7)
39-41: Yo, this new admin scope constant is lookin' fresh!The
SCOPE_LICENSE_ADMINURL pattern aligns with the established convention inAdminUIResource(e.g.,SCOPE_ROLE_ADMIN,SCOPE_PERMISSION_ADMIN). You better think twice if you ever change this pattern! Based on relevant code snippets from AdminUIResource.java, this follows the correcthttps://jans.io/oauth/config/adminui/...format for admin scopes.
49-62: Let's get this party rollin' - isActive endpoint looks solid!The OpenAPI security requirements and
@ProtectedApiannotation are properly aligned. The scope hierarchy (scopes → groupScopes → superScopes) correctly allows access viaSCOPE_LICENSE_READ, or escalated viaSCOPE_LICENSE_WRITE, or admin-level viaSCOPE_LICENSE_ADMINorSCOPE_ADMINUI_READ.
104-117: Wise ol' pigeon says this retrieveLicense endpoint is good to go!OpenAPI security requirements match the
@ProtectedApiconfiguration perfectly. The scope hierarchy allows proper access control escalation.
132-145: Trial endpoint is ready to party!Security configuration is properly aligned between OpenAPI and
@ProtectedApi. Good job keepin' it consistent!
160-173: Activate endpoint droppin' knowledge - no issues here!For this POST operation, omitting
groupScopesis correct since there's no read-level access that should escalate to write. ThesuperScopesproperly include bothSCOPE_LICENSE_ADMINandSCOPE_ADMINUI_WRITE.
188-201: SSA endpoint is flyin' high like a pigeon!Security setup mirrors the
activateendpoint pattern appropriately for write operations. Consistent and correct!
216-229: isConfigValid is lookin' clean now, my friend!The previously flagged duplicate
SCOPE_LICENSE_ADMINhas been rectified. The@ProtectedApiannotation now correctly lists each scope only once. Good vibes all around!
...ns/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java
Outdated
Show resolved
Hide resolved
Signed-off-by: pujavs <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
jans-config-api/plugins/docs/user-mgt-plugin-swagger.yaml (1)
883-897:CustomObjectAttribute.valuetype doesn’t match the examplesListen up, my friend — this schema says:
CustomObjectAttribute: properties: ... value: type: objectBut every example for simple attributes in this same file uses
valueas a string:{ "name": "sn", "multiValued": false, "values": [ "User3" ], "value": "User3", "displayValue": "User3" }If clients generate strongly typed models from this OpenAPI, they’ll expect
valueto always be an object, and strings in real responses will break validation or force ugly workarounds.If you truly support both simple and complex values, you better think twice and model that explicitly, e.g.:
value: oneOf: - type: string - type: object(And consider doing the same for
values.itemsif arrays can contain either strings or objects.)Otherwise, if only strings are expected for this API surface, tighten the schema back to
type: stringto match the actual payloads.
♻️ Duplicate comments (12)
jans-config-api/plugins/docs/kc-saml-plugin-swagger.yaml (1)
124-131: Define all newly referenced OAuth2 scopes undersecuritySchemesbefore this spec flies.Like a wise ol’ pigeon, I’m here to drop some knowledge: you’re now referencing a bunch of extra scopes in the
securityblocks, but only the.../config/saml*and the new.../config/saml.adminscope are actually declared undercomponents.securitySchemes.oauth2.flows.clientCredentials.scopes. OpenAPI validators will still squawk, because every scope used undersecuritymust be defined in that scopes map.Scopes currently used but not defined in
securitySchemesinclude (non‑exhaustive, but all visible here):
https://jans.io/idp/saml.readonlyhttps://jans.io/idp/saml.writehttps://jans.io/idp/saml.deletehttps://jans.io/oauth/config/saml.deletehttps://jans.io/oauth/config/read-allhttps://jans.io/oauth/config/write-allhttps://jans.io/oauth/config/delete-allYou better think twice about shipping this without wiring them up. Suggest extending the scopes section like this:
securitySchemes: oauth2: type: oauth2 flows: clientCredentials: tokenUrl: "https://{op-hostname}/.../token" scopes: https://jans.io/oauth/config/saml.readonly: View SAML related information https://jans.io/oauth/config/saml.write: Manage SAML related information https://jans.io/oauth/config/saml-config.readonly: View SAML configuration related information https://jans.io/oauth/config/saml-config.write: Manage SAML configuration related information https://jans.io/oauth/config/saml.admin: Admin to manage SAML configuration related information + https://jans.io/idp/saml.readonly: View SAML IdP related information + https://jans.io/idp/saml.write: Manage SAML IdP related information + https://jans.io/idp/saml.delete: Delete SAML IdP related information + https://jans.io/oauth/config/saml.delete: Delete SAML configuration related information + https://jans.io/oauth/config/read-all: Read access to all SAML configuration resources + https://jans.io/oauth/config/write-all: Write access to all SAML configuration resources + https://jans.io/oauth/config/delete-all: Delete access to all SAML configuration resourcesOnce these are declared, the new admin/idp/read‑all/write‑all/delete‑all requirements on the various SAML endpoints will be spec‑compliant and much easier to reason about downstream in tooling.
Also applies to: 205-213, 275-284, 306-313, 487-495, 522-529, 555-563, 583-591, 637-643, 691-697, 743-748, 793-798, 821-826, 848-855, 888-895, 1376-1389
jans-config-api/plugins/docs/lock-plugin-swagger.yaml (1)
602-611: You better think twice about those missing scope definitions!Like a wise ol' pigeon surveying the scene, I notice you're referencing scopes in the security block that aren't fully documented in the
securitySchemessection (lines 860-883):
https://jans.io/oauth/config/read-allhttps://jans.io/oauth/config/write-alljans_statAPI consumers rely on that catalog for scope discovery, my friend! You better think twice and add entries for all scopes that appear in
securityblocks so the spec is self-describing. Let's get this party rollin' with complete documentation!jans-config-api/plugins/docs/kc-link-plugin-swagger.yaml (1)
39-46: You better think twice about those missing scope definitions!Like a wise ol' pigeon surveying the scene, I notice the GET operation references scopes that aren't documented in the
securitySchemessection (lines 286-292):
https://jans.io/oauth/config/read-allhttps://jans.io/oauth/config/write-allWhile
kc-link.adminis now properly defined, these global config scopes are missing from the scope catalog. API consumers need those definitions to understand the permission model, my friend! Let's get this party rollin' with complete documentation!jans-config-api/plugins/docs/scim-plugin-swagger.yaml (1)
39-44: You better think twice about those missing scope definitions!Listen up, my friend! The GET operation references scopes that aren't documented in the
securitySchemessection (lines 139-144):
https://jans.io/oauth/config/read-allhttps://jans.io/oauth/config/write-allWhile the
scim.adminscope is properly defined, these global config scopes are missing from the catalog. API consumers and tooling rely on that section for scope discovery!Note: Based on learnings, SCIM schema endpoints are public per RFC 7644, but these are SCIM configuration endpoints which correctly require OAuth. However, all referenced scopes should still be documented!
jans-config-api/docs/jans-config-api-swagger.yaml (3)
2760-2766: Fix namespace mismatch —authorizations.adminshould use/oauth/client/prefix.Line 2764 introduces a scope using
https://jans.io/oauth/config/authorizations.admin, but existing authorization scopes at lines 2762 and 2888 usehttps://jans.io/oauth/client/namespace. Standardize to match the pattern. This issue propagates to line 2890 as well.Apply this fix:
security: - oauth2: - https://jans.io/oauth/client/authorizations.delete - - oauth2: - - https://jans.io/oauth/config/authorizations.admin - - oauth2: - - https://jans.io/oauth/config/delete-all + - oauth2: + - https://jans.io/oauth/client/authorizations.admin + - oauth2: + - https://jans.io/oauth/config/delete-allSame fix needed at line 2890.
2886-2894: Namespace mismatch on line 2890 — alignauthorizations.adminwith/oauth/client/pattern.Line 2890 repeats the namespace inconsistency. Apply the same fix as above to standardize the scope namespace.
14971-14977: Standardize UMA scope naming convention — mixing dots and hyphens.UMA scopes inconsistently mix naming patterns:
https://jans.io/oauth/config/uma.adminuses dots, whilehttps://jans.io/oauth/config/uma-read(line 14971) and similar entries use hyphens. This inconsistency appears throughout the file at lines 15043, 15109, 15196, and 15261. Align all UMA scopes to a single convention.Verify the authoritative naming convention in
ApiAccessConstants.javaand standardize all occurrences:security: - oauth2: - https://jans.io/oauth/config/uma/resources.readonly - oauth2: - https://jans.io/oauth/config/uma/resources.write - oauth2: - - https://jans.io/oauth/config/uma-read + - https://jans.io/oauth/config/uma.read - oauth2: - - https://jans.io/oauth/config/uma.admin + - https://jans.io/oauth/config/uma.admin(Replace all
uma-read,uma-write,uma-deletewith the consistent convention, or vice versa.)jans-config-api/plugins/docs/jans-link-plugin-swagger.yaml (1)
217-229: Defineread-allandwrite-allscopes insecuritySchemesto satisfy OpenAPI.You better think twice before leaving this as-is, my friend: the paths use
https://jans.io/oauth/config/read-allandhttps://jans.io/oauth/config/write-all, butcomponents.securitySchemes.oauth2.flows.clientCredentials.scopesonly declaresjans-link.readonly,jans-link.write, andlink.admin. That’s an OpenAPI violation and can break codegen/validators.You should add the super-admin scopes here (preferably via regenerating from updated Java annotations, not hand-editing):
securitySchemes: oauth2: type: oauth2 flows: clientCredentials: tokenUrl: "https://{op-hostname}/.../token" scopes: https://jans.io/oauth/config/jans-link.readonly: View Jans link configuration related information https://jans.io/oauth/config/jans-link.write: Manage Jans link configuration related information + https://jans.io/oauth/config/read-all: Read all configuration + related information https://jans.io/oauth/config/link.admin: Admin for Jans link configuration related information + https://jans.io/oauth/config/write-all: Write all configuration + related informationThen re-run the swagger generation so this YAML isn’t out-of-sync on the next build. Based on learnings, this file is auto-generated and should reflect the Java metadata rather than manual tweaks.
jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/rest/ApiApplication.java (1)
25-30: Add SUPER_ADMIN read/write scopes to@SecuritySchemeso docs don’t drift.Listen up, my friend: endpoints now accept
read-all/write-all(viaSUPER_ADMIN_*), but this@SecuritySchemeonly defines the three Jans Link–specific scopes. You better think twice before shipping OpenAPI where operations reference scopes that aren’t declared inflows.clientCredentials.scopes—that’s out of spec and already visible in the generated YAML.To keep the swagger generation consistent and future-safe, pull in the shared admin scopes here as well, e.g.:
-import io.jans.configapi.plugin.link.util.Constants; +import io.jans.configapi.plugin.link.util.Constants; +import io.jans.configapi.util.ApiAccessConstants; @@ -@SecurityScheme(name = "oauth2", type = SecuritySchemeType.OAUTH2, flows = @OAuthFlows(clientCredentials = @OAuthFlow(tokenUrl = "https://{op-hostname}/.../token", scopes = { -@OAuthScope(name = Constants.JANSLINK_CONFIG_READ_ACCESS, description = "View Jans link configuration related information"), -@OAuthScope(name = Constants.JANSLINK_CONFIG_WRITE_ACCESS, description = "Manage Jans link configuration related information"), -@OAuthScope(name = Constants.JANSLINK_ADMIN_ACCESS, description = "Admin for Jans link configuration related information"), -} -))) +@SecurityScheme(name = "oauth2", type = SecuritySchemeType.OAUTH2, flows = @OAuthFlows(clientCredentials = @OAuthFlow( + tokenUrl = "https://{op-hostname}/.../token", + scopes = { + @OAuthScope(name = Constants.JANSLINK_CONFIG_READ_ACCESS, description = "View Jans link configuration related information"), + @OAuthScope(name = Constants.JANSLINK_CONFIG_WRITE_ACCESS, description = "Manage Jans link configuration related information"), + @OAuthScope(name = Constants.JANSLINK_ADMIN_ACCESS, description = "Admin for Jans link configuration related information"), + @OAuthScope(name = ApiAccessConstants.SUPER_ADMIN_READ_ACCESS, description = "Read all configuration related information"), + @OAuthScope(name = ApiAccessConstants.SUPER_ADMIN_WRITE_ACCESS, description = "Write all configuration related information") + } +)))This keeps the Java metadata, generated swagger, and actual authorization model in sync.
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (2)
36-38: AlignCACHE_ADMINS_ACCESSname with other admin constantsListen up, my friend — every other constant here is singular
*_ADMIN_ACCESS, but this one isCACHE_ADMINS_ACCESS. That little “S” is pure copy‑paste bait for future bugs.If this constant is still internal to this PR, you better think twice and normalize it now:
- public static final String CACHE_ADMINS_ACCESS = "https://jans.io/oauth/config/cache.admin"; + public static final String CACHE_ADMIN_ACCESS = "https://jans.io/oauth/config/cache.admin";If external callers already compiled against the old name, consider keeping the old one as a deprecated alias pointing to the same URI.
40-42: Don’t reuse write-scope URIs for admin scopesYou better think twice here, my friend — these “admin” scopes aren’t actually distinct:
public static final String MESSAGE_WRITE_ACCESS = "https://jans.io/oauth/config/message.write"; public static final String MESSAGE_ADMIN_ACCESS = "https://jans.io/oauth/config/message.write"; // same URI public static final String SCOPES_WRITE_ACCESS = "https://jans.io/oauth/config/scopes.write"; public static final String SCOPES_ADMIN_ACCESS = "https://jans.io/oauth/config/scopes.write"; // same URIWith this setup, any code asking for an admin scope is effectively just asking for write. That undercuts the whole point of adding admin‑level scopes.
Consider giving them proper
*.adminURIs to match the rest of the file:- public static final String MESSAGE_ADMIN_ACCESS = "https://jans.io/oauth/config/message.write"; + public static final String MESSAGE_ADMIN_ACCESS = "https://jans.io/oauth/config/message.admin"; @@ - public static final String SCOPES_ADMIN_ACCESS = "https://jans.io/oauth/config/scopes.write"; + public static final String SCOPES_ADMIN_ACCESS = "https://jans.io/oauth/config/scopes.admin";Also applies to: 72-75
jans-config-api/plugins/docs/user-mgt-plugin-swagger.yaml (1)
126-134: Documentread-all/write-all/delete-allscopes insecuritySchemesListen up, my friend — the paths now correctly allow the super‑scopes:
https://jans.io/oauth/config/read-all(GET list, GET by inum)https://jans.io/oauth/config/write-all(PUT/POST/PATCH)https://jans.io/oauth/config/delete-all(DELETE)But down in
components.securitySchemes.oauth2.flows.clientCredentials.scopesyou only describe theuser.*scopes — these three super‑scopes are still undocumented.You better think twice and keep the permission model self‑contained in the spec. Something like this would close the loop:
securitySchemes: oauth2: type: oauth2 flows: clientCredentials: tokenUrl: "https://{op-hostname}/.../token" scopes: https://jans.io/oauth/config/user.readonly: View user related information https://jans.io/oauth/config/user.write: Manage user related information https://jans.io/oauth/config/user.delete: Delete user related information https://jans.io/oauth/config/user.admin: Admin to manage user related information + https://jans.io/oauth/config/read-all: Read access to all user-related data + https://jans.io/oauth/config/write-all: Write access to all user-related data + https://jans.io/oauth/config/delete-all: Delete access to all user-related dataThat way UI generators and client SDKs can surface the full set of usable scopes without guesswork.
Also applies to: 352-357, 571-577, 689-697, 720-726, 874-880, 1001-1011
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (18)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java(4 hunks)jans-config-api/docs/jans-config-api-swagger.yaml(138 hunks)jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/ApiApplication.java(1 hunks)jans-config-api/plugins/docs/jans-admin-ui-plugin-swagger.yaml(25 hunks)jans-config-api/plugins/docs/jans-link-plugin-swagger.yaml(3 hunks)jans-config-api/plugins/docs/kc-link-plugin-swagger.yaml(4 hunks)jans-config-api/plugins/docs/kc-saml-plugin-swagger.yaml(16 hunks)jans-config-api/plugins/docs/lock-plugin-swagger.yaml(14 hunks)jans-config-api/plugins/docs/scim-plugin-swagger.yaml(3 hunks)jans-config-api/plugins/docs/user-mgt-plugin-swagger.yaml(8 hunks)jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/rest/ApiApplication.java(1 hunks)jans-config-api/plugins/kc-link-plugin/src/main/java/io/jans/configapi/plugin/kc/link/rest/ApiApplication.java(1 hunks)jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/ApiApplication.java(1 hunks)jans-config-api/plugins/lock-plugin/src/main/java/io/jans/configapi/plugin/lock/rest/ApiApplication.java(1 hunks)jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ApiApplication.java(2 hunks)jans-config-api/plugins/user-mgt-plugin/src/main/java/io/jans/configapi/plugin/mgt/rest/ApiApplication.java(1 hunks)jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java(1 hunks)jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/StatResource.java(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-14T12:07:49.986Z
Learnt from: moabu
Repo: JanssenProject/jans PR: 12687
File: terraform-provider-jans/jans/schemas.go:44-61
Timestamp: 2025-11-14T12:07:49.986Z
Learning: In terraform-provider-jans/jans/schemas.go, the SCIM schema endpoints (/jans-scim/restv1/v2/Schemas/) are public discovery endpoints per RFC 7644 and do not require OAuth scopes or authentication tokens. The GetSchemas and GetSchema methods intentionally pass empty strings for token and scope parameters.
Applied to files:
jans-config-api/docs/jans-config-api-swagger.yamljans-config-api/plugins/docs/jans-link-plugin-swagger.yamljans-config-api/plugins/docs/lock-plugin-swagger.yamljans-config-api/plugins/docs/scim-plugin-swagger.yamljans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ApiApplication.java
📚 Learning: 2025-11-18T07:43:55.761Z
Learnt from: pujavs
Repo: JanssenProject/jans PR: 12704
File: jans-config-api/docs/jans-config-api-swagger.yaml:17540-17546
Timestamp: 2025-11-18T07:43:55.761Z
Learning: The file `jans-config-api/docs/jans-config-api-swagger.yaml` is auto-generated with dependent modules changes and metadata. The config API does not override it.
Applied to files:
jans-config-api/plugins/docs/jans-link-plugin-swagger.yamljans-config-api/plugins/docs/kc-link-plugin-swagger.yamljans-config-api/plugins/docs/scim-plugin-swagger.yamljans-config-api/plugins/docs/jans-admin-ui-plugin-swagger.yaml
🧬 Code graph analysis (5)
jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/rest/ApiApplication.java (1)
jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/util/Constants.java (1)
Constants(9-20)
jans-config-api/plugins/lock-plugin/src/main/java/io/jans/configapi/plugin/lock/rest/ApiApplication.java (1)
jans-config-api/plugins/lock-plugin/src/main/java/io/jans/configapi/plugin/lock/util/Constants.java (1)
Constants(9-43)
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/StatResource.java (2)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-146)jans-lock/lock-server/service/src/main/java/io/jans/lock/service/filter/AuthorizationProcessingFilter.java (1)
ProtectedApi(30-98)
jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java (1)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-146)
jans-config-api/plugins/kc-link-plugin/src/main/java/io/jans/configapi/plugin/kc/link/rest/ApiApplication.java (2)
jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/util/Constants.java (1)
Constants(9-20)jans-config-api/plugins/kc-link-plugin/src/main/java/io/jans/configapi/plugin/kc/link/util/Constants.java (1)
Constants(9-20)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: sonar scan (jans-fido2)
- GitHub Check: sonar scan (jans-config-api)
- GitHub Check: sonar scan (jans-linux-setup)
🔇 Additional comments (20)
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/StatResource.java (2)
43-48: Expanded OpenAPI security scopes are wired correctlyListen up, my friend: the oauth2
securityentries here cleanly coverstats.readonly,jans_stat, the newstats.admin, plus both super-admin read/write scopes, each as an OR alternative. Names line up withApiAccessConstantsand match the feature-wise admin model you’re rolling out, so this annotation block looks solid.
54-57: ProtectedApi scopes/superScopes align with the OpenAPI contractYou better think twice before overcomplicating this, but here it’s nice and tight: base access via
STATS_USER_READ_ACCESSorJANS_STATinscopes, and elevated access viaSTATS_USER_ADMIN_ACCESSplus the twoSUPER_ADMIN_*entries insuperScopes. That matches the OpenAPIsecuritylist above and the pattern used in other resources, so authorization behavior stays consistent.jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/ApiApplication.java (1)
29-36: SAML admin scope wiring in JAX-RS app looks consistent.Listen up, my friend! The new
Constants.SAML_ADMIN_ACCESSscope here lines up cleanly with the existing SAML config scopes and the swagger changes, so the OpenAPI security definition stays coherent across the stack. No issues from my side on this one—let’s get this party rollin’ with the rest of the scopes.jans-config-api/plugins/lock-plugin/src/main/java/io/jans/configapi/plugin/lock/rest/ApiApplication.java (1)
40-41: LGTM! Admin scope added cleanly.Listen up, my friend! Like a wise ol' pigeon, I can see you've added the
LOCK_ADMIN_ACCESSscope to the security scheme. The constant is properly defined inConstants.javaand the description is clear. This expands the admin authorization surface as intended. Let's get this party rollin'!jans-config-api/plugins/docs/lock-plugin-swagger.yaml (1)
882-883: Good vibes on the scope definition!Listen up, my friend! You've added the
lock.adminscope definition to the security schemes section. The description is clear and matches the admin pattern. Like a wise ol' pigeon, I appreciate seeing the scope properly documented!jans-config-api/plugins/docs/jans-admin-ui-plugin-swagger.yaml (2)
2094-2099: Admin scopes properly documented, my friend!Like a wise ol' pigeon, I can see you've added three new admin scope definitions to the security schemes:
config/adminui/role.adminconfig/adminui/permission.adminconfig/adminui/rolePermissionMapping.adminThese are properly documented with clear descriptions. Let's get this party rollin' 'cause this looks good!
Based on learnings, note that this file is auto-generated with dependent modules changes. Ensure your scope generation logic is updated so future regenerations include these admin scopes.
553-555: Scope expansion for config endpoint looks good!Listen up, my friend! The
/admin-ui/configGET endpoint now requiresproperties.readonlyORproperties.writescopes (lines 553-555), giving more flexibility than a single scope requirement. Like a wise ol' pigeon, I appreciate this granular approach!jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ApiApplication.java (2)
10-10: Constants import - nice touch!Like a wise ol' pigeon, I appreciate seeing you import the
Constantsclass. This sets you up to use those scope constants instead of hardcoded strings. Let's get this party rollin' with better maintainability!
27-30: Excellent refactoring with the admin scope addition!Listen up, my friend! You've made two improvements here:
Replaced hardcoded strings with constants - Using
Constants.SCIM_READ_ACCESS,Constants.SCIM_WRITE_ACCESS, andConstants.SCIM_ADMIN_ACCESSimproves maintainability and reduces the chance of typos.Added the admin scope - The new
SCIM_ADMIN_ACCESSscope expands admin-level authorization as intended by the PR.Like a wise ol' pigeon, I say this is a solid improvement! You better think twice before going back to hardcoded strings!
⛔ Skipped due to learnings
Learnt from: moabu Repo: JanssenProject/jans PR: 12687 File: terraform-provider-jans/jans/schemas.go:44-61 Timestamp: 2025-11-14T12:07:49.986Z Learning: In terraform-provider-jans/jans/schemas.go, the SCIM schema endpoints (/jans-scim/restv1/v2/Schemas/) are public discovery endpoints per RFC 7644 and do not require OAuth scopes or authentication tokens. The GetSchemas and GetSchema methods intentionally pass empty strings for token and scope parameters.jans-config-api/plugins/kc-link-plugin/src/main/java/io/jans/configapi/plugin/kc/link/rest/ApiApplication.java (1)
27-29: Admin scope for KC Link looks good!Like a wise ol' pigeon, I can see you've added the
KC_ADMIN_ACCESSscope using the constant fromConstants.KC_ADMIN_ACCESS. The description is clear: "Admin for Keycloak Link configuration related information". This aligns with the PR's objective to introduce feature-wise admin scopes. Let's get this party rollin'!jans-config-api/plugins/docs/kc-link-plugin-swagger.yaml (1)
291-292: KC Link admin scope properly documented!Listen up, my friend! Like a wise ol' pigeon, I can see you've added the
https://jans.io/oauth/config/kc-link.adminscope definition to the security schemes section. The description is clear and matches the admin pattern. Good vibes on this one!jans-config-api/plugins/docs/scim-plugin-swagger.yaml (1)
143-144: SCIM admin scope definition looks solid!Like a wise ol' pigeon, I appreciate seeing the
https://jans.io/oauth/config/scim.adminscope properly defined in the security schemes section. The description is clear: "Admin to manage SCIM configuration related information". Let's get this party rollin'!jans-config-api/docs/jans-config-api-swagger.yaml (6)
15671-15688: Verify schema changes for attribute fields.Lines 15676–15681 add new fields (
userCanEdit,adminCanEdit) to the attribute schema. Confirm these fields correspond to new feature flags or business logic additions and do not conflict with existing field definitions.
16607-16608: Verify newfapiboolean field in schema.Line 16607–16608 introduces a new
fapiboolean field. Confirm this is a legitimate feature addition and verify it's properly documented or linked to related backend changes.
17314-17317: Verify newtxTokenScriptDnsarray field.Lines 17314–17317 add a new
txTokenScriptDnsarray field to a schema. Confirm this field is properly initialized and used in backend code and that it aligns with the broader transaction token feature mentioned in hunk 71.
18613-18639: Approve scope descriptions and documentation — well-organized and comprehensive.Lines 18613–18639 add detailed descriptions for all new admin-level scopes in the OpenAPI documentation. The descriptions are clear and follow the established pattern. Once namespace inconsistencies (authorizations.admin, SSA, token) and UMA naming are fixed, this documentation will be consistent and authoritative.
14259-14267: Namespace variation forssa.adminscope is intentional and correct —/auth/ssa.adminis the authorized upstream constant.Verification confirms that
https://jans.io/auth/ssa.adminat line 14263 is not an error. The codebase defines three distinct scope namespaces:
https://jans.io/oauth/config/ssa.*— config operations (readonly, write, delete)https://jans.io/auth/ssa.*— authentication/admin scopes (admin, portal, developer)This separation is deliberate:
ApiAccessConstants.javadefinesAUTH_SSA_ADMIN = "https://jans.io/auth/ssa.admin"(line 144), andSsaScopeTypeenum confirms the three/auth/ssa.*scopes. The pattern appears consistently across all test properties files and swagger.yaml documentation (line 18638), confirming this is not a typo but an intentional design distinction between config-level and auth-level operations.
14517-14521: The/oauth/token.adminscope is intentional and properly defined.The namespace deviation is not an issue—it's an intentional design choice. The scope is consistently defined as a constant (
TOKEN_ADMIN_ACCESS) inApiAccessConstants.java(line 66) and documented in the swagger file (line 18626) as "Admin for Token management." It's applied across multiple endpoints (lines 14517, 14577, 14613, 14843) and configuration files, maintaining consistency. The separation of token management (/oauth/token.admin) from configuration scopes (/oauth/config/*) is intentional and appropriate.jans-config-api/plugins/docs/jans-link-plugin-swagger.yaml (1)
36-44: GET/PUT security combinations look consistent with the intended access model.Nice one, my friend: enumerating separate
oauth2entries per scope cleanly encodes “any of these scopes can call this operation” (jans-link.readonly,jans-link.write,link.admin,read-allfor GET;jans-link.write,link.admin,write-allfor PUT). That matches the feature-wise admin + super-admin story and keeps the swagger honest about which tokens are accepted.Also applies to: 68-74
jans-config-api/plugins/user-mgt-plugin/src/main/java/io/jans/configapi/plugin/mgt/rest/ApiApplication.java (1)
31-35: User management security scheme now properly exposes delete/admin scopesLooking sharp, my friend — the
@SecuritySchemenow advertises:
USER_READ_ACCESSUSER_WRITE_ACCESSUSER_DELETE_ACCESSUSER_ADMIN_ACCESSThis lines up with the new constants in
ApiAccessConstantsand gives tooling a complete picture of user‑mgt permissions.
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java
Outdated
Show resolved
Hide resolved
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java
Show resolved
Hide resolved
...api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/ApiApplication.java
Outdated
Show resolved
Hide resolved
jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java
Show resolved
Hide resolved
:wq! Merge branch 'main' of https://github.com/JanssenProject/jans into jans-config-fix
|
@coderabbitai generate docstrings |
✅ Actions performedInitiated docstring generation; will generate only if new commits exist. |
|
Note Docstrings generation - SUCCESS |
Docstrings generation was requested by @pujavs. * #12736 (comment) The following files were modified: * `jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java` * `jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/adminui/AdminUIResource.java` * `jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java` * `jans-config-api/plugins/fido2-plugin/src/main/java/io/jans/configapi/plugin/fido2/rest/Fido2ConfigResource.java` * `jans-config-api/plugins/fido2-plugin/src/main/java/io/jans/configapi/plugin/fido2/rest/Fido2RegistrationResource.java` * `jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/rest/JansLinkConfigResource.java` * `jans-config-api/plugins/kc-link-plugin/src/main/java/io/jans/configapi/plugin/kc/link/rest/KcLinkConfigResource.java` * `jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/IdpResource.java` * `jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/SamlConfigResource.java` * `jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/TrustRelationshipResource.java` * `jans-config-api/plugins/lock-plugin/src/main/java/io/jans/configapi/plugin/lock/rest/AuditResource.java` * `jans-config-api/plugins/lock-plugin/src/main/java/io/jans/configapi/plugin/lock/rest/LockConfigResource.java` * `jans-config-api/plugins/lock-plugin/src/main/java/io/jans/configapi/plugin/lock/rest/LockStatResource.java` * `jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ScimConfigResource.java` * `jans-config-api/plugins/user-mgt-plugin/src/main/java/io/jans/configapi/plugin/mgt/rest/UserResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/health/ApiHealthCheck.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AcrsResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AgamaDeploymentsResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AgamaRepoResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AgamaResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AssetResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AttributesResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AuditLogResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AuthConfigResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/CacheConfigurationResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/ClientAuthResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/ClientsResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/ConfigApiResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/ConfigSmtpResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/CustomScriptResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/DatabaseResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/JwksResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/LdapConfigurationResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/LoggingResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/MessageConfigurationResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/OrganizationResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/PluginResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/ScopesResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/SessionResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/SsaResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/StatResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/TokenResource.java` * `jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/UmaResourcesResource.java`
Signed-off-by: pujavs <[email protected]>
|
|
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
jans-config-api/server/src/main/resources/config-api-rs-protect.json (1)
4594-4627: SSA endpoint scope: empty inum with URL-style name is anomalous—requires clarification.Lines 4605–4607 contain a scope entry with an empty inum (
"") namedhttps://jans.io/auth/ssa.admin. This is inconsistent with the established pattern in the file: other empty inum entries use simple names (e.g.,jans_stat,revoke_session), not URL-style names. Additionally, this is the only occurrence of thehttps://jans.io/auth/prefix in the file; line 4619 defines a distinct entryhttps://jans.io/oauth/config/ssa.adminwith inum1800.05.34.Clarify whether:
- The empty inum is intentional and a proper inum should be assigned (not
1800.05.34, which would duplicate the superScope entry)- The name should be simplified to match the pattern of other empty inum entries, or
- This scope serves a distinct purpose from the superScope entry and requires its own inum assignment.
♻️ Duplicate comments (7)
jans-config-api/server/src/main/resources/config-api-rs-protect.json (1)
2155-2184: DUPLICATE: Agama syntax-check still has scope mapping inconsistencies—verify inum/name lockstep.This was flagged in a prior review. The current state still has issues:
- Line 2163: inum
1800.01.44is namedagama.readonly, but per the/jans-config-api/api/v1/agamaendpoint (line 2082),1800.01.43is.readonlyand1800.01.44is.write.- Line 2169: duplicates inum
1800.01.44in groupScopes for.write(correct value, but same inum as scopes field above).- Line 2179: superScopes uses inum
1800.03.2namedread-all, but elsewhere (e.g., line 29)1800.03.2maps towrite-alland1800.03.1toread-all.Realign these to follow the convention: use
1800.01.43for.readonlyand1800.01.44for.write; use1800.03.1forread-all.{ "path": "/jans-config-api/api/v1/agama/syntax-check", "conditions": [ { "httpMethods": ["POST"], "scopes": [ { - "inum": "1800.01.44", - "name": "https://jans.io/oauth/config/agama.readonly" + "inum": "1800.01.43", + "name": "https://jans.io/oauth/config/agama.readonly" } ], "groupScopes": [ { "inum": "1800.01.44", "name": "https://jans.io/oauth/config/agama.write" } ], "superScopes": [ { "inum": "1800.05.18", "name": "https://jans.io/oauth/config/agama.admin" }, { - "inum": "1800.03.2", - "name": "https://jans.io/oauth/config/read-all" + "inum": "1800.03.1", + "name": "https://jans.io/oauth/config/read-all" } ] } ] }jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (5)
36-38: RenameCACHE_ADMINS_ACCESSor alias it to a singularCACHE_ADMIN_ACCESSYou better think twice about this plural outlier, my friend:
public static final String CACHE_READ_ACCESS = ".../cache.readonly"; public static final String CACHE_WRITE_ACCESS = ".../cache.write"; public static final String CACHE_ADMINS_ACCESS = ".../cache.admin";Every other constant uses singular
*_ADMIN_ACCESS, so this one will trip people up when scanning the class.If it’s safe to adjust now, I’d either rename or introduce a canonical singular name and alias the old one:
- public static final String CACHE_READ_ACCESS = "https://jans.io/oauth/config/cache.readonly"; - public static final String CACHE_WRITE_ACCESS = "https://jans.io/oauth/config/cache.write"; - public static final String CACHE_ADMINS_ACCESS = "https://jans.io/oauth/config/cache.admin"; + public static final String CACHE_READ_ACCESS = "https://jans.io/oauth/config/cache.readonly"; + public static final String CACHE_WRITE_ACCESS = "https://jans.io/oauth/config/cache.write"; + public static final String CACHE_ADMIN_ACCESS = "https://jans.io/oauth/config/cache.admin"; + @Deprecated + public static final String CACHE_ADMINS_ACCESS = CACHE_ADMIN_ACCESS;That keeps existing callers compiling while steering new code toward the singular form.
40-42: Fix MESSAGE_ADMIN_ACCESS to use.admininstead of.writeListen up, my friend — this one is a real functional landmine:
public static final String MESSAGE_WRITE_ACCESS = "https://jans.io/oauth/config/message.write"; public static final String MESSAGE_ADMIN_ACCESS = "https://jans.io/oauth/config/message.write";
MESSAGE_ADMIN_ACCESSis pointing at the write scope, so there is no distinct admin scope at all. That defeats the purpose of introducing admin scopes and will confuse both docs and authorization logic.Patch it to use a proper
.adminURI:- public static final String MESSAGE_ADMIN_ACCESS = "https://jans.io/oauth/config/message.write"; + public static final String MESSAGE_ADMIN_ACCESS = "https://jans.io/oauth/config/message.admin";
68-71: SCOPES_ADMIN_ACCESS must not reuse the write scope URIYou better think twice about this copy‑paste, my friend:
public static final String SCOPES_WRITE_ACCESS = "https://jans.io/oauth/config/scopes.write"; public static final String SCOPES_ADMIN_ACCESS = "https://jans.io/oauth/config/scopes.write";As with MESSAGE, this makes the “admin” scope indistinguishable from write, breaking the intended permission separation.
Recommend switching to a dedicated
.adminURI:- public static final String SCOPES_ADMIN_ACCESS = "https://jans.io/oauth/config/scopes.write"; + public static final String SCOPES_ADMIN_ACCESS = "https://jans.io/oauth/config/scopes.admin";
58-66: Align OPENID_CLIENTS_ADMIN_ACCESS and TOKEN_ADMIN_ACCESS URI patternsListen up, my friend — these two admin scopes break the otherwise clean pattern:
public static final String OPENID_CLIENTS_READ_ACCESS = "https://jans.io/oauth/config/openid/clients.readonly"; public static final String OPENID_CLIENTS_WRITE_ACCESS = "https://jans.io/oauth/config/openid/clients.write"; public static final String OPENID_CLIENTS_DELETE_ACCESS = "https://jans.io/oauth/config/openid/clients.delete"; public static final String OPENID_CLIENTS_ADMIN_ACCESS = "https://jans.io/oauth/config/clients.admin"; // drops /openid public static final String TOKEN_READ_ACCESS = "https://jans.io/oauth/config/token.readonly"; public static final String TOKEN_WRITE_ACCESS = "https://jans.io/oauth/config/token.write"; public static final String TOKEN_DELETE_ACCESS = "https://jans.io/oauth/config/token.delete"; public static final String TOKEN_ADMIN_ACCESS = "https://jans.io/oauth/token.admin"; // drops /configUnless these are intentionally broader, they look like fat‑fingered typos and will diverge from the documented/configured scope naming.
If they’re meant to align with their siblings, patch like this:
- public static final String OPENID_CLIENTS_ADMIN_ACCESS = "https://jans.io/oauth/config/clients.admin"; + public static final String OPENID_CLIENTS_ADMIN_ACCESS = "https://jans.io/oauth/config/openid/clients.admin"; @@ - public static final String TOKEN_ADMIN_ACCESS = "https://jans.io/oauth/token.admin"; + public static final String TOKEN_ADMIN_ACCESS = "https://jans.io/oauth/config/token.admin";If the broader semantics are intentional, it’d be wise to add a short comment explaining why they differ so future pigeons don’t have to reverse‑engineer it.
95-98: Session and Asset ADMIN URIs deviate from their siblings — clarify or realignYou better think twice about these two, my friend:
// Sessions public static final String JANS_AUTH_SESSION_READ_ACCESS = "https://jans.io/oauth/jans-auth-server/session.readonly"; public static final String JANS_AUTH_SESSION_DELETE_ACCESS = "https://jans.io/oauth/jans-auth-server/session.delete"; public static final String JANS_AUTH_SESSION_ADMIN_ACCESS = "https://jans.io/oauth/config/session.admin"; // switches base path // Assets public static final String JANS_ASSET_READ_ACCESS = "https://jans.io/oauth/config/jans_asset-read"; public static final String JANS_ASSET_WRITE_ACCESS = "https://jans.io/oauth/config/jans_asset-write"; public static final String JANS_ASSET_DELETE_ACCESS = "https://jans.io/oauth/config/jans_asset-delete"; public static final String JANS_ASSET_ADMIN_ACCESS = "https://jans.io/oauth/config/asset.admin"; // drops jans_The admin URIs change base segments/prefix patterns relative to their read/write/delete siblings. That might be intentional (broader admin scopes), but right now it just looks like inconsistency.
Options:
- If they’re supposed to match their siblings, realign the URIs (
.../jans-auth-server/session.admin,.../jans_asset-admin).- If they’re intentionally broader/different, add a one‑line comment above each constant to document the rationale.
Also applies to: 129-132
jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java (1)
126-149: Admin scopes are wired correctly here but inherit the constant-level URI bugsListen up, my friend — this flock of new
@OAuthScopeentries cleanly exposes admin scopes for every feature, but a few of the underlying constants they reference are still off:
MESSAGE_ADMIN_ACCESSandSCOPES_ADMIN_ACCESSboth point at.writeURIs instead of.admin.OPENID_CLIENTS_ADMIN_ACCESSdrops the/openidsegment.TOKEN_ADMIN_ACCESSdrops the/configsegment.CACHE_ADMINS_ACCESS,JANS_AUTH_SESSION_ADMIN_ACCESS, andJANS_ASSET_ADMIN_ACCESSdon’t follow the same patterns as their read/write/delete siblings.Mechanically, the annotation wiring looks good; however, until you fix those constants in
ApiAccessConstants, the OpenAPI security definition here will advertise/require the wrong scope URIs.Once you correct the constants, this block should work as intended without further changes.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (7)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java(4 hunks)jans-config-api/plugins/fido2-plugin/src/main/java/io/jans/configapi/plugin/fido2/rest/ApiApplication.java(2 hunks)jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/rest/ApiApplication.java(2 hunks)jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java(1 hunks)jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/UmaResourcesResource.java(6 hunks)jans-config-api/server/src/main/resources/config-api-rs-protect.json(146 hunks)jans-config-api/server/src/test/resources/test.properties(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-18T07:43:55.761Z
Learnt from: pujavs
Repo: JanssenProject/jans PR: 12704
File: jans-config-api/docs/jans-config-api-swagger.yaml:17540-17546
Timestamp: 2025-11-18T07:43:55.761Z
Learning: The file `jans-config-api/docs/jans-config-api-swagger.yaml` is auto-generated with dependent modules changes and metadata. The config API does not override it.
Applied to files:
jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java
📚 Learning: 2025-11-14T12:07:49.986Z
Learnt from: moabu
Repo: JanssenProject/jans PR: 12687
File: terraform-provider-jans/jans/schemas.go:44-61
Timestamp: 2025-11-14T12:07:49.986Z
Learning: In terraform-provider-jans/jans/schemas.go, the SCIM schema endpoints (/jans-scim/restv1/v2/Schemas/) are public discovery endpoints per RFC 7644 and do not require OAuth scopes or authentication tokens. The GetSchemas and GetSchema methods intentionally pass empty strings for token and scope parameters.
Applied to files:
jans-config-api/server/src/main/resources/config-api-rs-protect.jsonjans-config-api/server/src/test/resources/test.properties
🧬 Code graph analysis (2)
jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/rest/ApiApplication.java (1)
jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/util/Constants.java (1)
Constants(9-20)
jans-config-api/plugins/fido2-plugin/src/main/java/io/jans/configapi/plugin/fido2/rest/ApiApplication.java (1)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-142)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: sonar scan (jans-casa)
- GitHub Check: sonar scan (jans-cli-tui)
- GitHub Check: sonar scan (jans-link)
- GitHub Check: sonar scan (jans-scim)
- GitHub Check: sonar scan (jans-linux-setup)
- GitHub Check: sonar scan (jans-config-api)
🔇 Additional comments (14)
jans-config-api/server/src/test/resources/test.properties (3)
11-11: ✅ Good catch on the leading slash!You fixed the assetUrl path format to include the leading
/and align with the other endpoint URLs. That's what we're talkin' about—consistency is key for proper URL concatenation.
11-37: ✅ New endpoint URLs follow consistent formatting.All the new endpoint properties (lines 12–37) have proper leading slashes and follow a uniform pattern. The test configuration is now ready to support the expanded admin-scoped feature across multiple endpoints.
15-15: Potential typo:apiConfigtionshould beapiConfigurationUrl?You better think twice about this one, my friend! Both line 15 (
apiConfigtionUrl) and the comment on line 40 (#apiConfigtion) contain what looks like a typo—missing the "ura" in "configuration." If this is an intentional internal property name, carry on. But if it should beapiConfigurationUrl, now's the time to fix it before it becomes a wild goose chase later.Can you confirm whether
apiConfigtionis intentional or if it should readapiConfigurationUrl? Also, is theapiConfigUrlon line 34 a separate, intentional property or a duplicate?Also applies to: 40-40
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/UmaResourcesResource.java (4)
63-77: Coo coo! Lookin' good, my feathered friends — read endpoints are now aligned!Listen up! Previously, there was a sneaky little inconsistency where the list endpoint had
UMA_READ_ACCESSbut the read-by-ID endpoints didn't. Now all three GET operations strut the same security swagger:
- Primary scope:
UMA_READ_ACCESS- Group scope:
UMA_WRITE_ACCESS(so write tokens can read too — makes sense!)- Super scopes:
UMA_ADMIN_ACCESS,SUPER_ADMIN_READ_ACCESS,SUPER_ADMIN_WRITE_ACCESSThat previous review concern? Squashed like a breadcrumb under my tiny pigeon feet. 🐦
Also applies to: 99-115, 121-136
144-156: Write operations (POST, PUT, PATCH) — consistent as a pigeon's daily routine!All three write operations follow the same pattern, and I ain't gotta think twice about it:
- Primary scope:
UMA_WRITE_ACCESS- Group scopes:
{}(empty — write ain't implied by other scopes)- Super scopes:
UMA_ADMIN_ACCESS,SUPER_ADMIN_WRITE_ACCESSThe
@Operation.securityand@ProtectedApiannotations are perfectly aligned across create, update, and patch. That's some well-organized nest-building right there!Also applies to: 180-193, 206-220
232-244: Delete endpoint flies solo with its own scope pattern — and that's how it should be!The delete operation correctly uses
UMA_DELETE_ACCESSas the primary scope withSUPER_ADMIN_DELETE_ACCESS(not write!) in super scopes. This separation of concerns means you can grant delete permissions independently from write permissions.Wise choice, friend! Keeps those destructive operations properly guarded.
63-77: All referenced scope constants exist inApiAccessConstants.Verification confirms that
UMA_READ_ACCESS,UMA_WRITE_ACCESS,UMA_ADMIN_ACCESS,SUPER_ADMIN_READ_ACCESS, andSUPER_ADMIN_WRITE_ACCESSare all properly defined in the class. The constants referenced in the code are valid.jans-config-api/server/src/main/resources/config-api-rs-protect.json (3)
4451-4485: New endpoint added:/jans-config-api/api/v1/agama-repo/download—verify scope completeness.A new endpoint path for agama-repo download has been added. Confirm that:
- The scope definitions (1800.01.91, 1800.01.92, 1800.05.18) are intentional and match the parent agama-repo endpoint.
- No additional scopes (e.g., for delete operations) are needed if this becomes a multi-method endpoint in the future.
4558-4592: New database endpoint added:/jans-config-api/api/v1/config/database—verify scope coverage.A new parent database endpoint (lines 4558–4592) has been added. Verify:
- Is this intentional as a top-level config/database GET endpoint, distinct from the existing
/config/database/ldapresources (line 1261)?- Are the scopes (1800.01.95, 1800.01.96, 1800.05.10) newly created or reused from elsewhere?
- Should this endpoint support POST/PATCH/PUT/DELETE methods as well, or is GET-only by design?
3088-3093: No action required. The inum1800.01.577is not a typo—it is intentional and distinct from the write scope1800.01.57. The SAML oauth/config scope hierarchy follows a deliberate pattern:1800.01.56(readonly),1800.01.57(write),1800.01.577(delete). Using a separate inum for the delete scope is correct, as assigning it the same value as the write scope would be semantically incorrect.jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (2)
11-35: New admin constants mostly follow a clear, consistent patternListen up, my friend — this flock of new
*.ADMIN_ACCESSconstants (auth config, attributes, acrs, database, scripts, smtp, logging, jwks, org, user, agama) all stick to the.../config/<feature>.adminconvention. That’s clean, predictable, and will make downstream authorization checks much easier to reason about.
105-120: Feature, super-admin, plugin, config, client-authorization, and health scopes look coherentListen up, my friend — the feature scopes (
OPENID_*,UMA_*), super-admin read/write/delete, plugin, config, client authorizations, andHEALTH_ADMINconstants all follow consistent naming and URI schemes. That consistency will make wiring them through OpenAPI and ProtectedApi annotations much smoother.Also applies to: 124-124, 141-141
jans-config-api/plugins/fido2-plugin/src/main/java/io/jans/configapi/plugin/fido2/rest/ApiApplication.java (1)
3-4: Good reuse of SUPER_ADMIN scopes in FIDO2 security definitionListen up, my friend — pulling
SUPER_ADMIN_*fromApiAccessConstantsand adding them alongside the FIDO2 config scopes keeps the security model consistent with the rest of the config API and centralizes scope definitions nicely.Also applies to: 29-34
jans-config-api/plugins/jans-link-plugin/src/main/java/io/jans/configapi/plugin/link/rest/ApiApplication.java (1)
4-5: Scoped layering for Jans Link (read/write/admin + super-admin) looks solidListen up, my friend — this stack of scopes (read, write,
JANSLINK_ADMIN_ACCESS, thenSUPER_ADMIN_*) gives a nice gradation of privileges for the Jans Link plugin while reusing central super-admin constants. That’s a clean pattern to follow for other plugins too.Also applies to: 27-33
Signed-off-by: pujavs <[email protected]>
|
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/TrustRelationshipResource.java (1)
351-355: Validation uses the same getter twice; likely breaks GET vs POST URL semanticsHeads up, my friend: this condition looks off:
if (StringUtils.isBlank(trustRelationship.getSamlMetadata().getJansAssertionConsumerServiceGetURL()) && (StringUtils .isBlank(trustRelationship.getSamlMetadata().getJansAssertionConsumerServiceGetURL()))) { throwBadRequestException("Either of AssertionConsumerService GET or POST URL should be provided!"); }You’re calling the same
getJansAssertionConsumerServiceGetURL()twice, even though the error message says “GET or POST URL”. That means:
- If GET is blank, the condition ignores any POST value and always throws.
- If GET is non-blank, POST is never checked.
This contradicts the intent of “either GET or POST should be provided” and can block valid configurations.
I’d recommend updating the second check to use the POST URL accessor (whatever the actual method/field name is in
SamlMetadata) so the logic truly enforces “GET or POST”.jans-config-api/server/src/main/resources/config-api-rs-protect.json (1)
3353-3370: Assign distinct inum foridp/saml.deleteinstead of reusing1800.01.67The path
/jans-config-api/kc/saml/idpincorrectly maps two different scopes to the same inum:
idp/saml.write:inum: "1800.01.67"idp/saml.delete:inum: "1800.01.67"This violates the 1:1 scope-to-inum mapping pattern used throughout the file. For example,
oauth/config/samluses separate inums:1800.01.56(readonly),1800.01.57(write), and1800.01.577(delete). Use an available inum (e.g.,1800.01.48,1800.01.93, or1800.01.97) for the delete scope.
♻️ Duplicate comments (6)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java (1)
244-257: You better think twice! Thedetails()endpoint still has a mismatch, my friend!The OpenAPI security (line 248) includes
SCOPE_LICENSE_ADMIN, but the@ProtectedApiannotation (line 257) does NOT include it insuperScopes. This means a token with onlylicense.adminscope will be rejected at runtime, even though the API documentation claims it should be accepted.This was flagged in a previous review and marked as addressed, but the fix appears to be missing.
Apply this diff to align with the other endpoints:
- @ProtectedApi(scopes = {SCOPE_LICENSE_READ}, groupScopes = {SCOPE_LICENSE_WRITE}, superScopes = {AppConstants.SCOPE_ADMINUI_READ}) + @ProtectedApi(scopes = {SCOPE_LICENSE_READ}, groupScopes = {SCOPE_LICENSE_WRITE}, superScopes = {SCOPE_LICENSE_ADMIN, AppConstants.SCOPE_ADMINUI_READ})jans-config-api/plugins/docs/kc-saml-plugin-swagger.yaml (1)
124-131: Define theidp/saml.*scopes insecuritySchemesto keep the spec validListen up, my friend: multiple SAML IDP endpoints reference
https://jans.io/idp/saml.readonly,.write, and.deletein theirsecurityblocks, but the oauth2scopes:map at the bottom only defines the config-level saml scopes and the read/write/delete‑all super scopes. You better think twice before shipping this—OpenAPI validators expect every referenced scope to be declared undercomponents.securitySchemes.oauth2.flows.clientCredentials.scopes.Consider adding entries like:
components: securitySchemes: oauth2: flows: clientCredentials: scopes: https://jans.io/idp/saml.readonly: View SAML IdP resources https://jans.io/idp/saml.write: Manage SAML IdP resources https://jans.io/idp/saml.delete: Delete SAML IdP resourcesso all
idp/saml.*scopes used insecurity:are explicitly defined.Also applies to: 205-212, 275-283, 307-313, 487-495, 521-529, 555-563, 847-857, 889-899, 939-948, 1393-1407
jans-config-api/server/src/test/java/io/jans/configapi/test/auth/StatResourceTest.java (1)
23-27: UseApiAccessConstantsand fix the misleadingSUPER_ADMIN_SCOPEnameListen up, my friend: the test behavior looks good, but you better think twice about these scope literals:
INVALID_SCOPEandSUPER_ADMIN_SCOPEduplicate values already defined inApiAccessConstants(ATTRIBUTES_READ_ACCESS,STATS_USER_ADMIN_ACCESS).SUPER_ADMIN_SCOPEactually holds the feature admin scope (.../stats.admin), not a global super‑admin read/write‑all scope, which is confusing.To stay DRY and clear, consider:
-import static ...; +import io.jans.configapi.util.ApiAccessConstants; @@ - private static final String INVALID_SCOPE = "https://jans.io/oauth/config/attributes.readonly"; - private static final String SUPER_ADMIN_SCOPE = "https://jans.io/oauth/config/stats.admin"; + private static final String INVALID_SCOPE = ApiAccessConstants.ATTRIBUTES_READ_ACCESS; + private static final String STATS_ADMIN_SCOPE = ApiAccessConstants.STATS_USER_ADMIN_ACCESS; @@ - String adminToken = this.getAccessTokenForGivenScope(SUPER_ADMIN_SCOPE); + String adminToken = this.getAccessTokenForGivenScope(STATS_ADMIN_SCOPE);This keeps scopes centralized and makes the intent of the “admin” token obvious.
Also applies to: 29-61
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
36-38: AlignCACHE_ADMINS_ACCESSname with other*_ADMIN_ACCESSconstantsListen up, my friend: every other admin scope here is singular (
*_ADMIN_ACCESS), but cache usesCACHE_ADMINS_ACCESSwhile still pointing at.../cache.admin. It’s a small naming wobble that can confuse future readers.If this constant isn’t part of a public API yet, consider tightening it up like:
- public static final String CACHE_ADMINS_ACCESS = "https://jans.io/oauth/config/cache.admin"; + public static final String CACHE_ADMIN_ACCESS = "https://jans.io/oauth/config/cache.admin"; + @Deprecated + public static final String CACHE_ADMINS_ACCESS = CACHE_ADMIN_ACCESS;so the new name matches the pattern while keeping the old one as a safe alias.
jans-config-api/plugins/docs/user-mgt-plugin-swagger.yaml (1)
126-134: Document read-all/write-all/delete-all super-scopes in securitySchemesYou better think twice before shipping scopes in operations that aren’t declared in
components.securitySchemes: the user endpoints reference:
https://jans.io/oauth/config/read-all(GET list and GET by inum),https://jans.io/oauth/config/write-all(PUT/POST/PATCH),https://jans.io/oauth/config/delete-all(DELETE),but the
scopes:map currently only lists theuser.*scopes plususer.admin.Add matching entries under
components.securitySchemes.oauth2.flows.clientCredentials.scopesso the OpenAPI is self-consistent, e.g.:scopes: https://jans.io/oauth/config/user.readonly: View user related information https://jans.io/oauth/config/user.write: Manage user related information https://jans.io/oauth/config/user.delete: Delete user related information https://jans.io/oauth/config/user.admin: Admin to manage user related information + https://jans.io/oauth/config/read-all: Super admin for viewing application + resource information + https://jans.io/oauth/config/write-all: Super admin for updating application + resource information + https://jans.io/oauth/config/delete-all: Super admin for deleting application + resource informationAlso applies to: 352-357, 572-577, 690-697, 721-726, 875-880, 1006-1011
jans-config-api/plugins/docs/fido2-plugin-swagger.yaml (1)
40-45: Declare thefido2.adminscope in the OpenAPI security definitions.You're referencing
https://jans.io/oauth/config/fido2.adminacross multiple endpoint security blocks (lines 40–45, 72–75, 154–159, 199–202, 356–361, 552–557), but the OAuth2 scopes map (lines 862–871) only declaresfido2.readonly,fido2.write,fido2.delete,read-all,write-all, anddelete-all. The missingfido2.adminscope will cause OpenAPI generators and UI tools to flag incomplete schema definitions.Add the missing scope declaration:
scopes: https://jans.io/oauth/config/fido2.readonly: View fido2 related information https://jans.io/oauth/config/fido2.write: Manage fido2 related information https://jans.io/oauth/config/fido2.delete: Delete fido2 related information + https://jans.io/oauth/config/fido2.admin: Administer fido2 related information https://jans.io/oauth/config/read-all: Super admin for viewing application resource information https://jans.io/oauth/config/write-all: Super admin for updating application resource information https://jans.io/oauth/config/delete-all: Super admin for deleting application resource informationAlso applies to: 72-75, 154-159, 199-202, 356-361, 552-557, 866-871
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (19)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java(4 hunks)jans-config-api/docs/jans-config-api-swagger.yaml(136 hunks)jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java(11 hunks)jans-config-api/plugins/docs/fido2-plugin-swagger.yaml(7 hunks)jans-config-api/plugins/docs/jans-link-plugin-swagger.yaml(3 hunks)jans-config-api/plugins/docs/kc-link-plugin-swagger.yaml(4 hunks)jans-config-api/plugins/docs/kc-saml-plugin-swagger.yaml(17 hunks)jans-config-api/plugins/docs/scim-plugin-swagger.yaml(3 hunks)jans-config-api/plugins/docs/user-mgt-plugin-swagger.yaml(7 hunks)jans-config-api/plugins/kc-link-plugin/src/main/java/io/jans/configapi/plugin/kc/link/rest/ApiApplication.java(2 hunks)jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/ApiApplication.java(2 hunks)jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/TrustRelationshipResource.java(7 hunks)jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ApiApplication.java(2 hunks)jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ScimConfigResource.java(3 hunks)jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/JwksResource.java(7 hunks)jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/TokenResource.java(4 hunks)jans-config-api/server/src/main/resources/config-api-rs-protect.json(145 hunks)jans-config-api/server/src/test/java/io/jans/configapi/test/auth/AssetResourceTest.java(1 hunks)jans-config-api/server/src/test/java/io/jans/configapi/test/auth/StatResourceTest.java(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-14T12:07:49.986Z
Learnt from: moabu
Repo: JanssenProject/jans PR: 12687
File: terraform-provider-jans/jans/schemas.go:44-61
Timestamp: 2025-11-14T12:07:49.986Z
Learning: In terraform-provider-jans/jans/schemas.go, the SCIM schema endpoints (/jans-scim/restv1/v2/Schemas/) are public discovery endpoints per RFC 7644 and do not require OAuth scopes or authentication tokens. The GetSchemas and GetSchema methods intentionally pass empty strings for token and scope parameters.
Applied to files:
jans-config-api/docs/jans-config-api-swagger.yamljans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ApiApplication.javajans-config-api/plugins/docs/scim-plugin-swagger.yamljans-config-api/server/src/main/resources/config-api-rs-protect.jsonjans-config-api/plugins/docs/fido2-plugin-swagger.yamljans-config-api/plugins/docs/jans-link-plugin-swagger.yamljans-config-api/plugins/docs/user-mgt-plugin-swagger.yaml
📚 Learning: 2025-11-18T07:43:55.761Z
Learnt from: pujavs
Repo: JanssenProject/jans PR: 12704
File: jans-config-api/docs/jans-config-api-swagger.yaml:17540-17546
Timestamp: 2025-11-18T07:43:55.761Z
Learning: The file `jans-config-api/docs/jans-config-api-swagger.yaml` is auto-generated with dependent modules changes and metadata. The config API does not override it.
Applied to files:
jans-config-api/plugins/docs/scim-plugin-swagger.yamljans-config-api/server/src/main/resources/config-api-rs-protect.jsonjans-config-api/plugins/docs/jans-link-plugin-swagger.yaml
🧬 Code graph analysis (5)
jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/TrustRelationshipResource.java (2)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-142)jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/util/Constants.java (1)
Constants(13-101)
jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ScimConfigResource.java (1)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-142)
jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ApiApplication.java (1)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-142)
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/TokenResource.java (1)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-142)
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/JwksResource.java (1)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-142)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: sonar scan (jans-lock)
- GitHub Check: sonar scan (jans-fido2)
🔇 Additional comments (33)
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/TokenResource.java (4)
55-70: LGTM! Security annotations forgetTokenByIdare consistent, my friend!Like a wise ol' pigeon checkin' every crumb, I've verified that the
@Operation.securityscopes align perfectly with the@ProtectedApiconfiguration. The read operation appropriately usesTOKEN_READ_ACCESSas the base scope, withTOKEN_WRITE_ACCESSas group scope, and admin/super-admin scopes properly elevated. Let's get this party rollin'!
89-104: LGTM! Security annotations forgetClientTokenare aligned!Listen up! This endpoint follows the same consistent pattern as
getTokenById- the security requirements between OpenAPI docs and runtime enforcement are perfectly synchronized. Good vibes all around!
132-147: LGTM! Security annotations forsearchTokenEntriesfollow the established pattern!You better think twice before doubtin' this one - it's rock solid! The search endpoint maintains the same well-structured scope hierarchy as the other read operations. Consistency is key, and this delivers!
172-186: LGTM! Scope mismatch from previous review has been properly resolved!Now we're havin' some fun! The previously flagged inconsistency between
@Operation.securityand@ProtectedApi.superScopeshas been addressed. Both now correctly specifySUPER_ADMIN_DELETE_ACCESSfor this DELETE operation, which aligns with least-privilege principles. The docs and enforcement are now singing the same tune!jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/ApiApplication.java (2)
6-6: Yo, that import's lookin' sharp!The ApiAccessConstants import is necessary for those fancy SUPER_ADMIN scopes you're bringin' to the party below. Nice and clean!
34-38: All scope constants are properly defined and enforced across resource endpoints.Verification confirms:
- Constants.SAML_ADMIN_ACCESS, SAML_CONFIG_WRITE_ACCESS, and all SUPER_ADMIN_* constants are defined and referenced correctly
- Scopes are enforced via @ProtectedApi annotations with clear hierarchy: granular scopes < SAML_ADMIN_ACCESS < SUPER_ADMIN_* scopes
- SUPER_ADMIN_* scopes (read-all, write-all, delete-all) consistently serve as cross-feature overrides
- SecurityRequirement annotations properly expose scopes in OpenAPI documentation
No issues identified.
jans-config-api/plugins/kc-saml-plugin/src/main/java/io/jans/configapi/plugin/saml/rest/TrustRelationshipResource.java (7)
11-11: ImportingApiAccessConstantsis appropriate and scoped correctlyYou’re only using
ApiAccessConstantsfor super-admin scopes in this class, and the new import is clean and necessary with no unused baggage. Looks tidy, my friend.
60-67: List endpoint now treats super-admins and SAML admin/write consistentlyNice alignment here, my friend: the list
GETnow allows:
- Feature scopes:
SAML_READ_ACCESS(primary), plusSAML_WRITE_ACCESSandSAML_ADMIN_ACCESS- Super scopes:
SUPER_ADMIN_READ_ACCESSandSUPER_ADMIN_WRITE_ACCESSvia both@Operation.securityand@ProtectedApi.superScopesThis avoids the weird “can write but can’t read” situation for write-all super-admin tokens and keeps read behavior consistent with other SAML endpoints.
Also applies to: 72-74
81-87:getTrustRelationshipByIdsuper-admin wiring matches the list endpointYou mirrored the same scope story for the “get by id”
GET:
- Feature read/write/admin + super-admin read/write in
@Operation.security@ProtectedApiwithSAML_READ_ACCESSas base,SAML_WRITE_ACCESSas group, and bothSUPER_ADMIN_READ_ACCESS/SUPER_ADMIN_WRITE_ACCESSas superScopesThat keeps behavior predictable across list and detail reads for SAML trust relationships. Solid move.
Also applies to: 94-96
118-123: Create (POST) endpoint correctly restricted to write/admin-level scopesFor creation with metadata file, you now require:
- Feature write or admin (
SAML_WRITE_ACCESS,SAML_ADMIN_ACCESS)- Or global write-all (
SUPER_ADMIN_WRITE_ACCESS)
@Operation.securityand@ProtectedApi.superScopesline up, withSAML_WRITE_ACCESSas the base scope. That’s a clean “no read-only super-admins writing config” stance, exactly what you want at this layer.Also applies to: 132-133
178-182: Update (PUT) endpoint mirrors create semantics for scopesSame story on update, my friend: only
SAML_WRITE_ACCESS/SAML_ADMIN_ACCESS- or
SUPER_ADMIN_WRITE_ACCESSare permitted via OpenAPI security and
@ProtectedApi. This keeps write paths coherent across POST and PUT and avoids over-permissive read/delete super scopes sneaking in.Also applies to: 190-191
259-263: Delete endpoint correctly bound to delete/admin super scopesThe delete
DELETEnow limits access to:
SAML_DELETE_ACCESS(base)SAML_ADMIN_ACCESSSUPER_ADMIN_DELETE_ACCESSwith
@Operation.securityand@ProtectedApi.superScopesin sync. That’s a nice, sharp separation of write-all vs delete-all responsibilities — you’re not silently giving delete to write-all tokens, which is a good security posture.Also applies to: 268-269
287-299: File-metadataGETendpoint scopes and response metadata look consistentYou’ve got this one wired like the other read endpoints:
- Feature scopes:
SAML_READ_ACCESSplusSAML_WRITE_ACCESSandSAML_ADMIN_ACCESS- Super scopes: both
SUPER_ADMIN_READ_ACCESSandSUPER_ADMIN_WRITE_ACCESSin@Operation.securityand@ProtectedApi.superScopesOn top of that, the
@ApiResponsesnow correctly advertise XML (MediaType.APPLICATION_XML) and a binary schema for the 200 response, which matches the actual behavior. That’s clear, accurate surface area for clients.Also applies to: 302-304
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java (7)
49-62: LGTM! Let's get this party rollin'!The
isActiveendpoint properly aligns OpenAPI security with@ProtectedApienforcement. The admin scope is correctly placed insuperScopesfor proper escalation.
77-89: LGTM! Ready to have some fun with this one!The
deleteLicenseConfigurationendpoint correctly enforces write scopes with proper admin escalation. EmptygroupScopesis appropriate since this is a write-only operation.
104-117: LGTM! Like a wise ol' pigeon, this looks spot on!The
retrieveLicenseendpoint maintains consistency between OpenAPI security and@ProtectedApiannotations with the new admin scope properly included.
132-145: LGTM! The scope configuration is consistent, my friend!The
trialendpoint properly aligns security requirements between OpenAPI and enforcement layer.
160-173: LGTM! Let's keep this party rollin'!The
activateendpoint correctly enforces write scopes with admin escalation viasuperScopes.
188-201: LGTM! Lookin' good, my friend!The
ssaendpoint follows the same correct pattern as other write endpoints with proper admin scope escalation.
216-229: LGTM! You fixed that duplicate issue, nice work!The
isConfigValidendpoint now correctly has single instances of each scope and proper alignment between OpenAPI and@ProtectedApi.jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ScimConfigResource.java (1)
45-51: SCIM config security alignment looks solidListen up, my friend: GET and PATCH now consistently honor feature admin and super-admin scopes (read/write) across both
@Operationand@ProtectedApi. The layering ofSCIM_READ_ACCESSwith groupSCIM_WRITE_ACCESSand super scopes (SCIM + SUPER_ADMIN_* ) is coherent and matches the broader pattern in this PR.Also applies to: 57-59, 66-70, 79-80
jans-config-api/server/src/test/java/io/jans/configapi/test/auth/AssetResourceTest.java (1)
22-59: Good coverage of asset authorization pathsLike a wise ol’ pigeon, I see these tests cleanly distinguish invalid vs admin scopes using
ApiAccessConstants, and assert the right 401/200 outcomes. Solid, DRY, and aligned with the new asset admin scope.jans-config-api/plugins/scim-plugin/src/main/java/io/jans/configapi/plugin/scim/rest/ApiApplication.java (1)
10-12: SCIM OAuth2 security scheme is consistent and well-scopedLike a wise ol’ pigeon, I see the SCIM plugin now cleanly exposes feature scopes (read/write/admin) alongside the SUPER_ADMIN read/write/delete scopes in the OAuth2 flow, matching the resource annotations and giving clients a clear contract.
Also applies to: 27-34
jans-config-api/plugins/kc-link-plugin/src/main/java/io/jans/configapi/plugin/kc/link/rest/ApiApplication.java (1)
3-5: KC Link security scheme matches the new admin modelListen up, my friend: KC Link now advertises read, write, and KC-specific admin scopes plus the SUPER_ADMIN read/write/delete scopes in one coherent OAuth2 scheme, lining up with the swagger and resource annotations.
Also applies to: 26-33
jans-config-api/plugins/docs/kc-link-plugin-swagger.yaml (1)
37-46: KC Link swagger security is consistent and fully declaredLike a wise ol’ pigeon, I can see the KC Link endpoints now cleanly require feature read/write, KC admin, and super‑admin scopes, with all of those scopes properly documented under
securitySchemes.oauth2.flows.clientCredentials.scopes. This keeps clients and server in sync.Also applies to: 75-80, 111-116, 281-298
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/JwksResource.java (1)
54-69: JWKS endpoint security annotations are now consistent and alignedNice cleanup here: for all JWKS endpoints,
@Operation.securityand@ProtectedApinow agree on:
- base scopes (read/write/delete),
- groupScopes (write where appropriate),
- superScopes (
JWKS_ADMIN_ACCESSplus the right SUPER_ADMIN_* variants).This removes the earlier mismatch on the patch-by-kid endpoint and keeps runtime enforcement in lockstep with the OpenAPI docs.
Also applies to: 75-88, 97-111, 122-135, 156-170, 180-194, 221-232
jans-config-api/plugins/docs/jans-link-plugin-swagger.yaml (1)
37-44: Jans Link scopes and securitySchemes are now wired up correctlyYou closed the loop nicely here:
- GET and PUT operations advertise
jans-link.readonly,jans-link.write,link.admin, and the super-scopes (read-all,write-all).components.securitySchemes.oauth2.flows.clientCredentials.scopesnow defines all of these URIs (plusdelete-all) with clear descriptions.This keeps the generated swagger in sync with your Java annotations and avoids undefined-scope surprises for clients.
Also applies to: 69-74, 224-235
jans-config-api/plugins/docs/scim-plugin-swagger.yaml (1)
37-46: SCIM config scopes are fully documented and consistent with operationsFor SCIM config, the OpenAPI now lines up:
- GET exposes readonly + write +
scim.admin+read-all/write-all.- PATCH uses write +
scim.admin+write-all.- All of these URIs are declared under
components.securitySchemes.oauth2.flows.clientCredentials.scopes, including the delete-all super-scope.Looks solid and matches the broader admin/super-admin pattern.
Also applies to: 74-79, 142-152
jans-config-api/docs/jans-config-api-swagger.yaml (5)
71-77: You better think twice! 🐦 New admin scopes follow consistent pattern across endpoints.The security definitions now include
.adminvariants alongside existing readonly/write/delete scopes, plus super-adminread-all/write-all/delete-allalternatives. This pattern holds steady across hunks 1–129. The prior namespace fixes (CLIENT_AUTHORIZATIONS_ADMIN_ACCESS →/oauth/client/, UMA naming cleanup) are confirmed in place, so that's solid.
2764-2764: 🐦 Authorization scopes correctly use/oauth/client/namespace (✅ prior fix confirmed).Lines 2764 and 2890 show
authorizations.adminusing the/oauth/client/namespace, which matches the fix applied toApiAccessConstants.javaline 128. This is consistent with existingauthorizations.readonlyandauthorizations.deletescopes on lines 2762 and 2888.Also applies to: 2890-2890
3565-3575: 🐦 OpenID clients admin scope integration looks good.The new
clients.adminscope (lines 3571, 4170) is properly placed between write and read-all/write-all scopes, maintaining the expected scope hierarchy. Matches the pattern across other resources.Also applies to: 4166-4174
14997-15005: 🐦 UMA resource scopes use correct naming (✅ prior fix confirmed).UMA scopes now consistently use
uma-read,uma-write,uma-delete(hyphen) withuma.admin(dot). Per prior review, this naming standardization was confirmed fixed in source constants. The pattern is consistent across all UMA endpoints in the spec.Also applies to: 15069-15073, 15185-15193, 15218-15222, 15281-15285, 15351-15359
130-136: Clarify the scope of schema field verification and correct line number references.The swagger.yaml file is indeed auto-generated from Java source via the swagger-maven-plugin, but with an important distinction: while the OpenAPI schema is generated from Java annotations and models, the example objects are loaded from manually-maintained JSON files (e.g.,
example/attribute/attribute-get-all.json).The lines you reference (130–136) contain a standard endpoint definition, not schema field additions. The actual schema example fields (whitePagesCanView, adminCanEdit, userCanAccess, userCanView, selected, etc.) appear starting around line 1407 in the example response objects, sourced from the attribute example JSON files. The scope documentation you mention is indeed at lines 18627–18655 and documents admin scopes correctly.
To properly verify whether these example fields align with the feature scope, you should:
- Examine the JansAttribute model class (
jans-core/service/src/main/java/io/jans/model/JansAttribute.java) to confirm these fields are actual model properties, not just example data- Check if the example JSON files were recently updated as part of this admin scope feature and whether they accurately reflect the model
...ns/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java
Outdated
Show resolved
Hide resolved
Signed-off-by: pujavs <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
jans-config-api/docs/jans-config-api-swagger.yaml(134 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-14T12:07:49.986Z
Learnt from: moabu
Repo: JanssenProject/jans PR: 12687
File: terraform-provider-jans/jans/schemas.go:44-61
Timestamp: 2025-11-14T12:07:49.986Z
Learning: In terraform-provider-jans/jans/schemas.go, the SCIM schema endpoints (/jans-scim/restv1/v2/Schemas/) are public discovery endpoints per RFC 7644 and do not require OAuth scopes or authentication tokens. The GetSchemas and GetSchema methods intentionally pass empty strings for token and scope parameters.
Applied to files:
jans-config-api/docs/jans-config-api-swagger.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: sonar scan (jans-casa)
- GitHub Check: sonar scan (jans-config-api)
- GitHub Check: sonar scan (jans-fido2)
- GitHub Check: sonar scan (jans-linux-setup)
- GitHub Check: cleanup
🔇 Additional comments (2)
jans-config-api/docs/jans-config-api-swagger.yaml (2)
18627-18655: Scope description section now documents admin scopes — verify completeness and accuracy.The updated descriptions (lines 18627–18655) document all new admin scopes and highlight the mixed namespace patterns across resources (e.g.,
/oauth/config/,/oauth/jans-auth-server/config/,/auth/,/oauth/client/). Ensure these namespace choices are intentional and align with the Java constants that auto-generate this file.
14289-14297: SSA scope namespace is intentionally split between/oauth/config/and/auth/— confirm if this design is intentional.The source constants in
ApiAccessConstants.java(lines 136-140) deliberately define SSA scopes with different namespaces:ssa.write,ssa.delete, andssa.readonlyuse/oauth/config/, whilessa.adminuses/auth/. This is not a YAML generation artifact but a deliberate choice in the Java source.Before treating this as an inconsistency requiring fix, clarify whether this namespace split is architectural intent (admin capabilities in
/auth/vs. CRUD operations in/oauth/config/) or an oversight. If it requires standardization, the fix belongs inApiAccessConstants.java, not the YAML.
Signed-off-by: pujavs <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java (1)
175-186: Minor typo in log message.Line 178 has a typo: "licese-key" should be "license-key".
public Response activate(@Valid @NotNull LicenseRequest licenseRequest) { GenericResponse licenseResponse = null; try { - log.info("Trying to activate license using licese-key."); + log.info("Trying to activate license using license-key."); licenseResponse = licenseDetailsService.activateLicense(licenseRequest);jans-config-api/server/src/main/resources/config-api-rs-protect.json (1)
3410-3432: Fix duplicate inum for idp/saml.delete scope.The DELETE condition for idp/saml (line 3416) incorrectly uses inum
1800.01.67, which is already assigned to the write scope (lines 3367 and 3394). Each distinct scope must map to a unique inum to maintain proper authorization enforcement. Assign a new, unused inum tohttps://jans.io/idp/saml.delete.
♻️ Duplicate comments (1)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/adminui/AdminUIResource.java (1)
55-59: SCOPE_ROLE_PERMISSION_MAPPING_ADMIN constant is still unused.This is a duplicate of a previous review comment. The
SCOPE_ROLE_PERMISSION_MAPPING_ADMINconstant is defined here but is never used in the role-permission mapping endpoints (lines 501-658). All those endpoints still referenceSCOPE_PERMISSION_ADMINinstead.To maintain consistency with the role and permission admin scopes, update all role-permission mapping endpoints to use
SCOPE_ROLE_PERMISSION_MAPPING_ADMINin both the@Operation.securityand@ProtectedApi.superScopesannotations.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java(4 hunks)jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/ApiApplication.java(1 hunks)jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/adminui/AdminUIResource.java(31 hunks)jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java(11 hunks)jans-config-api/server/src/main/resources/config-api-rs-protect.json(145 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-18T07:43:55.761Z
Learnt from: pujavs
Repo: JanssenProject/jans PR: 12704
File: jans-config-api/docs/jans-config-api-swagger.yaml:17540-17546
Timestamp: 2025-11-18T07:43:55.761Z
Learning: The file `jans-config-api/docs/jans-config-api-swagger.yaml` is auto-generated with dependent modules changes and metadata. The config API does not override it.
Applied to files:
jans-config-api/server/src/main/resources/config-api-rs-protect.json
📚 Learning: 2025-11-14T12:07:49.986Z
Learnt from: moabu
Repo: JanssenProject/jans PR: 12687
File: terraform-provider-jans/jans/schemas.go:44-61
Timestamp: 2025-11-14T12:07:49.986Z
Learning: In terraform-provider-jans/jans/schemas.go, the SCIM schema endpoints (/jans-scim/restv1/v2/Schemas/) are public discovery endpoints per RFC 7644 and do not require OAuth scopes or authentication tokens. The GetSchemas and GetSchema methods intentionally pass empty strings for token and scope parameters.
Applied to files:
jans-config-api/server/src/main/resources/config-api-rs-protect.json
🧬 Code graph analysis (1)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java (3)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/adminui/AdminUIResource.java (1)
Path(33-680)jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/TokenResource.java (1)
Path(38-232)jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/JwksResource.java (1)
Path(43-255)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: cleanup
- GitHub Check: sonar scan (jans-keycloak-integration)
- GitHub Check: sonar scan (jans-scim)
- GitHub Check: sonar scan (jans-config-api)
🔇 Additional comments (20)
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/license/LicenseResource.java (6)
39-41: LGTM! Admin scope constant follows established patterns.The new
SCOPE_LICENSE_ADMINconstant uses a consistent URL pattern with the existingSCOPE_LICENSE_READandSCOPE_LICENSE_WRITEscopes, aligning with other admin scopes in the admin-ui plugin (e.g.,SCOPE_ROLE_ADMIN,SCOPE_PERMISSION_ADMIN).
49-62: LGTM! Security configuration is consistent.The OpenAPI
@SecurityRequirementannotations align correctly with the@ProtectedApiannotation. The scope hierarchy (read → write → admin) is properly configured for this read operation.
77-89: LGTM! Write endpoint security is correctly configured.The DELETE operation correctly requires write scope as primary with admin scopes as super. The empty
groupScopesis appropriate for write-only operations.
104-145: LGTM! Read endpoint security patterns are consistent.Both
retrieveLicenseandtrialendpoints follow the same security pattern asisActive, maintaining consistency across read operations.
188-201: LGTM! Write endpoint security is correctly configured.The
ssaendpoint follows the same security pattern as other write operations (activate,deleteLicenseConfiguration).
216-257: LGTM! Previous review issues have been addressed.Both
isConfigValidanddetailsendpoints now correctly includeSCOPE_LICENSE_ADMINin theirsuperScopeswithout any duplicates. The security configuration aligns with the OpenAPI security requirements.jans-config-api/server/src/main/resources/config-api-rs-protect.json (4)
3837-4024: LGTM: jans-assets resources and variants are well-structured.The new jans-assets resource and its variants (name, services, asset-type, asset-dir-mapping) follow consistent patterns with properly mapped admin scopes (
1800.05.32) and appropriate read/write/delete authorization levels. Scope inum mappings are coherent across conditions.
4597-4631: Clarify empty inum in SSA resource scope definition.Line 4609 defines a scope with an empty
inumvalue ("") forhttps://jans.io/auth/ssa.admin. While the file does contain other empty inums (e.g.,jans_statat earlier lines), this appears anomalous in a DELETE condition context. If this scope is a legacy or external scope, confirm it is intentional. If it should have an inum assigned, align it with the established inum sequence (e.g.,1800.05.34or another appropriate value).
3087-3110: The proposed fix is incorrect. While1800.01.577at line 3093 does deviate from the typical 2-digit inum pattern in this file, changing it to1800.01.67would create a conflict:1800.01.67is already used elsewhere in the file forhttps://jans.io/idp/saml.writeandhttps://jans.io/idp/saml.delete. Assigning the same inum to multiple distinct scopes would violate the uniqueness requirement for OAuth scope identifiers.If
1800.01.577is indeed an error, further investigation is needed to determine the correct intended inum value, but it should not be a value already assigned to another scope.Likely an incorrect or invalid review comment.
3819-3833: The lockConfig resource scopes are correctly designed and do not require changes. The GET condition appropriately uses config-level read and write scopes (1800.03.1and1800.03.2), while the PUT/PATCH condition uses the lock-specific write scope (1800.03.5) in addition to config write-all. This differentiation is intentional: read operations on configuration should use config read scopes, while write operations on lock-related configuration should require lock write authorization. This pattern is consistent with other lock endpoints (e.g., lock/audit uses1800.03.4for read and1800.03.5for write operations). No alignment is needed.jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/adminui/AdminUIResource.java (3)
137-151: LGTM! Consistent admin scope application for role read endpoint.The role read endpoint now correctly includes
SCOPE_ROLE_ADMINalongside the read and write scopes in both the OpenAPI security metadata and the@ProtectedApiannotation. This provides proper admin-level override capability.
173-187: LGTM! Role write, edit, and delete endpoints correctly secured.All role mutation endpoints (add, edit, delete) consistently apply
SCOPE_ROLE_ADMINas a super scope alongsideAppConstants.SCOPE_ADMINUI_WRITEorAppConstants.SCOPE_ADMINUI_DELETE. The security configuration is uniform and correct.Also applies to: 209-223, 281-294
316-330: LGTM! Permission endpoints consistently secured with admin scope.All permission endpoints (read, write, edit, delete) properly include
SCOPE_PERMISSION_ADMINin their security requirements and@ProtectedApi.superScopes. The implementation parallels the role endpoints and maintains consistency across the Admin UI permission management layer.Also applies to: 352-366, 388-402, 424-438, 460-474
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (7)
11-11: LGTM! Core feature admin constants follow consistent patterns.The admin constants for auth config, attributes, ACRs, database, and scripts all follow the expected URI pattern matching their read/write/delete siblings. The distinction between
jans-auth-serverandconfigpaths is appropriate for the respective subsystems.Also applies to: 16-16, 20-20, 25-25, 34-34
38-38: LGTM! Infrastructure admin constants properly defined.The admin constants for cache, message, SMTP, logging, and JWKS are correctly defined with distinct
.adminURIs. Previous issues (typo inCACHE_ADMINS_ACCESSandMESSAGE_ADMIN_ACCESSreusing write URI) have been resolved.Also applies to: 42-42, 47-47, 51-51, 56-56
61-61: LGTM! OAuth-related admin constants correctly aligned.OpenID clients, token, and scopes admin constants now follow consistent URI patterns matching their siblings. Previous issues (missing path segments and URI reuse) have been addressed:
OPENID_CLIENTS_ADMIN_ACCESSincludes/openid/TOKEN_ADMIN_ACCESSincludes/configSCOPES_ADMIN_ACCESSuses distinct.adminURIAlso applies to: 66-66, 71-71
74-74: LGTM! User management admin constants properly configured.Stats, organization, user, and Agama admin constants follow consistent patterns. The previous typo in
STATS_USER_ASMIN_ACCESShas been corrected toSTATS_USER_ADMIN_ACCESS.Also applies to: 79-79, 84-84, 89-89
98-98: LGTM! Session admin constant uses correct path.
JANS_AUTH_SESSION_ADMIN_ACCESSnow correctly uses the/jans-auth-server/path, consistent with its read and delete siblings. The previous path inconsistency has been resolved.
113-113: LGTM! Feature-level admin constants defined consistently within their families.UMA, plugin, config, and client authorizations admin constants are defined correctly. Note that URL naming conventions vary by scope family (e.g., UMA uses dashes like
uma-adminwhile plugin uses dots likeplugin.admin), but each constant is consistent with its respective read/write/delete siblings.Also applies to: 116-116, 120-120, 124-124
132-132: LGTM! Asset and health admin constants correctly defined.
JANS_ASSET_ADMIN_ACCESSfollows thejans_asset-adminpattern matching its read/write/delete siblings.HEALTH_ADMINuses the standard.adminsuffix. Both are correctly aligned with their respective scope families.Also applies to: 141-141
|
|
||
| // Feature Scope | ||
| public static final String OPENID_READ_ACCESS = "https://jans.io/oauth/config/openid-read"; | ||
| public static final String OPENID_READ_ACCESS = "https://jans.io/oauth/config/openid/openid-read"; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check usage of OPENID_READ_ACCESS across the codebase
rg -n --type java 'OPENID_READ_ACCESS' -C 2Repository: JanssenProject/jans
Length of output: 3798
🏁 Script executed:
# Check the ApiAccessConstants file to see all OPENID_* constants and naming patterns
rg -n --type java 'public static final String OPENID' -A 0 -B 0Repository: JanssenProject/jans
Length of output: 1845
🏁 Script executed:
# Check for other scope constants to understand naming conventions
rg -n --type java 'public static final String.*= "https' | head -30Repository: JanssenProject/jans
Length of output: 6097
OPENID_READ_ACCESS uses inconsistent scope naming pattern within the same constants file.
The OPENID_READ_ACCESS constant (line 106) uses dash notation (openid-read), while resource-specific scopes in the same file like OPENID_CLIENTS_READ_ACCESS (line 58) use dot notation (clients.readonly). Although the comment "Feature Scope" suggests this distinction is intentional, the inconsistency within ApiAccessConstants.java is problematic. Either document this design decision clearly with inline comments explaining why feature-level scopes use dashes while resource scopes use dots, or standardize on a single naming convention across all OPENID scopes.
🤖 Prompt for AI Agents
In
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java
around line 106, the OPENID_READ_ACCESS value uses dash notation ("openid-read")
while other OPENID resource scopes use dot notation ("clients.readonly");
standardize this by changing the OPENID_READ_ACCESS scope string to use dot
notation (e.g., "openid.read" or follow the existing resource pattern), update
any code references/tests that rely on the old string, and ensure the file
contains a short inline comment asserting the chosen naming convention for all
OPENID scopes so future contributors understand the decision.
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/role.admin", description = "Manage admin user role related information"), | ||
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/permission.admin", description = "Manage admin permission related information"), | ||
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/rolePermissionMapping.admin", description = "Manage admin role-permission related information") |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, locate and read the ApiApplication.java file to verify exact descriptions
fd -t f "ApiApplication.java" jans-config-api/plugins/admin-ui-plugin/Repository: JanssenProject/jans
Length of output: 167
🏁 Script executed:
#!/bin/bash
# Read the file around the specified lines to see exact descriptions
sed -n '40,65p' jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/ApiApplication.java | cat -nRepository: JanssenProject/jans
Length of output: 2826
🏁 Script executed:
#!/bin/bash
# Search for @ProtectedApi annotations that reference these scopes
rg -n '@ProtectedApi|role\.(admin|write)|permission\.(admin|write)|rolePermissionMapping\.(admin|write)' \
jans-config-api/plugins/admin-ui-plugin/ --type java -C 2Repository: JanssenProject/jans
Length of output: 47339
🏁 Script executed:
#!/bin/bash
# Check git history to see if there's any pattern or discussion about .admin scopes
git log --oneline --all -20 -- '*ApiApplication.java' | head -20Repository: JanssenProject/jans
Length of output: 174
🏁 Script executed:
#!/bin/bash
# Search for any documentation or comments about the .admin scope semantics
rg -n "\.admin|superScopes" jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/adminui/AdminUIResource.java -B 2 -A 2 | head -50Repository: JanssenProject/jans
Length of output: 2531
Update OAuth scope descriptions to clearly differentiate .write and .admin levels.
Lines 18-20 define .admin scopes with descriptions identical to their corresponding .write scopes (lines 9, 11, 13), creating confusion about authorization levels:
role.writeandrole.admin: both say "Manage admin user role related information"permission.writeandpermission.admin: both say "Manage admin permission related information"rolePermissionMapping.writeandrolePermissionMapping.admin: nearly identical descriptions
While these scopes are correctly enforced as superScopes in @ProtectedApi annotations throughout the codebase, the descriptions don't reflect the intended super-user level access difference. Update descriptions to clarify the hierarchy, for example:
-@OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/role.admin", description = "Manage admin user role related information"),
-@OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/permission.admin", description = "Manage admin permission related information"),
-@OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/rolePermissionMapping.admin", description = "Manage admin role-permission related information")
+@OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/role.admin", description = "Full administrative access to admin user roles (super-user level)"),
+@OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/permission.admin", description = "Full administrative access to admin permissions (super-user level)"),
+@OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/rolePermissionMapping.admin", description = "Full administrative access to role-permission mappings (super-user level)")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/role.admin", description = "Manage admin user role related information"), | |
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/permission.admin", description = "Manage admin permission related information"), | |
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/rolePermissionMapping.admin", description = "Manage admin role-permission related information") | |
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/role.admin", description = "Full administrative access to admin user roles (super-user level)"), | |
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/permission.admin", description = "Full administrative access to admin permissions (super-user level)"), | |
| @OAuthScope(name = "https://jans.io/oauth/jans-auth-server/config/adminui/user/rolePermissionMapping.admin", description = "Full administrative access to role-permission mappings (super-user level)") |
🤖 Prompt for AI Agents
In
jans-config-api/plugins/admin-ui-plugin/src/main/java/io/jans/ca/plugin/adminui/rest/ApiApplication.java
around lines 57 to 59, the OAuth scope descriptions for the .admin scopes are
identical to the .write scopes causing confusion about privilege level; update
the description text for each .admin scope to explicitly indicate they are
super-user or administrative scopes (e.g., "Full administrative access to manage
user roles including higher-privilege operations and overrides") so they clearly
differ from the .write descriptions that denote standard write/change
permissions.
Signed-off-by: pujavs <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (4)
jans-config-api/docs/jans-config-api-swagger.yaml(135 hunks)jans-config-api/plugins/docs/jans-admin-ui-plugin-swagger.yaml(25 hunks)jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java(1 hunks)jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/CacheConfigurationResource.java(18 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-18T07:43:55.761Z
Learnt from: pujavs
Repo: JanssenProject/jans PR: 12704
File: jans-config-api/docs/jans-config-api-swagger.yaml:17540-17546
Timestamp: 2025-11-18T07:43:55.761Z
Learning: The file `jans-config-api/docs/jans-config-api-swagger.yaml` is auto-generated with dependent modules changes and metadata. The config API does not override it.
Applied to files:
jans-config-api/docs/jans-config-api-swagger.yamljans-config-api/plugins/docs/jans-admin-ui-plugin-swagger.yaml
📚 Learning: 2025-11-14T12:07:49.986Z
Learnt from: moabu
Repo: JanssenProject/jans PR: 12687
File: terraform-provider-jans/jans/schemas.go:44-61
Timestamp: 2025-11-14T12:07:49.986Z
Learning: In terraform-provider-jans/jans/schemas.go, the SCIM schema endpoints (/jans-scim/restv1/v2/Schemas/) are public discovery endpoints per RFC 7644 and do not require OAuth scopes or authentication tokens. The GetSchemas and GetSchema methods intentionally pass empty strings for token and scope parameters.
Applied to files:
jans-config-api/docs/jans-config-api-swagger.yaml
🧬 Code graph analysis (1)
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/CacheConfigurationResource.java (1)
jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java (1)
ApiAccessConstants(3-142)
🔇 Additional comments (11)
jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/CacheConfigurationResource.java (6)
69-86: LGTM!The security scope expansion for the GET endpoint follows the correct pattern: read operations are accessible via READ, WRITE (via groupScopes), and all admin scopes (via superScopes). The
@Operationsecurity requirements align with the@ProtectedApiannotation.
88-112: LGTM!The PATCH endpoint correctly restricts access to write-capable scopes only (WRITE, ADMIN, SUPER_WRITE). The exclusion of read-only scopes from write operations is the correct security posture.
114-184: LGTM!Redis cache configuration endpoints (GET, PUT, PATCH) follow the established scope patterns consistently. Read operations include all applicable scopes, and write operations correctly exclude read-only scopes.
186-256: LGTM!In-Memory cache configuration endpoints follow the same consistent security pattern as the other cache endpoints.
258-330: LGTM!Native-Persistence cache configuration endpoints maintain consistency with the security scope pattern established across all cache endpoints.
332-402: LGTM!Memcached cache configuration endpoints complete the consistent security scope expansion pattern. All endpoints properly distinguish between read and write access requirements.
jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java (1)
126-149: Confirm: All 24 admin scope constants are properly defined and actively used in resource annotations.Verification confirms:
- All constants are properly defined in
ApiAccessConstants.javawith correct.adminsuffix values (e.g.,https://jans.io/oauth/config/properties.admin)- All 24 scopes are actively referenced across resource classes via
@SecurityRequirementand@ProtectedApiannotations in 116+ locations (AuthConfigResource, AcrsResource, AttributesResource, CacheConfigurationResource, ClientsResource, CustomScriptResource, ConfigApiResource, ConfigSmtpResource, DatabaseResource, JwksResource, LdapConfigurationResource, LoggingResource, MessageConfigurationResource, OrganizationResource, PluginResource, ScopesResource, SessionResource, SsaResource, StatResource, TokenResource, UmaResourcesResource, AssetResource, AgamaResource, ClientAuthResource, and ApiHealthCheck)The authorization surface expansion is properly controlled and consistently enforced across the API.
jans-config-api/docs/jans-config-api-swagger.yaml (1)
18627-18655: Scope descriptions are comprehensive and well-documented.The new admin scope descriptions (lines 18627–18655) clearly articulate the purpose of each feature-wise admin scope (e.g., "Admin for Attribute management", "Admin for ACRS management"). This aligns well with the PR objective of introducing feature-wise admin scopes and provides good clarity for API consumers.
jans-config-api/plugins/docs/jans-admin-ui-plugin-swagger.yaml (3)
551-591: Verify consistency between GET and PUT operations on/admin-ui/configendpoint.The GET operation at lines 553–555 now includes multiple scopes (
properties.readonly,properties.write), but the PUT operation at line 591 includes onlyproperties.write. Verify this scope coverage is intentional and aligns with the intended authorization model.
2094-2099: Verify all new admin scopes are fully defined in securitySchemes.New scopes (
role.admin,permission.admin,rolePermissionMapping.admin) are added at lines 2094–2099, but the scope definitions appear incomplete. Confirm that:
- All
.adminscopes referenced in endpoint security (e.g.,license.admin,read-all,write-all,delete-all) are declared in thesecuritySchemessection.- Each scope has a description (e.g., "Manage admin...").
- The scope URI format matches the new feature-wise admin scope standard referenced in the PR objectives.
If the full scope definitions are not shown in the provided excerpt, expand lines 2094–2150 to verify completeness.
54-61: Multiple scopes are referenced in endpoint security definitions but not declared in securitySchemes.The endpoint at lines 54–61 references scopes including
permission.readonlyandread-allthat are not defined in thesecuritySchemessection. This violates OpenAPI specification requirements. Additionally, 27 other scopes across the file are similarly undefined, including entire scope families likewebhook.*,properties.*, and allconfig/*scopes.Add the missing scope definitions to the
securitySchemessection (lines 2067–2099).⛔ Skipped due to learnings
Learnt from: pujavs Repo: JanssenProject/jans PR: 12704 File: jans-config-api/docs/jans-config-api-swagger.yaml:17540-17546 Timestamp: 2025-11-18T07:43:55.761Z Learning: The file `jans-config-api/docs/jans-config-api-swagger.yaml` is auto-generated with dependent modules changes and metadata. The config API does not override it.
| - health_check | ||
| - authz_detail | ||
| - update_token | ||
| - tx_token |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
rg -n 'txTokenScriptDns|fapi' --type java jans-config-api -A 2 -B 2Repository: JanssenProject/jans
Length of output: 45
🏁 Script executed:
sed -n '5200,5210p' jans-config-api/docs/jans-config-api-swagger.yamlRepository: JanssenProject/jans
Length of output: 426
🏁 Script executed:
sed -n '17330,17340p' jans-config-api/docs/jans-config-api-swagger.yamlRepository: JanssenProject/jans
Length of output: 307
🏁 Script executed:
rg -i 'fapi|txTokenScriptDns' --type-list | head -5Repository: JanssenProject/jans
Length of output: 452
🏁 Script executed:
rg -i 'txTokenScriptDns' -lRepository: JanssenProject/jans
Length of output: 570
🏁 Script executed:
rg -i 'fapi' -l | grep -v swagger | grep -v '.yaml'Repository: JanssenProject/jans
Length of output: 3086
🏁 Script executed:
rg -B 20 'txTokenScriptDns:' jans-config-api/docs/jans-config-api-swagger.yaml | grep -E '^\s+\w+:$|txTokenScriptDns' | tail -30Repository: JanssenProject/jans
Length of output: 321
🏁 Script executed:
rg -B 20 'fapi:' jans-config-api/docs/jans-config-api-swagger.yaml | grep -E '^\s+\w+:$|fapi:' | tail -20Repository: JanssenProject/jans
Length of output: 332
🏁 Script executed:
grep -n 'txTokenScriptDns' jans-auth-server/persistence-model/src/main/java/io/jans/as/persistence/model/ClientAttributes.java -A 2 -B 2Repository: JanssenProject/jans
Length of output: 1025
🏁 Script executed:
grep -n 'fapi\|txTokenScriptDns' jans-auth-server/model/src/main/java/io/jans/as/model/configuration/AppConfiguration.java -A 2 -B 2Repository: JanssenProject/jans
Length of output: 757
🏁 Script executed:
rg -B 50 'txTokenScriptDns:' jans-config-api/docs/jans-config-api-swagger.yaml | grep -E '^\s{2,4}[A-Z]\w+:$' | tail -5Repository: JanssenProject/jans
Length of output: 84
🏁 Script executed:
rg -B 50 'fapi:' jans-config-api/docs/jans-config-api-swagger.yaml | grep -E '^\s{2,4}[A-Z]\w+:$' | tail -5Repository: JanssenProject/jans
Length of output: 45
🏁 Script executed:
grep -n '@JsonProperty.*fapi' jans-auth-server/model/src/main/java/io/jans/as/model/configuration/AppConfiguration.java -B 1 -A 1Repository: JanssenProject/jans
Length of output: 45
🏁 Script executed:
rg -n 'fapi:' jans-config-api/docs/jans-config-api-swagger.yamlRepository: JanssenProject/jans
Length of output: 82
🏁 Script executed:
rg -n 'txTokenScriptDns:' jans-config-api/docs/jans-config-api-swagger.yamlRepository: JanssenProject/jans
Length of output: 94
🏁 Script executed:
sed -n '5180,5220p' jans-config-api/docs/jans-config-api-swagger.yaml | cat -nRepository: JanssenProject/jans
Length of output: 1791
🏁 Script executed:
sed -n '17320,17350p' jans-config-api/docs/jans-config-api-swagger.yaml | cat -nRepository: JanssenProject/jans
Length of output: 1006
🏁 Script executed:
sed -n '16600,16650p' jans-config-api/docs/jans-config-api-swagger.yaml | cat -nRepository: JanssenProject/jans
Length of output: 1796
🏁 Script executed:
rg -B 100 'txTokenScriptDns:' jans-config-api/docs/jans-config-api-swagger.yaml | grep -E '^\s{2}[A-Z][a-zA-Z]+:$' | tail -1Repository: JanssenProject/jans
Length of output: 45
🏁 Script executed:
rg -B 100 'fapi:' jans-config-api/docs/jans-config-api-swagger.yaml | grep -E '^\s{2}[A-Z][a-zA-Z]+:$' | tail -1Repository: JanssenProject/jans
Length of output: 45
🏁 Script executed:
grep -n 'fapiCompatibility' jans-auth-server/model/src/main/java/io/jans/as/model/configuration/AppConfiguration.java | head -5Repository: JanssenProject/jans
Length of output: 351
🏁 Script executed:
sed -n '786,792p' jans-auth-server/model/src/main/java/io/jans/as/model/configuration/AppConfiguration.javaRepository: JanssenProject/jans
Length of output: 462
🏁 Script executed:
sed -n '1,50p' jans-auth-server/model/src/main/java/io/jans/as/model/configuration/AppConfiguration.javaRepository: JanssenProject/jans
Length of output: 2199
🏁 Script executed:
rg '@JsonProperty|@JsonNaming|@JsonIgnoreProperties' jans-auth-server/model/src/main/java/io/jans/as/model/configuration/AppConfiguration.java | head -10Repository: JanssenProject/jans
Length of output: 106
🏁 Script executed:
rg -B 5 'txTokenScriptDns:' jans-config-api/docs/jans-config-api-swagger.yaml | head -20Repository: JanssenProject/jans
Length of output: 199
Fix field name mismatch for fapi in swagger schema.
txTokenScriptDns is correctly defined in the ClientAttributes Java model as a List with proper @JsonProperty annotation, matching the swagger definition.
However, the swagger schema defines a field named fapi (boolean) in the AppConfiguration schema, but the corresponding Java field is named fapiCompatibility, not fapi. Without an explicit @JsonProperty rename annotation, this creates a serialization mismatch. Either rename the swagger field to fapiCompatibility or add @JsonProperty("fapi") to the Java field to match the swagger definition.
Additionally, the review comment incorrectly references line 5204 (which contains an enum value tx_token, not a field definition) and claims fapi is added to the AuthenticationFilter schema when it actually belongs to AppConfiguration.
🤖 Prompt for AI Agents
In jans-config-api/docs/jans-config-api-swagger.yaml around line 5204 (note:
line 5204 contains enum value tx_token, not the AppConfiguration field), fix the
fapi field mismatch by either renaming the AppConfiguration property in the
swagger schema from "fapi" to "fapiCompatibility" OR add @JsonProperty("fapi")
to the Java field named fapiCompatibility so serialization names match; also
correct the review reference to point to the AppConfiguration schema (not
AuthenticationFilter) and remove the incorrect reference to line 5204 if you
update schema lines where AppConfiguration is defined.
| security: | ||
| - oauth2: | ||
| - https://jans.io/oauth/config/ssa.delete | ||
| - oauth2: | ||
| - https://jans.io/auth/ssa.admin | ||
| - oauth2: | ||
| - https://jans.io/oauth/config/ssa.write | ||
| - oauth2: | ||
| - https://jans.io/oauth/config/delete-all |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find files containing scope definitions, particularly for SSA and other admin scopes
fd -t f -e java . | xargs grep -l "ssa\.admin\|SSA.*ADMIN" | head -20Repository: JanssenProject/jans
Length of output: 1718
🏁 Script executed:
#!/bin/bash
# Search for scope constants in the codebase
rg -n "ssa\.admin|SSA.*ADMIN" --type java -A 2 | head -50Repository: JanssenProject/jans
Length of output: 8666
🏁 Script executed:
#!/bin/bash
# Look for ApiAccessConstants or similar scope definition files
fd -t f "ApiAccessConstants|ScopeConstants|AccessConstants" | head -10Repository: JanssenProject/jans
Length of output: 313
🏁 Script executed:
#!/bin/bash
# Read the ApiAccessConstants.java file to see scope constant definitions
cat -n jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java | grep -E "AUTH_SSA_ADMIN|ADMIN_ACCESS|OAUTH.*ADMIN" | head -40Repository: JanssenProject/jans
Length of output: 2670
🏁 Script executed:
#!/bin/bash
# Get the full file to understand the scope constant pattern
wc -l jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.javaRepository: JanssenProject/jans
Length of output: 150
🏁 Script executed:
#!/bin/bash
# Verify the full constant definition and surrounding context
sed -n '135,145p' jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.javaRepository: JanssenProject/jans
Length of output: 520
Namespace mismatch: ssa.admin scope should use /oauth/config/ namespace to match related SSA scopes.
Line 14293 uses https://jans.io/auth/ssa.admin, but related SSA scopes in the constants use /oauth/config/ namespace:
SSA_READ_ACCESS = "https://jans.io/oauth/config/ssa.readonly"SSA_WRITE_ACCESS = "https://jans.io/oauth/config/ssa.write"SSA_DELETE_ACCESS = "https://jans.io/oauth/config/ssa.delete"
Update AUTH_SSA_ADMIN constant in ApiAccessConstants.java from https://jans.io/auth/ssa.admin to https://jans.io/oauth/config/ssa.admin to maintain consistency within the SSA scope family and align with the standardized admin scope pattern.
🤖 Prompt for AI Agents
In jans-config-api/docs/jans-config-api-swagger.yaml around lines 14289-14297
there is a security scope using https://jans.io/auth/ssa.admin which mismatches
the SSA scopes namespace; update the AUTH_SSA_ADMIN constant in
ApiAccessConstants.java to use https://jans.io/oauth/config/ssa.admin (matching
SSA_READ_ACCESS, SSA_WRITE_ACCESS, SSA_DELETE_ACCESS) so the swagger entry and
constant are consistent; change the constant value only and run a quick
grep/search to ensure no other references still use the old /auth/ namespace.
| $ref: "#/components/schemas/AttributeValidation" | ||
| tooltip: | ||
| type: string | ||
| adminCanEdit: | ||
| type: boolean | ||
| userCanView: | ||
| selected: | ||
| type: boolean | ||
| adminCanView: | ||
| type: boolean | ||
| adminCanAccess: | ||
| adminCanEdit: | ||
| type: boolean | ||
| userCanView: | ||
| type: boolean | ||
| userCanAccess: | ||
| type: boolean | ||
| userCanEdit: | ||
| type: boolean | ||
| selected: | ||
| adminCanAccess: | ||
| type: boolean |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find Attribute model/POJO files
find jans-config-api -type f -name "*Attribute*.java" | head -20Repository: JanssenProject/jans
Length of output: 431
🏁 Script executed:
#!/bin/bash
# Search for the specific fields across java files in jans-config-api
rg -n '(adminCanEdit|userCanView|userCanEdit|adminCanAccess|selected)' --type java jans-config-api --max-count 50Repository: JanssenProject/jans
Length of output: 3163
🏁 Script executed:
#!/bin/bash
# Look for class definitions in Attribute-related files
fd "Attribute\.java" jans-config-api --type f --exec wc -l {} \;Repository: JanssenProject/jans
Length of output: 45
🏁 Script executed:
#!/bin/bash
# Search in the entire jans repository for Attribute class definition
find . -path ./node_modules -prune -o -type f -name "*.java" -print | xargs rg -l "class Attribute " | grep -v test | head -20Repository: JanssenProject/jans
Length of output: 133
🏁 Script executed:
#!/bin/bash
# Look for Attribute model in core modules
find jans-core -type f -name "*Attribute*.java" 2>/dev/null | head -20Repository: JanssenProject/jans
Length of output: 1126
🏁 Script executed:
#!/bin/bash
# Search for the specific new fields in Attribute context
rg -B 5 -A 5 "private.*adminCanEdit|private.*userCanView|private.*userCanEdit|private.*adminCanAccess" --type java --max-count 30Repository: JanssenProject/jans
Length of output: 45
🏁 Script executed:
#!/bin/bash
# Check ConversionAttributes file content
cat jans-config-api/common/src/main/java/io/jans/configapi/model/configuration/ConversionAttributes.javaRepository: JanssenProject/jans
Length of output: 1264
🏁 Script executed:
#!/bin/bash
# Read the actual Attribute model file
cat jans-core/model/src/main/java/io/jans/model/attribute/Attribute.javaRepository: JanssenProject/jans
Length of output: 9036
Remove unsupported fields or update Attribute model to match schema changes.
The Attribute schema includes five new boolean fields (selected, adminCanEdit, userCanView, userCanEdit, adminCanAccess) that do not exist in the source model at jans-core/model/src/main/java/io/jans/model/attribute/Attribute.java. The model currently uses editType and viewType (UserRole arrays) for permissions, not individual boolean flags. Either remove these fields from the schema or add them to the Attribute model with appropriate getters, setters, and @AttributeName annotations.
🤖 Prompt for AI Agents
In jans-config-api/docs/jans-config-api-swagger.yaml around lines 15691–15707
the Attribute schema declares new boolean fields (selected, adminCanEdit,
userCanView, userCanEdit, adminCanAccess) that are not present in the Java
model; either remove these fields from the YAML or add matching fields to the
Java model at
jans-core/model/src/main/java/io/jans/model/attribute/Attribute.java — to add:
declare private Boolean fields for each new property, add standard public
getters/setters, annotate each field with the appropriate
@AttributeName("propertyName") matching LDAP/storage names, update
equals/hashCode/toString if applicable and any serialization mappings, and run
build/tests; to remove: delete the five boolean property entries from the schema
(and regenerate swagger artifacts) so schema and model remain consistent.
| @OAuthScope(name = ApiAccessConstants.AUTH_SSA_ADMIN, description = "Admin for SSA management"), | ||
| @OAuthScope(name = ApiAccessConstants.HEALTH_ADMIN, description = "Admin for Health API management"), |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for the constant definitions in ApiAccessConstants
rg -n "AUTH_SSA_ADMIN\s*=|HEALTH_ADMIN\s*=" --type=java -B2 -A2Repository: JanssenProject/jans
Length of output: 769
🏁 Script executed:
# Also search for where these constants might be defined (they could be in a different file)
fd -e java | xargs rg -l "AUTH_SSA_ADMIN|HEALTH_ADMIN"Repository: JanssenProject/jans
Length of output: 406
🏁 Script executed:
# Let's examine the full snippet to count the actual naming patterns
cat -n jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java | sed -n '126,149p'Repository: JanssenProject/jans
Length of output: 3051
🏁 Script executed:
# Check usages of AUTH_SSA_ADMIN and HEALTH_ADMIN in resource classes and other places
rg "AUTH_SSA_ADMIN|HEALTH_ADMIN" --type=java -B2 -A2Repository: JanssenProject/jans
Length of output: 6697
🏁 Script executed:
# Also verify the actual constant values to understand the scope URLs better
rg -A1 "public static final String.*ADMIN.*=" jans-config-api/common/src/main/java/io/jans/configapi/util/ApiAccessConstants.java | head -60Repository: JanssenProject/jans
Length of output: 2457
*AUTH_SSA_ADMIN and HEALTH_ADMIN deviate from the established _ADMIN_ACCESS naming convention.
Lines 148-149 introduce two admin scope constants that break the naming pattern used consistently across 22+ other admin scopes in the same file. All other admin scopes follow the *_ADMIN_ACCESS naming convention (e.g., ATTRIBUTES_ADMIN_ACCESS, SCRIPTS_ADMIN_ACCESS, CACHE_ADMIN_ACCESS), but these two omit the _ACCESS suffix:
AUTH_SSA_ADMIN(line 148) — used in SsaResource.java and ApiApplication.javaHEALTH_ADMIN(line 149) — used in ApiHealthCheck.java (3 times) and ApiApplication.java
Consider renaming to AUTH_SSA_ADMIN_ACCESS and HEALTH_ADMIN_ACCESS for consistency with the established convention. This would require updates in ApiAccessConstants.java, ApiApplication.java, SsaResource.java, and ApiHealthCheck.java.
🤖 Prompt for AI Agents
In
jans-config-api/server/src/main/java/io/jans/configapi/rest/ApiApplication.java
around lines 148-149, two OAuth scope constants use inconsistent names
(AUTH_SSA_ADMIN and HEALTH_ADMIN) that deviate from the project's *_ADMIN_ACCESS
convention; rename them to AUTH_SSA_ADMIN_ACCESS and HEALTH_ADMIN_ACCESS in
ApiAccessConstants.java and update every reference (ApiApplication.java,
SsaResource.java, ApiHealthCheck.java) to use the new names, ensuring imports
and any string literals or annotations are updated accordingly and run a
build/tests to verify no remaining references to the old names.
|
Prepare
Description
Defined new admin level scopes for each feature that will be as required #12487 https://jans.io/oauth/config/acrs.admin
Target issue
closes 11633
Implementation Details
Test and Document the changes
Please check the below before submitting your PR. The PR will not be merged if there are no commits that start with
docs:to indicate documentation changes or if the below checklist is not selected.Summary by CodeRabbit
New Features
Security Improvements
Documentation
Tests
✏️ Tip: You can customize this high-level summary in your review settings.