How to list/select users without having userManagementAdmin role

UAA
, , ,
1

Hi,

I already addressed this issue/question as a side note in thread model-relationships-to-domainusermanagement/2782, but here it’s correctly identified as a UAA subject.

Currently, I am still working only with the SME and the Preview App. I have a Project model that should have relationships to users as Project Owner, Assignee, and Executor. After downloading the DomainUserManagement document model from the UAA documentation and creating the relationships, everything seemed to work. However, only users with the userManagementAdmin role can list and select all users. All other users can only see and select themselves.

Please notice that I added a new role User_Reader to DomainUserManagement and that all my users have this role. The role User_Reader has access rights MODEL_READ, DOCUMENT_READ, and DOCUMENT_LIST. So there is no problem for downloading the document model.

Nevertheless, it seems that the userManagementAdmin role is not only necessary for managing users but also for retrieving them. UAA appears to restrict access to its API using the user-management-authorization.json policy file like that:

{
  "name": "User Document Reading Policy",
  "description": "The user document belongs to the currently logged-in user",
  "target": "true",
  "rules": [
    "containsAnyRole('userManagementAdmin') || #resource == principal.username"
  ]
}

I believe this explains the behavior well: only users with the userManagementAdmin role can read all users (including “technical” users). Other users can only see themselves.

To address this for my use case, I may need to customize the configuration file user-management-authorization.json or introduce a new configuration file to allow users with the User_Reader role to retrieve all or certain users.

Is this the right approach?

Why hasn’t this use case been addressed until now? It actually seems quite typical, doesn’t it?

2

Hi,
With your case, you are right about customizing the policies in authorization definition file to play around the role User_Reader (actually this approach have been using in some projects already).

However, the policy you pointed out is not enough. The one User Document Reading Policy currently is only used on the scope Read User Document Spec which is used to authorize the rest api /loadUserDocument/{userDocumentId}. That api is kind of utility endpoint provided by UM (User Management) and not used for UI loading. In fact, the rpc api is the one you need to make the impact on. The UI will load documents by using rpc api which is bound to the scope Query, so what you need is making the adjustment on the scope Query and related policies.

{
    "name": "User Document Read Permissions",
    "description": "",
    "repository-refs": [
      "User Document Username Filter Policy",
      "User Document Tenant Filter Policy",
      "Role Document Tenant Filter Policy",
      "AccessRight Document Tenant Filter Policy"
    ],
    "scopes": [
      "Query"
    ]
}

Having a look at the scope Query in authorization file, you can see it contains 4 repository-refs and those will be used by Dataservices to do the query filter. One of the repository-policy, for example, User Document Username Filter Policy

{
      "name": "User Document Username Filter Policy",
      "description": "User without userManagementAdmin role should not see other user information",
      "target": "#resource == 'DomainUserManagement' && !containsAnyRole('userManagementAdmin')",
      "templates": [
        {
          "operator": "exact_match",
          "field": "/user/username",
          "value": "principal.username",
          "caseSensitive": false
        }
      ]
 }

It is triggered only the current Document Model is DomainUserManagement and current logged-in user is not assigned to the role userManagementAdmin. If the target condition is fullfiled, Dataservices would append all the constrains including in the templates into the query. In this case, the query is going to return the documents belong to the current logged-in user (/user/username == principal.username). If there is any concern about UAA authorization mechanism, please check out the UAA documents for more information or you can approach me via webex.

And to customize authorization file, typically with UM, the only way to achieve is creating the new authorization file by your own (should clone from existing one of UM and adjust specific entities) and specify the path in the property mgmtp.a12.uaa.authorization.child-authorization-definitions.

Hope this would help you.

3

Hi @anh-fresh-forge,

Thank you for your response. I haven’t tried it yet, as I’m still working only with SME and the Preview App, but it sounds promising.

With the upgrade to release 2025.06, no users are now listed in the drop-down menu - not even the current user. What has changed? Does it have to do with the “Query” scope which now replaces the “Document List” scope?

Before in 2024.06 I defined a user with role userManagementAdmin, which surprisingly could not logged in. Now with 2025.06 this user can log in, but still cannot list any users. This does not seem to me to be in line with the configuration we discussed.

Regards,
Foued

4

I also found in A12 Tools - 2025.06\bin\preview-app-server\202506.0.0\previewapp-server-202506.0.0\BOOT-INF\classes\config\application-pa_uaa.properties the following entry:

# Authorization
mgmtp.a12.uaa.authorization.child-authorization-definitions=classpath:/uaa/workflowsAuthorizationDefinition.json

The content of the JSON file is only about workflows and I didn’t find anywhere else neither in the Preview-App nor in the JARs a different authorization definition. Does that mean that the Preview App in A12 release 2025.06 does not have any “User Management Permission Definition”? Is that because the User Management App is now standalone and/or the Preview-App in 2025.06 is missing uaa-user-management-service-9.0.1-plain.jar and uaa-user-management-user-9.0.1.jar which are necessary for retrieving user data?
I looks like it doesn’t help to define my own authorization file to be able to retrieve users in the Preview App because some Beans are missing.

Thanks for your help!

Foued

5

Thanks to the support of @anh-fresh-forge I was able to better understand the difference between local users from users.yaml in the preview-app which are kept in memory and therefore cannot be listed from UAA and “real” users which can be added manually in the form or on start of the preview-app by defining approporiate documents. See data folder explained in SME > Workspace Explorer.

Because in release 2025.06 the User management app is now standalone and no more integrated on the preview-app (see Preview App > Roles and Users) there is no possibility to work (assign, edit etc.) with users defined with UAA user model DomainUserManagement :slightly_frowning_face:.

In order to solve that and restore previous behavior known in release 2024.06 I had to:

  1. Add removed libs uaa-user-management-service-9.0.1-plain.jar and uaa-user-management-user-9.0.1.jar into previewapp-server-202506.0.0.jar.
  2. Updating workspace.json to include a separate properties file
{
  "environmentVariables": {
    "preview-app": {
      "SPRING_CONFIG_ADDITIONAL_LOCATION": "<your-path>\\application-local.properties"
    }
  }
}
  1. Defining the authorization definitions in the new config properties:
mgmtp.a12.uaa.authorization.child-authorization-definitions=<your-path>/user-management-authorization-local.json

mgmtp.a12.uaa.authorization.authorizationDefinition=<your-path>/authorizationDefinition.json

because those two files are also missing in the previewapp-server-202506.0.0.jar.
4. Update the user-management-authorization-local.json so that it swits to my needs.

That worked good so far enabling me to model in the SME with “real” UAA users of model DomainUserManagement and test that in the preview-app.

6

Unfortunately, it is not possible to use users from the users.yaml file directly for modeling. This means that the documents of a modeled employee Document Model and the users with whom you can log in to the preview app are different data. If a connection between the data is required, the Project Template should be used.