In this blog, we show step by step how to use your Azure Active Directory to implement a B2B experience on your Power Apps portal.
In today's world of hyper-awareness around security and compliance, many companies are struggling to find ways to protect their data. On the surface, encryption seems like the most effective way to do this – and in some cases that is true.
Disk level encryption has been around for years and can be as simple as clicking a button to enable. For workloads running in Azure, disk level encryption is the standard and turned on by default. This baseline protection only helps in the case of stolen or lost disks or containers that are downloaded without using the proper authentication. For example, if your laptop disk is encrypted and you were to lose your device, no one could get to the data without your login. However, once you are logged in, you have access to all your data, which is how it needs to be for the data to be useful.
When we think about how data is accessed, this once-logged-in vulnerability is very common. As another example, let's look at SQL server. A SQL database is stored on a disk. If that disk is encrypted the disk controller or the OS decrypt the data before SQL server even sees it. Therefore, anyone with access to the SQL server can still see all the data.
The workaround for this is to encrypt data at the SQL server layer. SQL Server 2016 and above offers some great features to facilitate this, but not every application can take advantage of them because it requires a very specific chain of SQL commands to encrypt and decrypt data. Although most modern applications will have no issues with this, some still do.
Microsoft Dynamics 365 for Finance and Operations is one such application. Since the SQL connection code is part of the kernel, developers have no access to it and cannot implement the newest SQL encryption features. This means that the encryption must happen at the application layer. To complicate matters further, the SaaS model prevents developers from easily accessing certificates or keys that are common artifacts in encryption algorithms.
Enter Azure KeyVault. Azure KeyVault is a Key Management System (KMS) that is itself a SaaS offering. Because the service is available to any system that can connect to the Internet, we can take full advantage of it in D365 for Finance and Operations.
This blog will show a simple way that a developer can implement key-based encryption to store SQL data consumed by D365 for Finance and Operations. If implemented correctly, this method could even be used to protect production data that is restored to dev/test environments. On the other side, companies that are implementing BYOD would need to ensure their changes did not remove access that data.
To understand what components are involved, here is an overview of the process.
Any user that has access to the Azure subscription it is deployed in can access a KeyVault. This user level access is cumbersome when calling from a potentially large number of applications. As such, we can define an application at the Azure tenant level and provide the application access to the KeyVault. This will generate an application id and key that can be used to provide authentication.
Once we have the application defined, we will need to consume it in our D365 for Finance and Operations code so that we can query the keys defined that will be used during the encryption and decryption process.
As a final step, we will need to modify the insert, update, and read methods of the table that we will be storing encrypted data in.
Note that this document does not present a complete and secure implementation. Care must be taken to not lose the key used in encryption as it can result in the permanent loss of data. At the same time, control of who has access to the key is critical as anyone with the key can decrypt the data.
To complete this setup, access to an active Azure subscription is required. This blog will show how to complete the process using the Azure Portal; however all these steps can be completed using PowerShell or the CLI.
To start with, we will create the Azure KeyVault.
1. Log in to the Azure Portal.
2. Click All services and enter Key vault in the Filter field.
3. Click on Key vaults.
4. Click Add to create a new Key vault.
5. Enter in the required information and click create.
6. Open the newly created Key vault.
7. Click on Keys.
8. Click on Generate/Import to generate a new key.
9. Make sure Generate is selected, enter a name and click Create.
10. Click into the new Key and copy the Key identifier. We will need this later.
With the Key created, we now need to create an application that will grant us access to the Key Vault.
1. Click on Azure Active Directory in the Services list.
2. Click on App registrations.
3. Click New application registration and enter the information.
4. Note, the Sign-on URL does not have to be valid but should belong to a domain registered to you or your company. Make note of the URL, we will need it later.
5. You may have to change the dropdown filter to All Apps to see the newly created app.
6. Click in to the App and click Settings.
7. Click into Required permissions under API access
8. Click Add.
9. Click Select an API.
10. Highlight Azure Key vault in the list and click Select.
11. Click Select permissions.
12. On the Enable Access blade, click to select Delegated Permissions and Have full access.
13. Click Select and Done.
14. Still in the Application, click on Keys.
15. Enter a new Key description and select an Expires date.
16. Click Save.
17. The Key value will be displayed
18. COPY THE KEY VALUE NOW. There is no way to return to it or recover it if it is lost.
19. Note that this secret can be used to control application access and can be set to expire. If there is ever any doubt that it has been compromised, simply generate a new secret and update the applications using it. This will not affect the encrypted data as it only affects access to the Key vault and not the Key vault itself.
Now that the Application is created. We must give it access to the Key vault.
1. Return to the Key vault created in the previous section.
2. Click on Access Policies.
3. Click Add new.
4. Click Select principal.
5. Scroll down or search for your application and select it.
6. Highlight it and click Select.
7. Click on the Key permissions dropdown and select Get, List, Encrypt and Decrypt.
8. Click Ok.
The last step before D365 for Finance and Operations can use the KeyVault is to create a C# Class Library that will link to the KeyVault.
1. Open Visual Studio.
2. Create a new project.
3. Highlight Visual C# and select Class Library.
4. Name the new project "EncryptionTest."
5. With EncryptionTest selected, click on the Project menu and select Manage NuGet Packages.
6. Click Browse to find and add Microsoft.azure.keyvault.
7. Select the returned image and click Install.
8. Accept any License agreements.
9. Repeat the browse and install for Microsoft.IdentityModel.Clients.ActiveDirectory.
10. Close the NuGet window.
11. Right click Class1.cs in the EncryptionTest project and select Rename.
12. Change the name to "EncCalls." Click Yes if prompted to update the project.
13. Open the EncCalls class and add in the following code:
This Class Library can now be linked to a D365 for Finance and Operations event handler method to encrypt and decrypt the data. That process will be reviewed in a future blog post.
While access to an Azure KeyVault can simplify the encryption of sensitive data, the implementation would need to be carefully reviewed. In the sample code provided, a call is made to the KeyVault for every encrypt and decrypt request. This may work for data that does not change or is accessed regularly, however, for large volumes of data this will become a bottleneck. Using the KeyVault to store they key, which could be retrieved at the beginning of a process and then running a local encrypt/decrypt method would provide the best performance.
Remember, always test in an environment that you can easily restore data to. Encryption can protect your data from everyone – even yourself – if you are not careful.
Be sure to subscribe to our blog for more Dynamics 365 tips and tricks!
Happy Dynamics 365'ing!