Different behaviour wrt Anonymous settings between UI and Rest API

[brenuart]

When configuring anonymous settings, the UI presents a list of realms to choose from, fetched via the /rest/internal/ui/realms/type endpoint. This list appears to include all realms capable of authorization. For example, in our case, the endpoint returned the following:

[
  {
    "id": "Crowd",
    "name": "Crowd Realm"
  },
  {
    "id": "LdapRealm",
    "name": "LDAP Realm"
  },
  {
    "id": "NexusAuthorizingRealm",
    "name": "Local Authorizing Realm"
  },
  {
    "id": "SamlRealm",
    "name": "SAML Realm"
  }
]

When saving the settings, the UI commits the changes by posting to the /rest/internal/ui/anonymous-settings endpoint. In our case, it allowed selecting the "Crowd" or "SamlRealm" realms even though they were not explicitly configured as active.

To replicate this configuration using the standard REST API, I tried making a PUT request to the /rest/v1/security/anonymous endpoint with the following payload:

{
    "enabled": true,
    "userId": "anonymous",
    "realmName": "Crowd"
}

However, the request was rejected with the error message:

400 Bad Request: "[ {
  "id": "realmName",
  "message": "Realm does not exist"
} ]"

Further investigation revealed that the REST API only accepts realm names that are considered "active" according to the /rest/v1/security/realms/active endpoint. Since the "Crowd" realm was not activated, the request failed. Conversely, we could use an active realm like "NpmToken" for the realmName in the request, even though it is not an authorizing realm. The request was accepted, but the UI did not display the value correctly and seems to have selected the first item in its list by default.

In summary:

• The UI endpoints accept any "authorizing" realms.
• The standard REST API only accepts "active" realms, regardless of whether they are authorizing.

This behavior appears inconsistent. Could someone clarify if there is a reason for this difference?

[mrprescott]

@brenuart Thanks for posting this; clearly it's a bit odd that the validation is more restrictive in one case vs. the other. My guess is it's nothing more meaningful than an inadvertent consequence of violating DRY in the REST end point design. Is there any impact to you? Setting anonymous on or off for inactive realms doesn't really do anything, it seems a harmless difference that we'll lock down when we eventually harmonize the two REST endpoints. Let me know you thoughts.