ICAEW - Identity IntegrationApril 10th 2019
Identity Integration is a great feature to have and it can save you from logging in to applications several times- all you need is the one log-in. We built a framework in the cloud using Microsoft Azure and was able to stretch the active directory to a federated service.
Identity integration is an extremely useful feature to have within your organisation. What actually is identity integration though? Well, it’s quite simple- instead of having to log in several times to several different applications, you can log in just once, and be logged into all your other applications. So, for example, if you log into Microsoft Office and need to use Dynamics as well, you won’t need to input your credentials again as the integration will have linked these applications together and recognised that you are the same user. Imagine the ease of access and movement you’ll have without the interruption of having to enter your credentials! At this client’s organisation, this is exactly what they were looking to achieve- the identity authentication, validation, and the management of your documents on top of this. This case is about a traditional on-premise active directory which wanted to implement this identity integration into their organisation.
The only real challenge that arose was related to the Active Directory. Within the AD, there is a database with fields that need the correct information inputting otherwise it will not work. In some cases, the customers tried to fill out the fields with information that did not correspond with the field’s requirements and so this caused some delay, but it was a simple challenge to fix. Another area that we needed to implement was a second authentication location and so we wrote and synced some bespoke directory. This was easy for us as we have the knowledge to understand and adjust the infrastructure build- although it is simple, it is an important aspect to get right.
How did we deliver this project? The main action was that we took their current active directory and then built a framework in the cloud where we’d transferred their information. We then stretched the active directory validation into the cloud infrastructure, and this was then used as their validation criteria. So, how was this done?
First of all, as we do with all projects, we went through a Discovery Process where we learnt about the client’s systems, development and processes currently in action. Usually we find that many active directories within organisations are old and out of date and more often than not, some facets are being used for functions that they are not designed for. This in itself can cause issues as the application is being made to do things that it is not correctly built for. So, the first thing we did was to look at their version of Windows and their active directory to see if the two were compatible. Having explored their active directory, we found that, due to several legal systems and services, it contained a mix of Windows 2008, 2012 and 2016 servers. This tends to happen when people update their systems to the next updated version of Windows. Although the system updates, their active directory doesn’t as it is a separate system. Luckily, our engineers have dealt with ‘old’ active directories and have the knowledge of how they work and also how to update them so that they work seamlessly with the current systems and updates.
Once we had updated it, we built a DSv environment and made a replica of their current on-premise system on it so that we could test different solutions out and see what worked best. We did this on the cloud because it allowed us to tear it down and rebuild the system really quickly in Azure- another skill of ours! We like to test plans A, B, and C etc and tweak them so that we can create the best environment for your organisation’s needs. Why create an exact replica in the first place though? Surely you want to create the solution? True, however, when replicating the current system, it also allows us to hit all the problems that they have- we can adjust and fix them in the test environment and understand what works and what doesn’t without breaking the live system. If we did these adjustments in the active directory environment (the live environment) and it breaks down, this would ultimately break the whole system and would create many issues for the organisation.
Is that all we did in this project? No! We try to go above and beyond (within reason and discussions with the organisation, budget etc) to create the best and most efficient system for our clients. In addition to fixing the issues in the active directory and improving it, we were also able to stretch out the active directory to other services, also known as a federated service. Was this complicated to do? No, it was a smooth addition as we have re-created and updated the active directory now in action. Simple! So, we got this to run concurrently with the old version (which used V3 legacy applications, where we use V4) but this can still run alongside each other. For example, if I log in with my email and I want to access my hosted document management service, the active directory in the cloud will recognise my credentials and creates a seamless login, meaning that I can access these documents without having to log in again. We use cloud hosted services to create federate services as it can identify multiple services which makes businesses and integrations much easier.