MSMQ, WCF and IIS: Getting them to play nice: The extras, Part I

I've recently been trying to set up queued publishing of data in my company within our internal applications so that we can publish that data out to other applications running in our hybrid cloud with Azure. To move the data around on-premise, I've been working off of the advice given to me by some very knowledgeable people in the IT space, and using architectural design patterns that have been proven to work (though not by me). To implement our new data-publishing architecture, I decided to leverage components I already had at my disposal and use WCF with MSMQ bindings to deal with unreliable connections from some of our remote sites. To help me get started, I began following the series of articles published here on MSDN by Tom Hollander. I was able to get past Part 1 of the tutorial without problem. I even needed the same architecture: a queued message client publishing to a service, via a queue hosted on a 3rd party system.

Part 2 however, securing the queue, proved to be a little bit harder, to the point where I needed to go to stackoverflow.com for help and posted this question. In the question, I kept running into an error when I tried to enable Transport security along with ActiveDirectory support. When I didn't enable ActiveDirectory support, I got a different error, with the code 0xC00E0030. Looking on the page for MSMQ queueing error codes on MSDN, I found that this error means that there was corrupted security data, somewhere. Here's what I had to do to resolve it:

1. In the EndpointAddress for my WCF binding, I had to add an extra parameter to the constructor for the EndpointIdentity of my binding: New EndpointAddress(queueUri, EndpointIdentity.CreateDnsIdentity(queueUri.Host))
2. I had to gain access to the server where I was hosting my MSMQ Server, and gain full access to the Server itself:  Computer Management -> Message Queueing -> Right-click -> Properties -> Security tab -> [my name] -> "Full Control"
3. I had to re-register my own Internal Certificate for MSMQ on the server: [previous steps] -> User Certificate tab -> Internal Certificate section -> Renew....

After cleaning up the certificate and adding the endpoint, I was good to go, and I could now authenticate and send messages to the MSMQ server.

To be fair to Tom Hollander, he did say that there would be some extra specifics to getting Authentication working, and I guess these were mine. I have to send him a lot of thanks for going through what he did AND recording and publishing the steps. People like him make the world a better place.

Using ADAL.js correctly with AngularJS when setting up your endpoints

When searching around and using the tutorials on how to correctly use adal.js to authenticate your calls to Web API (or anything else) in Azure, you'll often see a block similar to this that you have to put in your App.js to configure your main module:

adalAuthenticationServiceProvider.init(
{
tenant: 'mytenant.onmicrosoft.com',
clientId: 'abc4db9b-9c54-4fdf-abcd-1234ec148319',
endpoints: {
'https://localhost:44301/api': 'https://some-app-id-uri/'
}
},
$httpProvider
);

You'll notice that this appears to be pointing to the Web API root of a service running on localhost, and you'd be right. For this to work correctly, you'll need to enable OAUTH 2 path matching in the application manifest of the **client** that's connecting to the service!

Updating your Azure AD Application Manifest

We've recently found that as we develop more applications in Azure, we need to put safeguards on the deployment of the applications to ensure that they're configured correctly. Part of this means editing the application manifests to ensure that certain settings are always enforced on certain applications. Here's what Microsoft has to say about updating Application manifests.

Bottom line, if you want to automate anything to do with manifests, you'll have to write your own application to use the Azure Graph API libraries to retrieve the manifest / application settings and edit them.

Using adal.js and getting error AADSTS65001: The user or administrator has not consented to use the application with ID '....'

It turns out that you have to actually go in and give your javascript web client permissions to access the web api application in the Azure Active Directory management portal. Go figure.

Getting the Active Directory cmdlets (for scripted and remote management of your Windows Server machines)

To get the cmdlets, you'll need to install the Remote Server Administration Tools, available here.

Alternatively, you can follow the instructions on this blog: http://www.itgeared.com/articles/1072-how-to-install-rsat-on-windows-server_21/

Retrieving the list of Service Principals in your Azure subscription(s)

Recently I found that I needed to grant certain users permissions in my applications, specifically I needed to put Service Principals into groups in order to grant them permissions in my application so that they can access protected data.

I found out that in Azure PowerShell, there's the module 'MSOnline', which contains the following pertinent commands:

Connect-MsolService:

Connects your current session to your MSOnline account

Get-MsolServicePrincipal:

Retrieves a listing of all of the Service Principals in your subscription(s)

Setting up delegated authentication between web apps in Azure Active Directory - quirks

When setting up your Azure App ID for your web apps, it's extremely important that you follow the recommended format of "https://<your tenant name>/<your app name>"

Otherwise, delegated authentication will NOT work!!

Using ADAL in Javascript to enable use of Azure Active Directory from an AngularJS SPA

Check this out, apparently it came out last fall in Azure:

http://www.cloudidentity.com/blog/2014/10/28/adal-javascript-and-angularjs-deep-dive/

Enabling group membership claims in delegated tokens in Azure Active Directory

In your application manifest, add the following to the root object:

{
   ....
  "groupMembershipClaims": "All",
   ....
}

Fixing redirect loops in Azure web apps that use Azure Active Directory for authentication

We've recently been using Azure Active Directory to handle authentication for a bunch of our Line-Of-Business applications that we're moving into the cloud. Unfortunately, we've been noticing that in some circumstances, we encounter redirect loops that the browser can't break out of and I've been scratching my head over it. As it turns out, the loops had a common cause: going to a URL in the application that started with http://.

Since we're all good programmers here ;), we always want to be using best practices and enforcing secure connections anyway, but it also turned out to be the fix: adding [RequireHttps] to the top of our filters list in FilterConfig.cs solved the problem and closed a security hole at the same time.

As for the initial cause: why would anybody be using HTTP anyway ? It turns out that HTTP is the default scheme for URLs in the Azure portal when you're viewing the settings for an application and people were clicking on those links to go straight into the app.

Alex

My website doesn't accept my Active Directory credentials and just keeps prompting me over and over. Or if it's Chrome, just gives me a middle finger straight up.

Recently, I've been having the problem of trying to reach some of the internal applications that my company develops that uses Windows Authentication. Thanks to this article:

http://www.leftycoder.com/windows-authentication-chrome-iis/

... I found out why. I had to remove the option for 'Negotiate' with Windows Authentication. The settings had changed when we moved our applications to a new IIS Web Site. Something to keep in mind.

Implementing delegated authentication from an Azure MVC web app to an Azure Web API web service

Follow the information on this tutorial. Contained within that link, is this tutorial on authenticating a web app with delegated user identity to a web API service.