Azure Active Directory (AAD): Common Application Development Scenarios

Posted on July 18, 2015 by Thuru

Azure Active Directory is a cloud identity management solution, but not limited to cloud identity alone. In this post let’s discuss about how AAD can be used in designing multi-tenant applications in cloud. As usual consider that MassRover is an ISV.

MassRover got this great idea of developing a document management application named ‘Minion Docs‘ for enterprises, they simply developed the application for Intranet using Windows Authentication. VTech was the first customer of Minion Docs. MassRover installed the application on premise (in the VTech data centers).

After a while VTech started complaining that the users want to access it outside the organization in a more secure way using different devices, and VTech also proposed that they are planning to move to Azure.

MassRover decided to move the application to the cloud in order to sustain the customers, also they realized that moving to the cloud would open the opportunity to cater multiple clients and they can introduce new business models.

Creating Multi-Tenant Applications

The Intranet story I explained is very common in the enterprises.

All the organizations have the burning requirements of handling the modern application demands like mobility, Single Sign On and BYOD without compromising existing infrastructure and the investments.

MassRover team decided to move the application to the Azure in order to provide solutions for those problems and leverage the benefits of the cloud.

First Mass Rover got an Azure subscription and integrated Minion Docs as a multi-tenant application in their AAD. As an existing Intranet application this requires minimum rewrite with more configuration.

The below setup window is the out of the box ASP.NET Azure Active Directory multi-tenant template, you see in Visual Studio.

Registering an application in AAD as a multi-tenant application allows other AAD administrators to sign up and start using our application. Considering the fact that Minion Docs is an AAD application there 2 primary ways that VTech can use Minion Docs.

Sync Local AD with AAD along with passwords – allows users to single sign on using their Active Directory credentials even though there’s no live connection between local AD and AAD.
Federate the authentication to local AD – users can use the same Active Directory credentials but the authentication takes place in local AD.

The only significant different between the above two methods is, where the authentication takes place; in the AAD or in federated local AD.

Local AD synced with Azure Active Directory with passwords

VTech IT decides to sync their local AD with their AAD along with the passwords. And VTech AD administrator signs up for the Minion Docs and allows the permissions (read / write) to Minion Docs.

What happens here?

MassRover created and registered Minion Docs as a multi-tenant Azure Active Directory application in their Azure Active Directory.
VTech has their local AD which is the domain controller which had been used in the Minion Docs Intranet application.
VTech purchases an Azure Subscription and they sync their local AD to their Azure Active Directory along with the passwords.
VTech Azure Active Directory admin signs up for the Minion Docs application, during this process VTech admin also grants the permissions to the Minion Docs.
After the sign up Minion Docs will be displayed under the ‘Applications my company uses’ category in the VTech’s AAD.
Now a user named ‘tom’ can sign in to the Minion Docs application with the same local AD credentials.

Sign in Work Flow

Few things to note

Minion Docs does not involve in the authentication process.
Minion Docs gets the AAD token based on the permission granted to Minion Docs application by the VTech AAD admin.
Minion docs can request additional claims of the user using the token and if they are allowed Minion Docs will get them.
Authorization within the application is handled by the Minion Docs.

Local AD is federated using ADFS

This the second use case where the local AD is synced with the AAD but VTech decides to federate the local Active Directory. In order to do this, first VTech should enable ADFS and configure it. ADFS doesn’t allow any claims to be retrieved by default, so VTech admin should specify the claims as well.

Federated Sign in Work Flow

In the federated scenario the authentication happens in the local AD.

As an ISV Minion Docs is free from, whether the authentication happens in the customer’s AAD or in their local AD.

Tenant Customization

Anyone with the right AAD admin rights can sign up to the Minion Docs, but this is not the desired behavior.

The better approach would be during the first sign up we can notify the Minion Doc administrators with the tenant details and they can decide or this could be automated in subscription scenarios.

A simple example, consider Voodo is another customer who wants to use Minion Docs. The Voodo admin signs up and before adding Voodo as an approved tenant in the Minion Docs database they have to complete a payment. Once the payment is done Voodo will be added to the database. This is very simple and very easy to implement.

Azure Key Vault setup and usage scenarios

Posted on May 30, 2015 by Thuru

Introduction

At the time of this writing Azure Key Vault is in preview. Azure Key Vault is a secure store solution for storing string based confidential information.

The reason I’ve mentioned that the string based confidential information is that you can store a key used for encrypting a file, but you cannot store the encrypted file itself as a file object; because some people have the confusion what could be stored inside the Key Vault.

Azure Key Vault – http://azure.microsoft.com/en-gb/services/key-vault/

Key Vault store 2 types of information

Keys
Secrets

Secrets– This could be any sequence of byte under 10 KB. Secrets can be retrieved back from the vault. Very much suitable for retrievable sensitive information like connection strings, passwords and ect. From the design point of view, we can either retrieve the keys every time we need or retrieve it once and store in the cache.

Keys – Keys could be imported to the vault from your existing vaults, also if your organization has Hardware Security Modules (HSM) you can directly transfer them to HSM based Azure Key Vault. Keys cannot be retrieved from the vault. For example if you store the key of a symmetric encryption which encrypts the files, you should send the files to vault ask the vault to encrypt / decrypt the data. Since keys cannot be retrieved from the vault this provides a higher isolation.

Keys could be stored in 2 different ways in the vault

Software protected keys
Hardware protected keys

Software Protected Keys – This is available in the standard tier of the vault. Compared to the Hardware protection this is theoretically less secured.

Hardware Protected Keys – HSMs are used to add premium hardware based circuitry secure storage for the keys. The most advanced key vault system available.

Provisioning Azure Key Vault

As Azure Key Vault is used to store sensitive information the authentication to the Azure Key Vault should happen via Azure AD. Let me explain it in simple steps.

First a subscription administrator (either the service admin or co-admin) will create a Azure Key Vault using PowerShell.
Then the admin registers an Azure AD application and generate the App Id and the App Secret Key.
Admin grants the permission (trust) to the App to access the Key Vault using PowerShell.
The subscription where the Vault is created should be attached to the Azure AD where the accessing app in the above step is created.
This ensures that accessing app is an object of the Azure AD on which the subscription where the Vault is created is attached to.

Sometimes the 4th and 5th points might be bit confusing and you might face them especially when dealing with the multiple Azure subscriptions. See the below image for a clear picture.

Assume that you have two subscriptions in your Azure Account, if you create the Vault in the Development subscription the app which can authenticate to the Vault should be in the Default AD. If you want to have the app in the Development AD you have to change the directory of the Development subscription.

Usage

Assume MassRover is a fictional multi tenant application on Azure.

ISV owns the Azure Key Vault

Scenario 1 (using secrets to for the encryption) – MassRover allows users to upload documents and it promises high confidential data security to its tenants. So it should encrypt the data at rest. MassRover uses it’s own Azure Key Vault to store the secrets (which are the encryption keys). A Trust has been setup between the Azure Key Vault and MassRover AD client application. MassRover Web App authenticates to the Azure Key Vault retrieves the secrets and performs the encryption / decryption of the data.

Scenario 2 (using keys) – MassRover Azure Key Vault stores the keys which cannot be retrieved out of the Vault. So the web app authenticate itself with the Vault and sends the data to the Vault to perform the encryption of decryption. This scenario has higher latency than scenario 1.

Tenant owns the Azure Key Vault

Tenants can own their Key Vault and give access to MassRover by sharing the the authorized application Id and application secret. This is an added benefit if the tenants worry about ISVs keeping the keys in their subscription and administrative boundary. Tenant maintained Key Vaults give additional policy based security for sure but latency is high since data transfer has to happen across different wires. (this could be solved to certain extent if the tenant provisions the Key Vault in same region).

Tenant maintained Key Vault also has 2 scenarios explained above, as either to go with the secrets or go with the keys.

Scenario 3 (using secrets)

Scenario 4 (using keys)

Useful links

Azure Key Vault NuGet packages (at the time of this writing they in pre release stage : http://www.nuget.org/packages/Microsoft.Azure.KeyVault/

PowerShell for provisioning Azure Key Vault and .NET code sample : https://github.com/thuru/AzureKeyVaultSample

Channel 09 – http://channel9.msdn.com/Shows/Cloud+Cover/Episode-169-Azure-Key-Vault-with-Sumedh-Barde

AWS Best login practice – IAM Policies

Posted on May 6, 2015 by Thuru

This post explains the best practice that highly recommended to be followed in AWS account and the Identity Access Management (IAM) policies in login process.

First the user account that is used to create the AWS account is the Root Account. (the composite credential of email address and password). For example if I go to AWS portal and submit email address thuru@qbe.com and the password along with credit card payment details, this account or the credential holder becomes the Root Account.

It is not recommended to use the Root Account for any purposes even to login to AWS portal. (unless required in very specific scenarios like changing core account details and payment methods)

The best practice is to create an IAM user with administrator privileges. IAM administrator has all the privileges except the core account privileges mentioned above. You can use the built it IAM administrator template for this.

Follow these steps.

First login to the portal as AWS Root User (as in the beginning Root User is the only one who has privileges to create Administrators). Root user will go to https://console.aws.amazon.com/console/home and enter email and password to login to the portal. You can note that this is a global URL for all AWS users all over the world.
In the portal go to under Administration & Security section click on IAM
Go to users and click create users. Name the user (ex – admin) and you can generate key for the user in order to access AWS services via APIs. It’s not recomended to use admin account for development purposes so better not to generate keys for admin. Click create to create the user.
By default the users do not get any permissions. In order to assign permission, click on admin (the user created in the above step will appear in the users grid). Under the permission tab click on attach policy.
First option is Administrator Access policy. Click on that to assign it and click Attach Policy button.
Then back in the page under Security Credentials section click on Manage Password to create a password for the admin.
There you can auto assign a password or can assign a custom password. You also get the option to make the user to change the password in the first login.
You also have the option to specify MFA (will post a separate blog on this topic)
Now go back to the IAM Dashboard and you will see a section like this.
This is the IAM user sign-in link. You can click customize and replace the number in the URL to some alias (your organization name). And this URL should be used by IAM users including the admin in order to access AWS web console.

Root user account and the global sign-in URL should be untouched unless a specific requirement.

Azure Blob Storage Data Security

Posted on April 19, 2015 by Thuru

The question of security and cloud computing is one of the very well argued discussed and debated topic. It’s also one of the very common question I get in my sessions.

What ever said and done I personally believe that talking about security regardless of in the cloud or not it has 2 major characteristics.

Security is a policy based feature
Security is a shared responsibility

Ok, leaving the arguments of security, let’s jump into the Azure blob storage data security.

What would be the concerns of data security in Azure Blob storage

How much secure the Azure data centers are ?
What is the security for the data in transit ?
Does Microsoft look or access my data stored in Azure Blob ?
What are the policies should I follow in order to store data securely in Azure Blob ?

Let’s discuss each point one by one

How much secure the Azure data centers are ?

If you’re concerned that Azure data centers aren’t secured enough that physical security breach easily be possible, then you are not going to use the Azure in the first place. And there are tons of articles and videos in the Internet explaining the data center security features of Microsoft Azure.

What is the security for the data in transit ?

All the communications with the Azure and also within different data centers in Azure happen via https so it’s secured via TLS. There are some services which can be accessed (blob service included) with the http but by default this is turned off and it is not recommended to turn it on unless specifically required.

Does Microsoft look or access my data stored in Azure Blob ?

The direct answer from Microsoft is No, and indeed it’s true to my knowledge. But as per in the agreement Microsoft might collect the telemetry data of your blob storage in terms of billing, usage patterns and service improvement parameters.

What are the policies should I follow in order to store data securely in Azure Blob ?

All your cooperate policies that you apply on premise and also additional policies that you have defined in your organization to store the data outside the cooperate firewall should be applied when using Azure Blob storage. But this is very unique and different to each company.

With all that information Why do you need to encrypt the data at rest from any public cloud provider ?

This is a question I ask from the customers when they request me to encrypt the data. Of course there’re several reasons mostly it is due to the cooperate policies which state any data at rest outside the cooperate firewall should be encrypted and also there’re cooperate policies that define the data should be in a specific political and geographic boundary. This is another concern in architecting the applications and selecting appropriate redundancy policies.

Other than the above reasons some customer have complained that we want to protect the data from our public cloud service provider, and prevent them reading the data. This is acceptable for some extent but again this raises plenty of other arguments like how and where to keep the encryption keys and how to secure them.

Encrypting data at rest in Azure Blob Storage

Azure blob storage does not provide any inbuilt mechanisms to encrypt the data at rest. We have to handle this in our application.

First selection of the encryption is very important. Since we’re talking about encrypting the data at rest symmetric encryption serves the purpose well, we do not need to put asymmetric encryption and overwhelm the situation.

Second where to keep the private keys – In most of the application design scenarios keeping the private keys in a database either encrypted or unencrypted format is a common practice. If you’re encrypting your private keys then you should have a master key. You can design your own key management policy for you application or use Azure Key Vault for the key management which is still in preview. One of the concerns I’ve been researching is having an algorithm as a master key which can create master keys for given parameters and handles master key expiration policies this will help us from the problems of persisting keys. (will write another separate post about this)

Third we should be aware when and how to apply the encryption – As the best practice always encrypt and decrypt the memory streams of your blobs. So you ensure that data is encrypted before hitting the disk.

In a web application encryption and decryption happens in the web server. The following diagram explains a scenario where there’s a web app and a blob storage in place and how encryption/decryption happens for the data at rest.

Azure encryption extensions is a great library (https://github.com/stefangordon/azure-encryption-extensions)

Nuget – Install-Package AzureEncryptionExtensions

Performing the encryption and decryption in the stream helps to protect the data before it hits the disk. See the code below.

You can access the sample code with Web API service for upload and download content to Azure blob storage with symmetric encryption from my git repo

https://github.com/thuru/azurestorageencryptionsample

Azure Account Management

Posted on January 30, 2015 by Thuru

This post explains about how an Azure account is managed, what are the different administrative roles , what they do in managing Azure subscriptions, and how Azure Active Directory (AAD) is connected in managing Azure accounts and subscriptions.

An Azure account is simply a container for managing subscriptions. All the services we use in Azure are contained in a subscription. One Azure account can have multiple subscriptions. Consider the below scenario to understand the concept.

I have marked few important rules, which I consider the rule of thumbs to remember in Azure account administration.

Azure Account

There are several ways that you can get access to Azure, you can start a free trial, you might get Azure credits from any of the enterprise licenses your company has with Microsoft or through any other non-documented or unclarified methods.

But let’s begin the story in a more simpler and practical way. Assume Bob wants to learn Azure and wanted to buy an Azure account. Bob entered his credit card detail and activated the Azure account, during this registration process Bob entered his personal email address bob@outlook.com.

Bob got an Azure Account.
Bob created a subscription in order to access Azure services since Azure account is a container for the subscriptions.
Bob named this subscription Dev Subscription.
One Azure account can have multiple subscriptions and each subscription can have different payment options as well.
Since Bob owns the Azure Account he becomes the Service Administrator for the Dev Subscription and also he is the Account Administrator.
Later Bob created another subscription for testing and he named it Test Subscription.
Bob is the Service Administrator for both subscriptions.
Then Bob added Kevin as a Co Administrator in the Dev Subscription using Kevin’s email address kevin@outlook.com.

After the above steps, this is the logical structure of the Bob’s Azure account.

Account Administrator: Account Administrator is the person who owns the Azure account, he is the only person who can manage subscriptions (create, edit, change payment plans).

Service Administrator: Service Administrator has full privileges inside the subscription. One subscription can have only one service admin. He has full rights in managing all the resources and services inside the subscription including adding / removing Co Administrators.

Co Administrator: Co Administrators have full rights in managing resources and services inside a subscription, except they cannot manage users, meaning they cannot manage other Co admins or Service admins.

Read this link for detailed information about the above administrator roles.

Rule #1

In order to login to Azure, a user should be either a Service Administrator or a Co Administrator of the subscription.

As you see Kevin is a Co Admin in the Dev Subscription and he has full rights in managing the resources in the Dev Subscription. But he doesn’t see the Test Subscription. Kevin can be an Account Administrator / Service Administrator of some other Azure Account with the same email address. In that case when he logs into the Azure Portal he will see all the subscriptions in the drop down. He can select the subscription he wants to work with. Any programmatic operation requires the subscription Id.

Azure Active Directory and Azure Account Management

Azure Active Directory (AAD) plays a major role in the Azure account management. Even in the scenario explained above, it has a big part though the process is totally transparent. This is where I put the second rule in.

Rule #2

In order to authenticate to Azure you need Azure Active Directory authentication, in the other terms Azure only trusts the Azure Active Directory authentications.

In the above example Bob and Kevin has no knowledge about AAD, they simply added their personal Microsoft email addresses and everything works.

Bob or Kevin logs into Azure portal using their personal Microsoft email addresses (bob@outlook.com / kevin@outlook.com). Technically they use the Microsoft email authentication to access Azure. This is a huge contradiction to the rule #2.

Answer is very simple, in order to make sure the customer experience smooth and non-cumbersome Microsoft has taken efforts that Azure Active Directory trusts the Microsoft consumer authentication tokens.

So when Bob / Kevin is authenticated via their consumer authentication credentials, the token is passed to the AAD, which trusts the consumer identity token and authenticates them to the Azure portal.

Azure automatically adds Service administrators and Co Administrators to the Azure Active Directory associated with the subscription.

Consider the below cases for the detailed clarification.

Service Administrator is a member and the Global Administrator of AAD

There’s a Service Administrator and he’s a member of AAD as well. The first image shows the Administrators section of the settings page and the second image shows the AAD users section. Azure has added the Service Administrator automatically in the AAD as a user, typically with the Global Administrator permission for the AAD.

Co Administrators are automatically added to the AAD with user roles

Now I want to add a Co Administrator to this subscription. When you click the Add button in the portal you will get a window with this message on top.

As you see the message is very clear. It is the combination of rule #1 and 2.

When you add a user with Microsoft account and add him / her as Co Administrator he / she will automatically be added to the AAD users. The first image shows the Administrators sections of the settings page and the second image shows the AAD users section.

AAD can have the following sources.

Microsoft Account
Azure Active Directory Account
Local Active Directory Account – when a local AD is synced with AAD

We were unable to find any subscriptions associated with your account.

The above is a very common message people get with the image below.

The reason is when you add a Co Administrator the user is added to the AAD, but when you remove a Co Administrator the user in the AAD remains undeleted. Because the user might have some other apps he/she has been accessing using AAD credentials.

In this case if the user tries to access the Azure portal they will get this message. Because here the rule #2 is true but rule #1 is false.

Azure Account Management Best Practices

It is highly recommended not to use Microsoft consumer identities especially the root accounts to access the Azure portal for the day to day tasks. In our case study bob@outlook.com is the root account. Always create a AAD users with specific roles and use them for development purposes.

How to create a certificate authentication with Azure Management Service

Posted on September 26, 2014 by Thuru

In order to carry out any management tasks in Azure using an agent (Visual Studio or any custom code), it should authenticate itself with Azure. Requests to the Azure Management API should be authenticated using on of the following methods.

Active Directory
Certificate Authentication

This article covers the certificate authentication. Azure Management Service (AMS) APIs require a X.509 certificate for the authentication. For the development purpose we can create a sample certificate in our machine using the following command line. Make sure you open the Visual Studio command line in administrator mode to execute this.

makecert -sky exchange -r -n "CN=<CertificateName>" -pe -a sha1 -len 2048 -ss My "<CertificateName>.cer"

This creates the certificate in the local machine under the Personal Certificates since I have specified “My”as location.

Open the Certificate Manager in your local machine (enter certmgr.msc in the Run). You can check for your new certificate.

We should upload this certificate to Azure to establish the trust and each and every API request should contain the certificate. Certificates are saved in Azure under subscriptions thus they are used to manage the subscription owner actions. Each subscription can contain up to 100 certificates as of this writing.

Export the certificate from certificate store, as a .cer file. Follow the screen shots below.

Once you have exported the certificate, next step is to upload it to the Azure subscription. Login to the Azure select the correct directory if you more than one under your login and select the correct subscription to which you need to upload the certificate. Then go Settings and go to Management Certificates tab, there you can upload your certificate.

After uploading the certificate you can view it in grid like this.

To summarize what we’ve done up to now,

We need establish a trust between Azure and the subscription agent via certificate authentication.
Subscription agent is the party / tool which programmatically carries our the tasks of a subscription owner.
First we generated a local certificate using certmgr.msc
We exported the certificate and put it in the Azure management certification store.
So now any subscription agent with the certificate can perform the subscription ownership tasks (using Azure Management API) thus authenticating using the certificate.

The below C# code shows how to retrieve the certificate from your local store by providing the thumbprint.

public X509Certificate2 GetStoreCertificate(string thumbprint)
{
    List<StoreLocation> locations = new List<StoreLocation>
    {
        StoreLocation.CurrentUser,
        StoreLocation.LocalMachine
    };

    foreach (var location in locations)
    {
        X509Store store = new X509Store("My", location);
        try
        {
            store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);
            X509Certificate2Collection certificates = store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint,false);

            if (certificates.Count == 1)
            {
                return certificates[0];
            }
        }
        finally
        {
            store.Close();
        }
    }

    throw new ApplicationException("No Certificate found");
}

The above code tries to get the certificate from the Personal certification location, as the parameter “My” has been passed to the X509Store constructor.

After obtaining the certificate, you should pass it through each and every Azure Management API request whether you use the REST API or any language SDK.

Versatile Digital DNA

Category Archives: Cloud Security

Azure Account Management

How to create a certificate authentication with Azure Management Service

Creating Multi-Tenant Applications

Local AD synced with Azure Active Directory with passwords

Local AD is federated using ADFS

Tenant Customization

Share this:

Share this:

Introduction

Provisioning Azure Key Vault

Usage

Useful links

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: