You might be thinking, we already have so many wonderful blog articles which explains how to do this. I agree. But in most of the cases, not the whole steps from the start to finish is mentioned to make it work in real life. In some cases, it is neatly depicted what you should do but why are you doing the same is missing. After all knowing the why part of it with the how part is something we always desire and helps us to design better solutions going forward.
So if you have not tried this, I hope that after reading this post you would understand things better than before. On the other hand if you have configured and the integration works for you as well but you are not sure about how it works, I would suggest you read this. If you have very good idea of what Azure Service bus is and how does ACS authenticates with service identity, unfortunately there is nothing new for you guys here. 
So let’s start. Let us split out the components and understand what role they play in this integration.
First is Azure Service Bus. For a quick understanding just think of it is a broker which passes messages between two components. You can compare this to postal services. You want to send a message to someone residing in some other part. You use the postal services. It takes the message from you and delivers it to the appropriate receiver. How does the postal service identify the receiver? Well you have mentioned the address right in the message envelope.
Comparing to the above, Dynamics CRM is the sender and a Queue configured in Azure service bus is the receiver. All you need to do is configure your service bus to collect the message from CRM and deliver it to the queue. And like the postal service, you would indeed need to provide the address of the queue to the service for it to deliver the message correctly.
So the whole thing works like this. A user of Dynamics CRM will post information to the Queue hosted in azure service bus. The service bus would need to authenticate CRM User against the queue. Any Dynamics CRM user who posts information to the queue and those claims should be understood by the Queue. Now since these are two separate applications, the claims generated from one might not be understood by the other as they might not speak the same language.
So now what. Here in comes the concept of Access Control Sevice in Azure Bus Services. The queue will be set-up to trust the Access Control service and any claims generated from the ACS would be accepted by the queue as a valid token and it would allow those messages to be sent to the queue.
The mechanism is very well explained in the below screenshot.
IP – Identity Provider. Here Dynamics CRM is identity provider.
ACS – The Access Control Service of Azure Service Bus
RP – Relying party which trusts the ACS. For our example it is the Queue.
Client – The user of Dynamics CRM who is trying to post message to the queue.
The mechanism is explained in the following steps.
- A user in Dynamics CRM tries to send a message to the queue.
- Since the queue does not get a valid ACS token, it redirects the user to the ACS
- The ACS in turn redirects the user to the Identity Provider which in our case is Dynamics CRM
- Dynamics CRM verifies that the request is generated from a valid user and generates a IP token (identity provider token).
- The user sends the IP token claims to the ACS
- ACS does the hard job of converting claims from IP token to appropriate claims understood by the Queue and sends an ACS token to the user.
- Now since the Queue trusts token generated from ACS, it will allow the message into the queue.
Hope now things are getting cleared up. And since we now understand the basics, once we do the steps, we know why are we doing this apart from how to do it.
So let us check all the steps we need to do for this. I have broken this down in a series of blog post otherwise a single post would be pretty lengthy.
The next article explains on how to set-up the queue and also configure dynamics CRM as identity provider – https://debajmecrm.com/part-2-complete-in-depth-walkthrough-of-dynamics-crm-plugins-with-azure-service-bus-queues/
Discover more from Debajit's Power Apps & Dynamics 365 Blog
Subscribe to get the latest posts sent to your email.
Good start to the series. Appreciate the effort to simplify however you should be very careful about not confusing the readers:
> The ACS in turn redirects the user to the Identity Provider which in our case is Dynamics CRM
Dynamics CRM is *not* an identity provider, AAD is. It’s important to understand that CRM is just a resource that can be granted access to by AAD.
Thanks.
For this integration context, Dynamics CRM is configured as service identity. And service identities are credentials that are configured globally for the Access Control namespace that allow applications or clients to authenticate directly with ACS and receive a token. In the part 2 of the blog, I have mentioned about service identities which makes it more clear. It acts as the claims issuer in the integration. If we explore the rule groups, we can see that. (The last one in the screenshot below)
However let’s take the context for CORS (Cross origin resource sharing). Let’s take the example of a external HTML page trying to to interact with Dynamics CRM OAuth endpoint and trying to gain access, in that case Dynamics CRM is the resource which is given access to by AAD to the HTML standalone page.
It’s more of an analogy I am trying to draw here to make things clear to the readers.
Since you have good command on this subject, would certainly like to know more on this. And you perspective about both the scenarios that I have mentioned above. Would be interesting.
Regards
Debajit