Developer forum

Hi

The section ADDING AN API PERMISSION describes where to set the permission in Azure. The permissions it delegated through the user, so the user used to attain the token must have the correct permissions.

In DW 9.14.2 we are going to release OAuth Service-To-Service, where DW is authorized access directly to BC, without the user impersonation.

Best Regards

Rasmus Sanggaard

>> The section ADDING AN API PERMISSION describes where to set the permission in Azure. 

Yes, we followed that section. However, we only ever added the user to Azure AD and never explicity to BC.

>> The permissions it delegated through the user, so the user used to attain the token must have the correct permissions.

And which user is that? We don't see an additional user in BC. Where / how would we set permissions for that user?

Imar

Hi Imar, 

You need a licenced user in BC with correct permissions when using the OAuth 2.0 - User Impersonation. So either set it up with that user in Azure and attain token by logging in inside DW or send the Authorization URL to the user with correct permissions. We do not have documentation on setting up permission in BC.

The above is sometimes a cumbersome process if you do not have the BC license yourself, therefore we have also made the OAuth 2 - Service-to-Service, which is in the next release 9.14.2. 

Best regards 

Rasmus Sanggaard

Yes, I am aware of that, thanks. But I think you are missing what I am asking, and what I am confused about. As far as I can tell, all we did was create an Azure AD user. We then set up the permissions on the app registration against BC. And finally, we created the token by validating the URL with the AD user. After that, things just worked and we got data back from BC. But I don't understand why. Where did this AD user become a BC user? And what powers does the user that we impersonate have in BC? When looking at the users in BC I don't see this newly created user nor does it seem to consume a license, so how does this work?

Thanksl!

Imar

Hi Imar

I was a bit confused at the beginning as well, so I will try to explain. When using delegated permission you are only using the App Registration user for impersonating a real BC user.

So if you have created App Registration (AR) setup with delegated permission, this AR is not a BC user in itself nor can you use it exclusively to gain access to BC. You can only use this to impersonate a licensed BC user, which then grants a token. The permission is then granted based on the licensed BC user you used to authenticate when requesting the token. If you didn't get prompted for login to BC, it was probably because your browser session was already authenticated on a specific licensed BC user on that tenant.

So for delegated permission you need both an App Registration and a licensed BC user. This differs from S2S authentication where you will set the permissions on the specific S2S user and requires no BC license. There's an article about it here: https://learn.microsoft.com/da-dk/dynamics365/business-central/dev-itpro/webservices/authenticate-web-services-using-oauth

BR Chris 

Thanks Chris, that helps. I am still a bit confused as the AD and BC admin claims he only created an AD user and then things magically worked. It could be that they are just confused, or I am.

I just wished the docs were way better so we could send them off to an ERP partner or network admin without having to spend hours and hours on the phone with them trying to talk them through it one step at a time :-(

Imar

Hi Imar

I have added some additional info to the BC OAuth User impersonation guide to clarify that the API permissions reflect the permissions of the BC user used to log in when requesting the token.

Regarding the mentioned case, it sounds to me like the admin was already a licensed user in BC when adding the authentication, and therefore was able to obtain the token with his BC credentials. 

Kind regards Tobias

Thanks Tobias!