SAC - User Provisioning API - User ID issue

[harald_zarakowitis]

Dear experts,

I hope you can help with this problem. I want to create SAC users over the API automatically. Everything is setup correctly and I can create test users but I have one open issue now:

- Creating a users manually in SAC lets you choose a user name that is different from its E-mail.

- However we are using SAML login via e-mail adress and the API documentation tells me this: /Users

Note
You must provide userName, name, and email information.
If you are using SAML authentication, userName should be set to the property you are using for your SAML mapping. For example, the user's USER ID, EMAIL, or CUSTOM SAML MAPPING. If your SAML mapping is set to EMAIL, the email address you add to userName must match the email address you use for email.

- I provided the e-mail as "userName" and wanted to add "id" to forward the User ID from our company. I used "id" because if you do a GET request on an existing user, you get this attribute returned which has the User ID (=Windows AD).

- However it seems that the POST request ignores the provided "id" and creates a user name based on the provided E-Mail in "userName". In my case that would be "HARALDZARAKOWITIS", because "." or "-" are ignored. The worst thing is that the location to the user object is also now "/api/v1/scim/Users/HARALDZARAKOWITIS", so it is very hard to retrieve information again, because the automatic creation from the user name is not consistent (very long names are cut off and _01 is added).

Any ideas how to work around this problem are appreciated.

Best regards,
Harald

[mfoeken]

Hi Harald,

Using dynamic user creation works in the same way. We don't care about the actual username created. Is there a specific reason why this is of interest if all is associated with the email adress?

Kind regards,

Martijn van Foeken | Interdobs

[harald_zarakowitis]

Hi Martijn,

as far as I have seen the <id> is the string how I can access a user objects again after the creation ("/api/v1/scim/Users/HARALDZARAKOWITIS"). I also need the <id> to add users to a team but the creation of the <id> is not stable.

I just tested this again: I create a user with a long name: FIRSTNAME_LASTNAME_LASTNAME@company.com
Username and E-Mail is OK.

The <id> however is changed to: FIRSTNAME_LASTNAM_1
And the path is: "/api/v1/scim/Users/FISTNAME_LASTNAM_1"

Best regards,
Harald

[harald_zarakowitis · Accepted solution]

Hi Christian,

I tried that, but since we have SAML configured based on E-Mail I get this error if the Username and E-Mail don´t match during creation:

{"status":400,"message":"User/group operation not completed: Invalid SAML IdP Configuration"}'

I worked now around this issue by first sending <USERNAME@company.com< for both username and E-Mail. The API will write USERNAME into the field Username.

Afterwards I make an update and change the E-Mail adress to <first_name.last_name@company.com>

Best regards,

Harald

[Matthew_Shaw]

Thanks Harald

Thanks so much for this. I didn't think of your point 3:

3. I want the username to be our login ID, because the path is cut off (_1), if the username is to long, so I wouldn´t be able to get the correct path again to identify a user object.

I see what you're doing and that makes sense to me. You're having to create the user (POST) with userName and email to be the same value, but because the email (and userName) is too long, SAC will change the userName to be shorter and _1 added to the end. The userid has the same value as userName.

So you're creating the user (POST) with userName and email to be wrong 'email' values, but the right userName (they both need to be the same at time of creation, but doing so means the userid is what you want it to be), then updating the email after creation and updating the email is allowed unlike updating the userName.

You can perform a search of user based upon their email, but the search will be slower than a GET, but I think your solution is better because the username is predicable and known.

So I think the error:

{"status":400,"message":"User/group operation not completed: Invalid SAML IdP Configuration"}'

is simple because the email doesn't match the userName and because you have SAML SSO setup matching on email.

For your workflow there's a few gotcha's when you do a GET/PUT of the user to update the email. Any default roles are added after user creation, but they will be there by the time you perform a GET and so don't include logic in your code to look at the role and accidentality remove a default role because your logic says it shouldn't be there. There's also a gotcha when the session times-out (or you get a 500 and simply you need to re-submit) and you'll then get a 409, but all you need to do is read the user and optionally update the users' email (because the session may have timed-out between the POST and the PUT)

If its aright with you, I might have to incorporate your logic into one of my sample scripts as I think other customer will want to benefit from this. (Sample scripts are to be made available soon)

All the best, Matthew

[dvankempen]

For the interested reader, we have started to record a video tutorial series about the SAP Analytics Cloud user and team provisioning API

• https://blogs.sap.com/2021/09/25/sap-analytics-cloud-user-and-team-provisioning-api-hands-on-video-t...

[Matthew_Shaw]

Hi Harold

My sample scripts are now available via https://blogs.sap.com/2021/05/28/sap-analytics-cloud-scim-api-best-practices-and-sample-scripts/

Your issue is resolved with sample scripts 13x and the transport scripts 933 and 983.

I've also covered this workflow in my best practices article that explains a few gotcha's !

Hope this helps you and many other customers,

Matthew

[Matthew_Shaw]

Hello Harald

Perhaps if or when you have time, you could test a sample script that I've created that includes this workflow of yours. There's 3 samples that I've added, and they have numbers 131, 132 and 133. Once my initial set of sample scripts are published (coming soon!) then once these new ones are validated I can add them to the set for everyone else be benefit.

I'll follow you and I think if you follow me, we can chat directly via the message service provided.

Many thanks, Matthew

[Matthew_Shaw]

Hello Harald

I think you'll get the error

{"status":400,"message":"User/group operation not completed: Invalid SAML IdP Configuration"}'

when you have another user (identified by a different userid) using the same email.

The '_1' will be added to the userName if the (userid AND email) doesn't match the existing user with userid and email, i.e. you're POSTing with a different email than the existing user matching on userid.

You can test for the '_1' userName in the responseBody of the POST, just read userName and test if it matches the userName of your POST. (you can then go on to delete this user and update the 'right' users' email, rather than create another user)

You need to be a little careful though when re-POSTING and you're changing the email as there's a gotcha when your session expires mid-operation. In the coming weeks I'll be posting a load of best practice on this topic... so follow me for a full solution! 😉

All the best, Matthew

[harald_zarakowitis]

Thanks, I´m looking forward to your posts.

In my tests I didn´t see what you described. There couldn´t be another user with the same mail, because I used values for a test user, that didn´t exist.

1. The API doesn´t allow different values for username and E-Mail during creation (HARALD@COMPANY.COM) because of SAML.
2. The path to the object will always be the username before the @. ("/api/v1/scim/Users/HARALD")
3. I want the username to be our login ID, because the path is cut off (_1), if the username is to long, so I wouldn´t be able to get the correct path again to identify a user object.

So far everything works with my workaround, where I first create the user with POST by using USERNAME@company.com and then updating with PUT with the real e-Mail: firstname.lastname@company.com.

I can now sync BW roles with SAC and create the users if necessary automatically.

Best regards,
Harald

[former_member47640]

Based on the documentation this seems to work as designed.

If you want to use the Windows AD user ID, then I suggest to create the "userName" attribute using that ID. Don't use the email address for the "userName" field. Only provide the email address in the email address field.

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
    ]
    "userName":"<Windows AD User ID>",
    "name":
    {
        "givenName":"<User_Given_Name>",
        "familyName":"<User_Family_Name>"
    },
    "displayName":"<User_Display_Name>",
    "emails":[  
        {  
            "value":"<user@email.com>",
            "type":"work",
            "primary":true
        }
    ],
    "roles":[],
    "groups":[],
    "urn:scim:schemas:extension:enterprise:1.0": {
        "manager": {
            "managerId": ""
        }
    }
}