Migrating a bespoke company intranet to Azure meant we could no longer authenticate users' domain credentials in IIS. Luckily, Azure has a good API for authenticating and identifying users.
A lot of the functionality of our bespoke intranets depends on knowing who the user is - what administration privileges do they have? Do they have any alerts? Has anything been added that matches their tag subscriptions? When have they booked a desk for?
When you're hosting an intranet within a corporate network behind a firewall, this is relatively easy. The user is logged into the windows domain, and you can configure IIS to include their username in the CGI variables when their browser makes an HTTP request for an intranet page. The intranet server can compare the username with it's staff list and identify whose information and administration privileges to display. However, when the intranet is moved to the cloud, this is no longer an option.
We recently moved a bespoke Coldfusion-based company intranet to Microsoft Azure, and we needed a new way of identifying users. This was part of a wider company migration to the Azure platform, including Active Directory, and it was this that saved the day.
The Microsoft Identity platform is built to solve these kinds of issues - it provides a series of APIs and sample code to allow developers like us to use Microsoft's authentication routines to identify users - as long as those users are in Active Directory and can log in to Azure.
A lot of the functionality of our bespoke intranets depends on knowing who the user is - what administration privileges do they have? Do they have any alerts? Has anything been added that matches their tag subscriptions? When have they booked a desk for?
The first thing we needed to do was register our web application by filling out a web form in the Azure portal. It was pretty straightforward - choose a name, select who has access and provide a redirection URL.
This redirection URL is important. When a user opens the intranet in a browser, if they are not authenticated they will be redirected to an Azure login form. Once they have successfully logged in, they are redirected back to the intranet, and this redirection URL is where they will land. Their authenticated email address is included in the redirection, and that is the all-important piece of information that allows the intranet to check it's staff list and recognise the user.
Microsoft provides Javascript code to drop into the application code to handle the redirection to Azure login and back again. It all integrated very smoothly into our existing code, and removed a potential stumbling block in the Azure migration project.
If you would like to find out more about web applications on Azure and other bespoke developments, please do not hesitate to get in touch.
