Skip to main content
Solved

Creating IAM Users in scheduled flow in custom application leads to not_authorized_usr_admin error

R
Sidekick
Forum|alt.badge.img

We like to automatically create users in IAM based on data in our custom application in that very IAM. It is intended to do this in a stored procedure which is involved in an automated process, started by a scheduled flow. This does not work. The error not_authorized_usr_admin is logged in the indicium log when trying to insert User records into the IAM database.

It seems that the pooluser somehow does not have permissions to insert records in these IAM tables. We did some extra tests, which resulted in the observations that the code that creates the User records in IAM works fine in the situation when it is executed in Azure Studio in the same circumstances, even with the same authentication (being the pool user). This seems to indicate that the problem is somehow more complex. 

Can you please help us out in this matter?

Best answer by Mark Jongeling

Hi Richard,

I would like to ask you to create a ticket in TCP for this. We should look into this and make sure, like you said, that the pool user does not need to be listed in the IAM Users table.

 

Right now we are thinking about a dedicated IAM user, and using that user in a database connector action in a process flow to insert/update Users in IAM. Does this seem to be a good idea?

Technically you could but it will cost a lot of effort to build I think. Temporarily listing the pool user as User in IAM is the quickest way. The password of this user (I believe) does not need to be the same as the actual password for the pool user becuase this user doesn't log in, but rather connects to it in a different way that allows it to manage IAM and the applications inside.

 

Moreover, we also like to insert/update/delete user group assignments for IAM users, and add tags to IAM users as well. Does the pool user have rights for these actions, or should we use a dedicated IAM User for this as well?

The pool user should have all rights to the IAM database and any application databases that are inside IAM as applications (db_owner would do the trick). This way the pool user can interact and indeed manage all of your mentioned tables.

Inside IAM is an extra layer of rights as the IAM application itself is a bit complex in the sense that you cannot assign roles to a particular user, but can only user the Administration screens as details of the User screen. This effectively works just like roles, f.e. Root administration is All rights, User administration is a set of roles to manage users.

View original
Did this topic help you find an answer to your question?
This topic has been closed for comments

Mark Jongeling
Administrator
Forum|alt.badge.img+23

Hi,

Being a User admin is required to create users. You can make sure the Indicium (pooluser) can create users by creating a user for that pooluser in the target IAM, and making that user be Root administrator. This way this user can create users in any tenant.

Hope this helps!

"Wake me up before you low-code"
R
Sidekick
Forum|alt.badge.img

Hi Mark,

This solution is unfortunately not working for us, since we don't want to have the pool user as an IAM user for security reasons.

Right now we are thinking about a dedicated IAM user, and using that user in a database connector action in a process flow to insert/update Users in IAM. Does this seem to be a good idea?

Moreover, we also like to insert/update/delete user group assignments for IAM users, and add tags to IAM users as well. Does the pool user have rights for these actions, or should we use a dedicated IAM User for this as well?  

Mark Jongeling
Administrator
Forum|alt.badge.img+23

Hi Richard,

I would like to ask you to create a ticket in TCP for this. We should look into this and make sure, like you said, that the pool user does not need to be listed in the IAM Users table.

 

Right now we are thinking about a dedicated IAM user, and using that user in a database connector action in a process flow to insert/update Users in IAM. Does this seem to be a good idea?

Technically you could but it will cost a lot of effort to build I think. Temporarily listing the pool user as User in IAM is the quickest way. The password of this user (I believe) does not need to be the same as the actual password for the pool user becuase this user doesn't log in, but rather connects to it in a different way that allows it to manage IAM and the applications inside.

 

Moreover, we also like to insert/update/delete user group assignments for IAM users, and add tags to IAM users as well. Does the pool user have rights for these actions, or should we use a dedicated IAM User for this as well?

The pool user should have all rights to the IAM database and any application databases that are inside IAM as applications (db_owner would do the trick). This way the pool user can interact and indeed manage all of your mentioned tables.

Inside IAM is an extra layer of rights as the IAM application itself is a bit complex in the sense that you cannot assign roles to a particular user, but can only user the Administration screens as details of the User screen. This effectively works just like roles, f.e. Root administration is All rights, User administration is a set of roles to manage users.

"Wake me up before you low-code"
R
Sidekick
Forum|alt.badge.img

Hi Mark,

You are right that having the pool user in IAM, with user admin rights, does the trick, and that this is by far the quickest way to make things work… However it seems to be no option for us (I will double check if it is indeed)

Regarding the TCP: I'm not sure if I get what you mean.. your reason for the TCP sounds like that it should not be needed to list the pool user in the IAM Users table to make the pool user have rights to create IAM Users, however last night you said that it is needed for any user, including the pool user, to have IAM User Admin rights before being able to do that.. Can you clarify this a bit?

 

Mark Jongeling
Administrator
Forum|alt.badge.img+23

Hi Richard,

I meant TCP as in the Thinkwise Community Portal: Thinkwise Community Portal (TCP) 😄. This is the way to create a ticket for us to be able to process your request for change or to resolve an issue. 

"Wake me up before you low-code"
R
Sidekick
Forum|alt.badge.img

Hi Mark,

Sorry for the confusion. My question was not about the term TCP, but about the content of the bug, since last night it seemed that you said it was normal for the pooluser to need a user listed in IAM, and this morning you seem to state that this is not intended behavior and that the pool user should NOT need a user listed in IAM to have permission to create IAM users.. So I was not sure what the actual bug is in this matter..

 

I created a ticket in TCP as well

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings