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

API/CLI
, ,
1

Hello!

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:
{“sourceRoleName”:null,“sourceRoleFqn”:“up.testpy”,“mappedRole”:{“id”:108,“name”:“umg/up.testpy”,“authority”:“umg/up.testpy”}}

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?

2

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.

1 Like
3

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.

Thanks!

4

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.