16 June 2025
Production release: 16 June 2025
Staging release: 09 May 2025
16 June 2025
Section titled “16 June 2025”Features
Section titled “Features”-
API Development for Public Organization Search: The first version of the Public Organization Search API is complete, featuring POST: organizations/search and POST: accounts/{account_id}/isPartnerFor endpoints.
POST /organizations/searchPOST /accounts/{accountId}/isPartnerFor
Refer: IAM Documentation page
-
Introduced a new API endpoint designed to streamline the process of removing roles from accounts or groups. This endpoint utilizes a DELETE method at applications/{applicationId}/roles/{roleId}. To execute this operation, users must provide a query parameter that specifies either the account TRN ID or the group TRN ID, ensuring precise identification of the target for role removal.
-
A new GET endpoint has been introduced to facilitate the retrieval of roles associated with applications, accounts, or groups, accessible via /applications/{uuid}/roles. Users can specify either the account TRN ID or the group TRN ID as a query parameter to accurately fetch the relevant role information.
-
Implemented a GET endpoint to enable the retrieval of roles associated with groups and other entities. This endpoint, located at /groups/{uuid}/roles, requires a query parameter specifying either the account TRN ID or the application TRN ID to ensure precise role data acquisition.
-
Accounts/search endpoint of IAM can be accessed only by applications with accounts-searcher role and is also restricted totally for users.
-
Accounts and their associated addresses are live ingested into OpenSearch in IAM to enable the integrating systems to search the accounts based on their country and other address related attributes. The updates and deletes associated with the accounts and their addresses are also handled as part of the live ingestions.
-
In addition to the existing functionality of searching the accounts and their organizations based on the Geo Location, an enhanced feature to search the accounts and organizations based on only country field has been introduced.
Enhancements
Section titled “Enhancements”-
The relation names ‘HAS_ACCESS_TO’ and ‘ACCESSIBLE_BY’ have been converted to lowercase to adhere to common standards.
-
New device models have been integrated into the IAM system within the live sync Lambda environment.
-
The POST, GET, and DELETE endpoints at /roles/{roleId}/users have been decommissioned, and a common pattern has been established with the development of an alternative endpoint, /users/{userId}/roles, to manage roles for a user.
-
The application name has been removed from the permissions and roles in the BLU system as part of the latest update.
-
To maintain parity in CDH, enforced a limitation that disallows the removal of the final reference in external systems.
Bugfix
Section titled “Bugfix”-
500 Error when updating references: The issue that caused a 500 Internal Server Error when updating existing references on an account/address has been resolved. Requests should now succeed, and the refId will be updated accordingly.
-
Account is missing in calling subject on org creation: When creating an organization, if the token lacks account details, it incorrectly associates the organization with ‘none’. This has been updated to throw an error, notifying the caller that account details are required to establish the relation.
-
Get permission of an application over a group: Fetching application permissions for a group with assigned roles previously resulted in a 404 error. The expected behavior is now implemented, where the response will display the application’s permissions assigned to the group based on the role.
-
On-behalf token returns 502: The issue of 502 errors occurring when using an onbehalf token has been fixed, and authorization processes have been thoroughly tested.
-
Relation creation in db: The /groups/{groupId}/roles/{roleId}?on=
endpoint was incorrectly setting ‘forward’ relations as ‘reverse’ and ‘reverse’ as ‘None’ in the database. -
Fetch account despite failed user status: Users with a failed status in an account are now restricted from performing any actions on that account.
-
Exception message handled on pageSize: The exception handling for pageSize has been improved. Previously, a pageSize of zero or less resulted in a 500 Internal Server Error. It will now return a 400 error with a proper validation message.
-
Handling Non-Existent Account Errors for “Account-Provisioner” Role in API Requests: When using an application token with the “account-provisioner” role to access the above APIs, a 500 Internal Server Error was previously thrown if the specified account did not exist. This has been corrected to return a 404 error, indicating that the account does not exist.
-
500 internal server error while creating a user with null payload: Attempting to create a user with a null payload in the Invitation workflow previously resulted in a 500 Internal Server Error. This issue has been resolved by implementing a validation error message.
-
Unique Constraint Errors should return 409 instead of 400: The error response for conflicting external systems was previously returning a 400 Bad Request status, whereas a 409 Conflict status is more appropriate. The error message itself is correct, but the status code and status field should be updated to 409 CONFLICT.