Hitting an issue while attempting to use the /api/user-sources/#" end point


I’m hitting an issue trying to figure role mappings via the API. This similar to Creating identity source role mappings via REST API

I did get the “roleMappingNames” object to work before, but with that being marked Deprecated I wanted to use another option that is still supported.

I’m attempting to use the UserSourceCreationObject" that says it will add/update the specified role mapping(s) without removing undefined settings, as I just literally need to add the SAML group value to the Role ID.

First thing I noticed was what I think is an error in the API docs (?) as the UserSourceCreation Object is listed as a “string” for the newKey and New Value entries, but sending two strings is returning the following in the Morpheus logs:

For input string: “umg/up.testpy”. Stacktrace follows:
'java.lang.NumberFormatException: For input string: “umg/up.testpy”

I changed the value for the newKey to the integer value for the Role, but that fixes the 500 threw a gasket but doesn’t seem to actually do anything.

My JSON is:

payload = {
            "userSource": {
              "defaultAccountRole": {
                "id": identity_source['defaultAccountRole']['id']
              "name": identity_source['name'],
              "type": identity_source['type'],
              "roleMappings": {
                roleId: "up.testpy"

where roleId is the value of the role, and the ID, Name, and Type fields are populated with what’s read in from a prior identity sources call, in this case:
defaultAccountRole ID: 14
name: -redacted-
type: azureSaml

I get back a 200, but I see the follow in the return JSON and the field in the Identity Source isn’t filled out as expected:

Per the API docs, the “UserSourceCreationObject” doesn’t need the a sourceRoleName, vs the “UserSourceCreationMap” that does have the sourceRoleName input.
I can use the UserSourceCreationMap instead, but this method requires reading in all existing objects, appending the new entries and sending back, and I was looking to use what seemed like the easier approach.

Can someone help me in figuring out what I’m missing?

It’s not really deprecated. The OpenAPI spec however did not have a better option to denote 2 different schema for the same exact endpoint. Both are 100% valid routes. I would have to investigate further why this is failing, but the other is not being decommissioned.

Thanks for the feedback! I had noticed the deprecated tag went back a ways so I wasn’t sure about using it, but if it’s not really deprecated I can use that and just simplify things that way.


Sorry about the confusion! I’m the one that wrote that a while back. I’ll see if there are some better options now to denote that better.