Terwijl ik dit schrijf, is Microsoft hard aan het werk om de transitie van de Azure Service Management (ASM) API’s naar de Azure Resource Management (ARM) API’s af te ronden. Beide API’s bieden de mogelijkheid om je Azure resources te beheren en zijn de REST API’s achter Azure Powershell en de Azure portal.

De oudere, ASM API wordt niet voor niks vervangen. Het grote nadeel van deze API is, dat hij niet de mogelijkheid biedt tot fine-grained autorisaties. De enige manier om toegang tot resources te beheren is op het niveau van de subscription. Je kunt niet per resource bepalen wie waar bij mag. In elke organisatie met meer dan een paar resources is dit volledig onacceptabel.

De ARM API is op dit punt een grote stap vooruit. Met ARM kun je Azure Service Management (ASM) APIs to the per resource bepalen wie er bij kan en zelfs regelen wat men precies mag.

Maar dat is niet alles. Naast personen zijn er soms ook applicaties of systemen die toegang nodig hebben tot een of meer Azure resources. Via ASM kon dit door het gebruik van zogenaamde management certificates. De houder van zo’n certificaat had dan volledige controle over een subscription. Met ARM is het mogelijk om ook applicaties gericht toegang te geven tot een subset van je resources. Het is echter niet erg duidelijk hoe dit werkt. In dit blog zal ik dan ook laten zien hoe je een applicatie toegang kan geven tot Azure resources volgnes het principle of least privilege. Voor autorisatie zal ik daarvoor gebruik maken van certificaten, een veiligere methodiek dan wachtwoorden.

Iedereen die, via ARM, toegang tot een subscription heeft moet bekend zijn in de Azure Active Directory (AAD) die bij die subscription hoort. Dit geld niet alleen voor personen, maar ook voor applicaties. Het registreren van een applicatie in de AAD kan helaas nog niet in de nieuwe portal. We moeten dus terug naar de oude portal of gebruik maken van Powershell. Nadat de applicatie geregistreerd is in de AAD, moet deze ook nog geautoriseerd worden op een resourcegroup. Dit kan echter weer alleen in de nieuwe portal of via Powershell. Om die reden kies ik voor Powershell zodat ik niet heen en weer hoef tussen portals.

Om verbinding te maken met de AAD vanuit Powershell is er een specifieke Powershell module (MSOL) nodig, die je hier vindt.

Allereerst registreren we de applicatie:

> # Connect to your active directory
> Connect-MsolService

> #Create the application
> New-MsolServicePrincipal -DisplayName YourApplication
The following symmetric key was created as one was not supplied r...k=

DisplayName : YourApplication
ServicePrincipalNames : {f...1}
ObjectId : c...f
AppPrincipalId : f...1
TrustedForDelegation : False
AccountEnabled : True
Addresses : {}
KeyType : Symmetric
KeyId : 2...4
StartDate : 18-10-2015 15:13:31
EndDate : 18-10-2016 15:13:31
Usage : Verify
> # We will need that AppPrincipalId later, so keep it for reference

> # However, first we remove that Symmetric key we do not need
> # First we find its KeyId
> Get-MsolServicePrincipalCredential -AppPrincipalId f...1
cmdlet Get-MsolServicePrincipalCredential at command pipeline position 1
Supply values for the following parameters:
ReturnKeyValues: 

Type : Symmetric
Value : 
KeyId : 2...4
StartDate : 18-10-2015 15:13:31
EndDate : 18-10-2016 15:13:31
Usage : Verify 

> # Now remove it providing again the ApplicationId and the KeyId.
> # The KeyIds parameter takes an array, hence the parentheses
> Remove-MsolServicePrincipalCredential -AppPrincipalId f...1 -KeyIds ("2...4")

Nu voegen we authenticatie op basis van een certificaat toe:

> # Let's grab the certificate from filesystem and transform it to Base64
> $certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate 
> $certificate.Import("c:\...\YourApplication.cer")
> $binaryCertificate = $certificate.GetRawCertData() 
> $base64Certificate = [System.Convert]::ToBase64String($binaryCertificate);

> # Register the certificate as the applications credential
> New-MsolServicePrincipalCredential -AppPrincipalId "f...1" -Type asymmetric -Value $base64Certificate -Usage verify

Tenslotte moeten we de applicatie rechten geven op een resource. Voor dit doel heb ik een resourcegroup ‘poc’ aangemaakt:

> # Every resource under ARM is defined by an URL
> $scope = "/subscriptions/4...f/resourceGroups/poc"

> # Contributor is a pre-assigned role that includes every right, except GRANTS
> New-AzureRoleAssignment -ServicePrincipalName "f...1" -RoleDefinitionName Contributor -Scope $scope

De applicatie schrijven

Nu dat we een applicatie in de AAD geregistreerd hebben, kunnen we de applicatie zelf schrijven. Hieronder vind je een minimaal voorbeeld voor authenticatie en het opvragen van een lijst van alle storage accounts in een rsource group:

var subscriptionId = "4...f"; // The guid assigned to your subscription. If you don't have it, use Get-AzureSubscription
var tenantId = "4...f"; // The guid assigned to your AAD Tenant. If you don't have it, use Get-AzureSubscription
var aadEndpoint = $"https://login.windows.net/{tenantId}";
var clientId = "f...1"; // Again, AppPrincipleId
var certificateThumbprint = "b...a"
var armLocation = "https://management.azure.com/"

var context = new AuthenticationContext(aadEndpoint);
var certificate = GetARMCertificate(certificateThumbprint);
var credentials = new ClientAssertionCertificate(clientId, certificate);
var loginResult = context.AcquireToken(armLocation, credentials);
var token = new TokenCloudCredentials(subscriptionId, loginResult.AccessToken);
var managementClient = new StorageManagementClient(token);

var accounts = managementClient.StorageAccounts.List();

Er zijn twee NuGET packages die je moet installeren om deze code te draaien: Microsoft.IdentityModel.Clients.ActiveDirectory and Microsoft.Azure.Management.Storage

En hier het eindresultaat: Een overzicht van alle storage accounts in de resource group. Andere acties, zoals het toevoegen of verwijderen van storage accounts zijn natuurlijk ook mogelijk..

ARMCertificateAuth

Gisteravond heb ik bij SnelStart een korte presentatie gegeven over het State Pattern. Wat is het, waar gebruiken we het voor en waarom?

Als we naar een pattern kijken als een ‘type oplossing, voor een type probleem’ dan is het niet alleen belangrijk om het probleem dat een pattern oplost te kennen, maar ook te kunnen herkennen. Kennen: Het state pattern is de oplossing voor het type probleem waarbij we een class hebben die, afhankelijk van de state waarin hij verkeerd, ander gedrag moet vertonen bij het aanroepen van zijn methoden. Herkennen: De naïeve oplossing voor dit type probleem is het introduceren van een enumeratie en in elke methode een switch/case statement om de juiste code uit te voeren. Aan deze combinatie kun je een goede kandidaat voor gebruik van het state pattern gelijk herkennen.

Natuurlijk blijft dan nog de vraag over waarom het gebruik van het state pattern beter is dan die naïeve implementatie. Er zijn tal van argumenten te noemen, maar de belangrijkste voor mij zijn testbaarheid en onderhoudbaarheid. Een implementatie op basis van polymorfisme in plaats van een aantal conditionele switches, verminderd bijna altijd het aantal testgevallen dat je moet vangen in je unit tests. Daarnaast, onderhoudbaarheid: Bedenk wat er gebeurd wanneer iemand een state-enumeratie uitbreidt met een nieuwe waarde en een switch/case statement vergeet aan te passen. Je programma compileert, je testen draaien nog en toch zit er waarschijnlijk een grote bug in je programma. Met een state pattern heb je dit niet omdat je compiler je dwingt om de nieuwe state volledig te implementeren.

Maar wat is het state pattern dan precies? Een state pattern kenmerkt zich door een outer class die zelf geen gedrag implementeert, maar alle aanroepen delegeert naar een inner class die de huidige staat van de outer class omschrijft. Een voorbeeld in UML zie je hieronder.

StatePattern

State pattern in UML. We zien hier een Order class die een aantal methoden adverteert. Elke aanroep is echter een delegatie naar de abstracte OrderState class. De overervingen van deze class zorgen voor het juiste gedrag in elke staat waarin de order zich kan bevinden.

Nu zegt een plaatje meer dan duizend woroden, maar is code nog veel mooier. Hier kun je een visual studio C# solution met vier projecten downloaden met een gedetaileerde implementatie van het state pattern en een stap-voor-stap refactoring hier naar toe vanaf een naïeve implementatie.

Een van de eerste uitdagingen die ik tegenkwam toen ik begon te ontwikkelen op een Windows machine, was het creëren van een valide SSL certificaat. Er zijn veel handleidingen te vinden die je van alles met IIS laten doen of via allerlei hoepels self signed certificaten laten genereren. Uiteindelijk ben ik toch teruggevallen op wat me zo beviel onder Linux: de command line.

Omdat het mijn doel was een om echt geldig certificaat te krijgen, moest ik eerst een CSR (certificate sign request) genereren om te kunnen opsturen naar een certificate authority zodat ik een geldig certificaat krijg. Natuurlijk is het mogelijk om een certificaat te bemachtigen zonder eerst een CSR te genereren, maar dat raad ik af.

Een certificaat downloaden zonder CSR

Een certificaat bestaat altijd uit twee delen, het publieke en het privé deel. Het publieke deel kan gebruikt worden om informatie voor de houder van het certificaat te versleutelen, het privé deel om die weer te ontsleutelen. Ten overvloede, dat privé deel moet je dus voor jezelf houden. Wanneer je een volledig certificaat (publiek en privé deel) van een certificate authority krijgt betekend dus dat een of meer mensen het privé deel van je certificaat hebbben (gehad). Als je zelf een CSR genereert, dan genereer je zelf het privé deel en een gedeelte van het publieke deel van je certificaat. Deze informatie gebruikt je certificate authority om het publieke deel van je certificaat te maken. Ze krijgen dus het privé deel nooit te zien als je een CSR gebruikt. Helemaal wanneer je je certificaten bij je leverancier kan downloaden, is het dus verstandig om zelf een CSR te genereren.

Het genereren van een CSR

Zoals gezegd had ik geen zin in gedoe met IIS, domein controllers of allerlei andere onbekende software voor het genereren van een CSR, dus ik heb de OpenSSbinaries voor Windows gebruikt. Je kunt deze vinden op http://indy.fulgan.com/SSL/ of een andere bron opzoeken via www.openssl.org.

Nadat OpenSSL geinstalleerd is, kan een keypair gegeneerd worden. Dit keypair is de basis van een certificaat:

.\openssl.exe genrsa -out .\henrybeen.nl.key 4096

Ik heb gekozen voor een 4096 bit sleutel. Op dit moment zijn er veel tutorials of voorbeelden die een 1024 bit sleutel gebruiken, maar dit is echt te kort. Veel certificate authorities accepteren alleen nog maar CSR’s met een sleutel van 2048 of langer. Deze lengte zal veilig zijn tot ongeveer 2030 verwacht men. De reden dat ik 4096 gebruik, is simpelweg omdat ik kan. Na het genereren van het keypair, kunnen we dit gebruiken om een CSR te generen:

.\openssl.exe req -new -sha256 -key "henrybeen.nl.key" -out "henrybeen.nl.csr" -days 730 -nodes -x509 -subj "/C=NL/ST=xx/L=xx/O=yy/CN=henrybeen.nl"

Dit CSR kunnen we opsturen naar een certificate authority om het publieke deel van het certificaat te ontvangen. Er zijn veel certificate authorities, de enige nog duurder dan andere. Zelf gebuik ik regelmatig StartSSL, welke gratis is voor privé gebruik.

Nu nog automatiseren

Lui als ik ben, wil ik dit natuurlijk niet elke keer met de hand doen, dus ik heb een eenvoudig Powershell script geschreven dat het downloaden van OpenSSL, het genereren van een keypair en CSR automatiseert. Leuk om ook eens aan scripten onder Windows, in Powershell te ruiken. Het is niet bepaald mijn lievelings, maar het werk. Het script is natuurlijk te downloaden en kan als volgt gebruikt worden:

.\GenerateCSR.ps1 -domain henrybeen.nl -countryCode NL -city "xx"-organization "yy"

Wat uiteindelijk twee bestanden oplevert: Het keypair en de CSR