Azure API Management is an API gateway that can be used to publish APIs to the Internet. It provides features such as per-developer API keys, request throttling and request authentication. One of the way requests can be authenticated is through standard OAuth2 bearer tokens. I assume that the most common scenario is to use Azure AD to issue those tokens. But if an organisation is not that cloud enabled yet and the users are in an on prem AD, the natural token issuer is to use ADFS. And ADFS on Windows Server 2016 supports OpenID Connect, so it should work, right?
Well, it turns out it didn’t just work. The OpenID Connect implementation in ADFS has some quirks that need to be handled. In the end it worked, but with some limitations.
Lately I’ve been doing some experiments with Active Directory and of course I’m running my lab environment in Azure. It works great, until after 42 days the password of the one and only user account (mine) in the domain expires. Azure only provides remote desktop access to virtual machines, and in a default setup it’s impossible to change the password over rdp once the password has expired.
In all modern incarnations of remote desktop, the user authentication is done during the connection phase. This is called NLA: Network Level Authentication. It means the user name and password is entered in the Rdp client, as part of the connection setup. Not like in the old days where the remote desktop would show up and present the same user name and password prompt as if one were actually sitting at the physical console. In the old days, the remote server could show a password expired message and force a password reset before the logon was accepted. With NLA, that just doesn’t work. So what we need to do is to disable NLA, without logging on to the remote machine.
In a recent project using Azure, SSL worked perfectly on all devices – but those running Android 2.X. It turned out that legacy Android has limited support for modern SSL/TLS features such as SNI and subject alternative name.
Getting TLS configuration right nowadays can be quite tricky. Google Chrome is aggressively pushing for deprecation of old insecure standards by showing warnings or even errors on sites using deprecated https settings. Using a certificate issued merely two years ago, with the standards where common then now shows an error because the SHA-1 algorithm is not considered to be safe for the two remaining years of the lifetime of the certificate. The Google Chrome team is definitely pushing hard for moving web cryptography to safer grounds.
On the other end of the scale (no, I won’t be complaining about Windows XP, it’s not that much of a problem any more) is another Google product: Android. Even with the blazingly fast technology development, people are (IMHO rightfully) expecting a multi €100-device to last for more than a few years. That means that a lot of devices out there are still running Android 2.X. In this particular project, the target audience are not that tech-savvy. A lot of the users even have had to invest in their first smart phone, making their call-and-sms-only phones to history. With that audience, we had to support those old devices. On the other hand SSL warnings or errors in Chrome was unacceptable, so we had to find something that worked for all those platforms – and we did. Oh and by the way, the budget was really, really tight, so we had to find something that wasn’t too expensive.
I was recently made aware that some unit tests for Kentor.AuthServices were failing on non-English computers. To be able to test a different setup I turned to Azure and set up a machine with VS2013 Pro and installed Swedish language support. Once I found the right way, it was very straight forward.
The problem was that I had set up a number of unit tests to check the actual contents of the exception message. Those are customized when running on a different UI culture (if the language is installed).
Just checking the type of the exception would not be enough as some methods throw
ArgumentNullException for different parameters and I want to make sure that it is the right param that is detected and not a false positive. Following the TDD practices as strictly as possible on this project I had to get failing tests first, before making any changes.
I also wanted to make sure that it’s possible to develop and run all tests on VS Pro (I’m using Premium myself). It’s easy to accidentally use a tool that is not available in Pro and this was a perfect opportunity to check that.
So I headed over to manage.windowsazure.com to get started.