Announcing a New Active Directory Connector for Logic Apps

Just over a year ago, Codit welcomed Alfred, our personal butler that is taking care of our visitors. This has been a side project that I’ve been working on with Pieter Vandenheede, Wouter Seye and has been a ton of fun – if you’ve missed that, read more about it in this article.

In the past year, we’ve focused on improving our foundation while starting experimenting with bots.

Here is a brief overview of what we did:

• Automatically synchronize all employees based on the Codit AD – Fully exposed via an API and orchestrated via Azure Logic Apps.
• Migration from the Codit Internal Azure subscription to dedicated Azure subscriptions – Allows us to manage all resources as we’d like.
• Ability to determine how you want to be notified when a visitor arrived – Fully exposed via an API, ready to be consumed.
• Build more robust release pipelines in VSTS – Fully automated releases with deployment gates, Azure resource creation (ARM), Application Insights annotations and more

Automatically synchronize all employees based on the Codit AD

When we were building our synchronization workflow, we decided to use Azure Logic Apps as an orchestrator.

We are currently using the following Logic Apps:

1. Company Debatcher – Triggers a new run per company by passing the company name, such as Codit Managed Services, and a list of users that can be blacklisted. This can be used to filter out users that are being used by applications or for testing purposes.
2. Company Synchronizer – Retrieves all users from Azure AD for a specific company and filter out the blaclisted ones, if that is applicable. Once that is done, it will trigger a new run for every employee in the result set
3. Employee Synchronizer – Imports and configures default notification configuration in the Santiago platform via our Management API

Here’s a simplistic overview:

While building this synchronization flow, we started off using the built-in Azure AD connector. However, it soon began clear that this was not the best fit for us since it requires Global Administrator permissions.

We ask our Global Administrator if this would be ok but we decided that using Azure AD Applications to act on behalf of our platform would be the best fit.

Unfortunately, this is not supported at the time of implementation and decided to our own Active Directory „connector“.

Introducing Active Directory connector for Logic Apps

It took us a long time but as of today our Azure Active Directory connector with Azure AD Application support is now available on GitHub and ready to be deployed on your subscription.

Authentication

In order to use our connector, you’ll have to create & configure your Azure AD application in the Azure AD itself.

The Azure AD Application needs to have Read permissions for the Windows Azure Active Directory API API.

Want to learn more? Read our docs.

Features

Given our synchronization flow is centered around users, we only support the following operations for now:

• Get a list of all users
• Get a list of all users by company name
• Get a specific user by user principle name ie. foo.bar@codit.eu
• Send telemetry to Azure Application Insights

However, this is certainly not the end. If you’d like to request a feature or help us extend this we recommend creating a new issue.

Conclusion

Azure Logic Apps allowed us to very quickly build a synchronization workflow that easily integrates with our API. However, the built-in AD connector that we tried required us to use global administrator powers of our company active directory.

We did not want to do that given this is risky and decided to build our own Active Directory connector with Azure AD Application support. This Active Directory connector is now open-source and available on GitHub.

This enabled us to easily deploy and integrate it into our workflow and query our Active Directory with limited capabilities and still achieve our goal.
Although the component is very limited; we are open for suggestions and accept contributions, but prefer to discuss them in an issue first.

But this is only the beginning, we are working hard to open-source Alfred & Santiago as well so that you can run your own version of our internal visitor system.

Thanks for reading,

Tom.