OpenID User Provisioning

Hi Arie,

This one is planned for the 2022.2 release in June. Support for the Microsoft ‘common' tenant will be available in a few weeks. 

Great stuff, we plan on using it pretty soon!

@Jasper Out of curiosity: are you planning to register Thinkwise as a Gallery app at Azure AD? Might make it even simpler for your customers to setup SSO and User Provisioning.

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/v2-howto-app-gallery-listing 

We got it up and running today very easily. In addition to the Docs, we had to add the following Claims to IAM manually for setting up Azure AD User Provisioning:

• given_name → to map to First name in the IAM User Template
• family_name → to map to Surname in the IAM User Template
• groups → to map to User Group in the IAM User Group Template
  • Note that a Cloud-based Azure AD Group (not inherited from a local AD) only provides the Group ID, not a sAMAccountName

On the Azure AD side we simply had to go the already existing App registration > Token configuration > Add groups claim

After recycling Indicium it worked as expected!

Hi Arie,

I would very much like to do that, but I don't expect we'll get around to that anytime soon unfortunately.

@Vincent Doppenberg We have recently enabled User Provisioning in our Production environment. We see a couple of things I would like to check with you:

1. For every existing User, we now always see two login attempts, 1 failed and 1 successful with the same Timestamp. Why is this and how can this be resolved?

The failed one has the following entry in the Log field:

The user 'xxx' will be updated.
The gender is no longer up-to-date. The gender will be updated to '0'.
Updating the gender failed with error message:
<msg id="not_authorized_usr_admin"></msg>

The successful one has the following entry in the Log field:

The user 'xxx' will be updated.
The gender is no longer up-to-date. The gender will be updated to '0'.
Updating the gender failed with error message:
<msg id="not_authorized_usr_admin"></msg>
Note: This will not prevent further processing.
The following user groups will be assigned: BRIDGE Base.
Other existing provisioned user group assignments will be revoked.
The user is up-to-date.

2. Should the Pool User have usr_admin rights in assigned in IAM in order to update Users? By the way, for the User data I tend to prefer that it is not updated based on the Provisioning template.
    
3. Like Gender there are some more User data field we would like to set in IAM, are known in Azure AD, but are not provided with Azure AD User provisioning (f.e. CompanyName / Department / employeeID / Phone nr). These fields seem not to be available as Claims. We are considering using a separate MS Graph API call to retrieve that data. Could you think of other solutions to retrieve additional User data from the Open ID provider (Azure AD) into IAM? 

Hi Arie,

These valuable additions are now documented in topics:

• Manually update mappable claims
• Add and map claims for Azure AD user provisioning.

Hello Arie,
 

1. For every existing User, we now always see two login attempts, 1 failed and 1 successful with the same Timestamp. Why is this and how can this be resolved?

2. Should the Pool User have usr_admin rights in assigned in IAM in order to update Users?

I think that these two points share the same underlying issue. There has been a small misunderstanding between IAM and Indicium which we did not catch ourselves because in our test environment, the pool user does have usr_admin rights in IAM. With that said, I would not recommend this configuration for you. The ideal scenario is that the pool user does not exist as a user in IAM. I will make sure that this issue is resolved in the upcoming 2022.2.15 release of Indicium.

By the way, for the User data I tend to prefer that it is not updated based on the Provisioning template.

Can you elaborate on this? Do you mean that you would like this user data to be provisioned when the user does not exist but not be updated when the user does exist? If so, then I would recommend creating an Idea for this. More granular control over what is and is not updated would have to be added as a new platform feature.

3. Like Gender there are some more User data field we would like to set in IAM, are known in Azure AD, but are not provided with Azure AD User provisioning (f.e. CompanyName / Department / employeeID / Phone nr). These fields seem not to be available as Claims. We are considering using a separate MS Graph API call to retrieve that data. Could you think of other solutions to retrieve additional User data from the Open ID provider (Azure AD) into IAM? 

You can set extension attributes which can be emitted as optional claims, but this does not seem to be a very useful solution. It looks like these extension attributes need to be set for every user. Sadly, there doesn’t seem to be a great way to achieve this. Calling the Graph API yourself might be your best bet.

I hope this helps.

I will make sure that this issue is resolved in the upcoming 2022.2.15 release of Indicium.

@Vincent Doppenberg Does this mean the Pool user will be able to update the user table from 2022.2.15 release onwards?

By the way, for the User data I tend to prefer that it is not updated based on the Provisioning template.

Can you elaborate on this? 

Well, let's take Gender as example here. I can add a Default value in the User template (f.e. Unknown). But for most of the Users I know their Gender, so we have set this previously or could update this manually on Users that exist in the IAM database. If the User provisioning would then update it back to Unknown the next time they login, that'd be unwanted. But how would the logic deal with this if we would set the Gender in the User Provisioning - User template to null? It is a mandatory field on the usr_general table. Will it use the Default set on that table if mapped as null in the User template and would it leave the Gender be for existing Users? That would suffice at this stage I suppose.

You can set extension attributes which can be emitted as optional claims, but this does not seem to be a very useful solution.

I suppose you're talking about this feature? https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-schema-extensions

It does sound as if it might work to add some additional fields, but then the possibility to map these values in the User template in IAM is missing. So in order to map f.e. CompanyName / Phone no / Employee ID, changes in IAM User Template functionality would be needed too.

Hello Arie,

Does this mean the Pool user will be able to update the user table from 2022.2.15 release onwards?

Yes.

Well, let's take Gender as example here. I can add a Default value in the User template (f.e. Unknown). But for most of the Users I know their Gender, so we have set this previously or could update this manually on Users that exist in the IAM database. If the User provisioning would then update it back to Unknown the next time they login, that'd be unwanted. But how would the logic deal with this if we would set the Gender in the User Provisioning - User template to null? It is a mandatory field on the usr_general table. Will it use the Default set on that table if mapped as null in the User template and would it leave the Gender be for existing Users? That would suffice at this stage I suppose.

I understand what you mean. From a quick glance at the stored procedure that is called, it appears to me that it disregards any current value of the gender column in usr_general and updates the gender according to this priority:

• The claim value returned by the Identity Provider (if mapped)
• The default, static value from the user template (if set)
• 0 (which I believe is Unknown)

So yes, if the claim is not mapped or the Identity Provider does not return it, it will always be updated to Unknown, even if you don't have a default value in the user template. I see how this can be an issue.

@Anne BuitCan you have a look at this?

I suppose you're talking about this feature? https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-schema-extensions

It does sound as if it might work to add some additional fields, but then the possibility to map these values in the User template in IAM is missing. So in order to map f.e. CompanyName / Phone no / Employee ID, changes in IAM User Template functionality would be needed too.

Yes, I'm talking about that feature. I have never tried it myself, but at face value it seemed very cumbersome to use, but perhaps it’s not that bad. For fields like Company name and and Employee identifier, you are correct, changes to IAM would be required and I would recommend creating an Idea for this. The Phone number field, however, is included in the template. So if you can get Azure AD to emit a phone number claim, then you can simply add this claim manually (assuming it cannot be discovered through the task that parses the metadata) and map it in the template.

I hope this helps.

There is currently indeed no way to prevent certain user fields from being updated in the same manner as they would be set when the user would be provisioned.

The following fields will always be updated:

• Tenant
• User id
• Email
• First name
• Surname
• Phone number
• Gender
• User groups (provisioned ones)

There are some exceptions for fields that have functional impact in the application - they will be provisioned once but they will not be automatically updated.

• Time zone
• Application language

Furthermore, the default allowed user preferences settings will be applied but will not b updated.

While a default value for mandatory fields will be necessary for provisioning, having the ability to explicitly override the provisioned value at the user record or explicitly excluding a field from future updates in the user mapping sounds like a valuable addition to the current mechanism.

Please feel free to create a ticket for this.

Hello Arie,

One more update regarding this:

Does this mean the Pool user will be able to update the user table from 2022.2.15 release onwards?

Upon further investigation we have decided that this needs to be fixed in IAM and not in Indicium. So there won’t be a fix in Indicium version 2022.2.15, but we will release a hotfix for IAM as soon as possible.

Hello Arie,

The mentioned hotfix for IAM has been released.

Anne Buit wrote:

While a default value for mandatory fields will be necessary for provisioning, having the ability to explicitly override the provisioned value at the user record or explicitly excluding a field from future updates in the user mapping sounds like a valuable addition to the current mechanism.

Please feel free to create a ticket for this.

@Anne Buit TCP 4905S created.

@Vincent Doppenberg Hotfix applied on our DEV and TEST environment, this indeed has the effect that now only 1 successful entry is logged in the Login attempts and that the User record is updated successfully. 

I intend to hold off from applying this on our PROD environment pending a fix for TCP 4905S though.