Windows Azure Free Trail

Omdat ik een Windows Azure account wilde koppelen aan mijn bestaande Office 365 account, heb ik een nieuw Windows Azure account gestart. In deze blogpost neem ik jullie stap voor stap door het aanmeld proces heen. Je kunt zonder risico starten met Windows Azure, als je over het gratis gebruik heen gaat dan stopt het allemaal vanzelf.

De eerste stap die je moet nemen, ga naar: https://www.windowsazure.com/nl-nl/pricing/free-trial/.

 waproef02

Als je op “nu kopen” klikt, dan krijg je dit scherm.

waproef01

Ik ga even van Prive gebruik uit. Dat betekent, dat we eventueel later willen betalen voor wat we echt gebruiken en niet dat we vooraf capaciteit inkopen. Het inkopen van Windows Azure capaciteit kan erg interessant zijn voor bedrijven of startups, die weten hoeveel capaciteit ze minimaal verstoken. Je krijgt dan wel een korting. Het principe is gelijk aan wat Telecom aanbieders doen. Als je een bel-bundel koopt, dan zijn de tikken binnen je bel-bundel goedkoper dan er buiten.

Je moet je dan aanmelden met je Microsoft Account. Aangezien ik mijn Windows Azure Free Trial wilde koppelen aan mijn Office 365 account, kies ik daar niet voor. Het vervolg na deze stap is voor beide gelijk.

waproef03

Ik krijg nu het inlog scherm van Office 365.

waproef04

Als ik dan ingelogd heb met mijn Office 365 account, dan krijg ik het volgende te zien. Ik heb inderdaad nog geen abonnementen, dat is het doel van deze actie  😉 Maar als je al een Free Trail actief hebt, dan kun je er niet nog een aanvragen. Je zult dan of je Free Trail moeten stop zetten of subscription kopen.

 waproef05

Na het klikken op de “Meld u aan” link, gaan we lekker verder.

 waproef06

We moeten een mobiel nummer opgeven. Daarmee wordt gecontroleerd dat er niet een vreemde robot of zo allerhande free trails gaat aanmaken.

 waproef07

Je krijgt dan een SMS met een code. Deze moet je op de site invoeren.

 waproef08

 waproef09

Daarna zullen we Credit card gegevens en adresgegevens moeten opvoeren. Via een faktuur betalen kan tegenwoordig ook, maar dan alleen als je kiest voor de bundel varianten.

 waproef10

Na het klikken op volgende, wordt je subscription aangemaakt.

 waproef11

En je bent de gelukkige eigenaar van een mooie Windows Azure subscription. Anders gezegd je computerkracht en diskruimte is nu onbeperkt!

 waproef12

Als je dan op knop Rechtsboven (Portal) klikt, dan ga je naar de Windows Azure managment portal. Je doorloopt dan de welkoms wizard, die bekend maakt met alle vernuftige dingen in de portal.

 waproef13 waproef14 waproef15 waproef16 waproef17

En we krijgen de Management portal te zien!

 waproef18

Zoals je ziet is de Active Directory van je Office 365 account gelijk toegevoegd. Met alle gebruikers van het Office 365 account. Daarover later nog veel meer.

 waproef19

Als je nu naar het Billing menu gaat. Klik daarvoor op je e-mail adres bovenaan en kies voor “Show my bill”. Dan zie je dat je subscription een vreemde naam heeft. Deze kun je aanpassen.

 waproef20

Klik dan op de witte regel met “Gratis proefversie van 3 maanden”. Er verschijnt dan een overzicht van je verbruik en er staan een aantal opties. Een daarvan is “Uw abonnement bewerken”.

 waproef21

Mocht je niet meer van je subscription af willen (wat ik mij prima kan voorstellen 😉 ), dan klik je op gele regel.

 waproef22

Heel veel plezier met je Windows Azure subscription. Laat je gedachten de vrije loop en creeer mooie nieuwe toepassingen op het Windows Azure platform.

WAAD – Integrate with Web App

In mijn vorige blogpost over Windows Azure Active Directory liet ik onderstaande scherm al zien. Ik vertelde toen dat ik hier op terug zou komen.

waad01

Als je de Wizard volgt en invult, dan ratelt het even en zal onderstaande verschijnen. Je heb je Website gekoppeld aan je Active directory.

waad02

De Federation Metadata document URL heb je straks nodig in Visual Studio.

 waad03

 waad04

Aan de naamgeving zag je al dat ik niet heel veel gedaan heb 😉 Ik heb Visual Studio gestart en File –> New Project gedaan. Daarna gekozen voor mijn personal Favoriet een MVC 4 website. Vervolgens doe je op de Web application portal een rechter muis klik. Je kiest dan voor ‘Identity and Access’.

 waad07

Je kiest voor de tweede optie en kopieert de Federation Metadata URL van de portal hierin.

 waad08

Daarna is het F5 in Visual Studio. Je web applicatie runt en toont een login scherm.

 waad09

Als je dan vervolgens inlogt met een gebruiker van je AD, dan krijgt die gebruiker toegang tot je geweldige applicatie.

 waad10

Hoe gaaf is dat! Dit biedt absoluut nieuwe mogelijkheden en super toepassingen voor vele bedrijven. Dit maakt een Office 365 subscription ineens nog interessanter!

Oke, als je bovenstaande stappen uitvoert, krijg je wel eerst nog deze foutmelding. Er wordt dan geklaagd over de Antiforgery token.

 waad11

 waad12

De oplossing is relatief simpel.

 waad13

Wil je je Office 365 gebruikers de toegang tot de applicatie ontnemen. Dan klik je op dit menu.

 waad05

Kiest voor de Remove app keuze.

 waad06

En de gebruikers krijgen deze fijne foutmelding.

waad14

Anyway, hoe gaaf is dit. En dan heb ik je nog niet laten zien, dat ik door middel van de WAAD Graph API toegang kan krijgen tot de informatie van deze Active directory. Waarmee je dan ook nog eens beslissingen in je app kunt maken. Maar daarover in een volgende blogpost maar meer 😉

Windows Azure Active Directory (WAAD)

Het grote nadeel van Webapplicaties in de Cloud ten opzichte van Intranet applicaties is de beschikbaarheid van Active directory. Een van de oplossingen is natuurlijk om gebruik te maken van social networks (zoals Google, FaceBook, Twitter, Yahoo, Windows Live) om de gebruiker te valideren.

Maar dan weet je wel dat degene die zich aanmeldt degene is die hij zegt dat ie is, maar autorisatie moet je nog steeds zelf beheren. Dat is lastig, want zo heb je nog steeds geen echte controle. Zeker als je gebruikers medewerkers van je bedrijf zijn, dan wil je dat ze inloggen met een corporate account natuurlijk.

Maar als modern bedrijf maak je natuurlijk gebruik van Office 365 (Microsoft’s SAAS oplossing voor Office, Exchange en SharePoint in de Cloud). De medewerkers hebben dan een account en zou het niet mooi zijn om dat account te kunnen gebruiken in je Webapplicatie.

Op de Windows Azure portal hebben we al een Active Directory menu item. Daarachter zit het reeds bekende Windows Azure Access Control. Via dit mechanisme kun je via de bekende social networks (Google, FaceBook, Yahoo en Windows Live) mensen authentiseren. Meer info heb ik al eerder beschreven op dit blog: http://blog.marcelmeijer.net/2011/07/06/windows-azure-appfabric-acs-met-meerdere-instanties/ en http://blog.marcelmeijer.net/2012/05/04/windows-azure-wif-access-control-acs/.

clip_image001

clip_image003

Mijn eigen test site http://cloudtest.marcelmeijer.net maakt hier gebruik van.

clip_image005

Maar waar deze site ook gebruik van maakt, is Office 365 als authenticatie provider. Met mijn Office 365 account op het Joep-IT domein kan ik inloggen op de site.

clip_image006

Via het Claims mechanisme van ACS krijgen we dan enkele gegevens terug. Die kunnen we dan weer gebruiken in onze applicaties etc.

clip_image008

Dit klinkt allemaal wel goed, maar dat is nog steeds niet het echte Active directory. Bij Active directory willen we users maken en deze users gegevens en rollen geven. Dat willen we dan gebruiken.

Sinds kort is een op Office 365 gebaseerde Active Directory beschikbaar gekomen. We kunnen een Directory maken, op dit moment alleen nog op een nieuwe <name>.onmicrosoft.com Office 365 account. Het is de bedoeling dat ik hier later ook mijn bestaande Joep-IT Office 365 account kan gebruiken.

clip_image009

clip_image011

clip_image013

En via de SDK kun je graph en dus de gegevens van deze Active directory opvragen en gebruiken. Super!

En ik kan gebruikers toevoegen.

clip_image015

De gebruiker krijgt dan een mailje met een tijdelijk wachtwoord.

clip_image017

Maar wat als je nu een on-premise Active directory hebt, moet je dan dingen dubbel doen? Voor ACS hebben we al AD-FS (Active Directory Federation Services). Daarmee kun je de gebruikers van je locale AD naar de Cloud halen. Deze oplossing is niet helemaal optimaal. De ‘nieuwe’ Active directory biedt je mogelijkheden om je on-premise AD te syncen met je Cloud AD.

clip_image019

Aan de Cloud AD kun je dan applicaties toevoegen.

clip_image021

Dit is helemaal top. Ik kom later terug met een meer uitgewerkt voorbeeld van de werkelijke toepassing.

Windows Azure + WIF + Access Control (ACS)

Als je gebruik gaat maken van de Access Control Service (ACS) op het Windows Azure platform, dan zijn er voldoende websites te vinden met een keurig stappenplan. Bijvoorbeeld hier. Hoewel er behoorlijk geconfigureerd moet worden, zowel in de applicatie als op de ACS website, is het goed te doen.

Als je vervolgens de gebouwde Windows Azure applicatie ook daadwerkelijk in de Cloud gaat laten draaien zijn er een aantal aha momenten. Hieronder een opsomming.

Het is wel handig om de website als SSL te maken.

1) De Windows Identity Foundation (WIF) runtime.

Op de standaard Windows Azure instances is de WIF runtime niet aanwezig. Uit verschillende discussie die ik gevolgd heb en eigen ervaring, blijkt dat een simpel ‘copy local’ van de WIF assembly (Windows.Identity.dll) niet voldoende. Je zult echt de WIF runtime moeten mee installeren met de installatie van de Windows Azure web applicatie.

Dat is relatief eenvoudig. Met behulp van het startup task mechanisme van Windows Azure kun je een batch file af starten en daarmee de runtime installeren. Deze runtime is te downloaden van hier. Er is zowel een x86 als x64 versie beschikbaar. De x64 heb je nodig voor het deployen naar Windows Azure. Afhankelijk van de gekozen OS Family (Windows 2008 of Windows 2008 R2) heb je de 6.0 of de 6.1 nodig. Ontwikkel je lokaal op Windows 7 of Windows 2008 R2 dan heb je ook 6.1 nodig.

In de ServiceDefinition.csdef van de WebRole voeg je het volgende stuk toe.  

   1:  <Startup>
   2:    <Task commandLine="startup.cmd" 
   3:               executionContext="elevated" 
   4:               taskType="simple">   
   5:    </Task>
   6:  </Startup>

Aan het webproject voeg je dan een file met de naam startup.cmd toe. Het makkelijkst is dat om in de root te doen. Anders moet je in de stap hierboven ook het path aangeven.

De startup.cmd bevat dan:
 

   1:  REM WIF assembly 
   2:  sc config wuauserv start= demand 
   3:  wusa.exe "%~dp0Windows6.1-KB974405-x64.msu" /quiet /norestart
   4:  rem wusa.exe "%~dp0Windows6.0-KB974405-x64.msu" /quiet /norestart 
   5:  sc config wuauserv start= disabled

Bij het deployen van de applicatie wordt in een van de stappen ook de startup task uitgevoerd.

2) Multiple instances

Zoals bekend moet je op Windows Azure om aan de SLA te voldoen in elk geval 2 instanties van je Role starten. Van Windows Azure ACS krijg je een cookie. Deze cookie wordt geencryptd en gedecryptd.

Deze versleuteling vindt plaats met de machine-sleutel van de instantie waar je zat. Maar op de andere instantie is de machine-sleutel natuurlijk anders en dan kan het cookie niet gelezen worden door een andere instantie.

De oplossing is dan ook vrij simpel, zorg ervoor dat de versleuteling plaats vind met voor alle machines een gelijke sleutel. Ik heb voor mijn domein een SSL certificaat gekocht en deze kan ik daar mooi voor gebruiken. Om dit goed te laten verlopen moet je in de Global.asax.cs de FederatedAuthentication.ServiceConfigurationCreated methode toevoegen.

   1:  protected void Application_Start()   
   2:  {   
   3:      AreaRegistration.RegisterAllAreas();   
   4:  
   5:      FederatedAuthentication.ServiceConfigurationCreated 
   6:             += OnServiceConfigurationCreated;   
   7:  }   
   8:   
   9:  void OnServiceConfigurationCreated(object sender, 
  10:                        ServiceConfigurationCreatedEventArgs e)   
  11:  {  
  12:      // Use the <serviceCertificate> to protect the cookies 
  13:      // that are sent to the client.  
  14:      // so multiple roles do the same.  
  15:      if (e.ServiceConfiguration.ServiceCertificate == null)  
  16:         return;  
  17:   
  18:      Trace.WriteLine("ServiceCertif: ", 
  19:                 e.ServiceConfiguration.ServiceCertificate.Thumbprint);  
  20:      List<CookieTransform> sessionTransforms =  
  21:          new List<CookieTransform>(  
  22:              new CookieTransform[] {  
  23:                  new DeflateCookieTransform(),
  24:                  new RsaEncryptionCookieTransform
  25:                         (e.ServiceConfiguration.ServiceCertificate),  
  26:                  new RsaSignatureCookieTransform
  27:                         (e.ServiceConfiguration.ServiceCertificate)   
  28:              }  
  29:          );  
  30:   
  31:      SessionSecurityTokenHandler sessionHandler =   
  32:         new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());  
  33:   
  34:      e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(
  35:                 sessionHandler
  36:      );  
  37:  }

3) Realm

Op mijn demo site zijn alle pagina’s zichtbaar zonder in te loggen, maar mag je secret page pas benaderen na inloggen. In de default situatie na het doorlopen van de wizard zullen alle pagina’s niet benaderbaar zijn zonder in te loggen. Ik heb daarom dit gedeelte in de web.config uit gecommentarieerd.

   1:  <system.web>
   2:      <!--
   3:      <authorization>
   4:        <deny users="?" />
   5:      </authorization>
   6:      -->

Op de ACS portal heb ik de return URL laten verwijzen naar de pagina die bij mij geheim is.

acs3

Dat is deze pagina in de app.

acs2

ACS implementeren is eigenlijk heel makkelijk, maar toch weer heel lastig. Er zijn veel knoppen waar je aan moet draaien om het goed te laten werken.

Ander dingetje wat je je moet realiseren. Het Access Control mechanisme zoals Windows Azure die aanbiedt bestaat voor het grootste gedeelte uit alleen de authenticatie. Weet je het nog Authenticatie, ben jij degene die je zegt dat je bent; Autorisatie, wat mag jij of welke rollen heb jij op deze website / webapplicatie. Wat je met ACS uit handen geeft is de authenticatie. Door middel van de login/password bij een van de Identity providers.

acs1

De autorisatie moet je zelf uitwerken in je eigen website of webapplicatie. De claims die je van de identity providers terugkrijgt zijn tokens (alleen FaceBook), e-mail adressen (niet bij Windows Live), Name (niet bij Windows Live) en een nameidentifier. De nameidentifier kun je wel gebruiken als key voor je rollen toekenningen systeem. En zoals je voorgaande leest, wil je bij Windows Live zelf vragen om e-mail adres en name (of je gaat met de nameidentifier zelf te raden bij Windows Live wat natuurlijk ook kan).

Veel plezier met WIF, ACS en Windows Azure. Wil je mijn web.config bekijken, mail mij (marcelmeijer @ planet.nl) dan. Mijn demo site is https://cloudtest.marcelmeijer.net .

VS11 Beta + WIF

Met het uitkomen van Visual Studio 11 Beta is er ook een update gekomen van de Windows Identity Foundation (WIF) tools. De precieze details kun je natuurlijk beter verteld krijgen door Kaptein Identity (Vittorio Bertocci). Voor de Cloud cover aflevering zie http://blogs.msdn.com/b/vbertocci/archive/2012/03/16/the-wif-tools-for-visual-studio-11-beta-on-cloudcover.aspx

Maar ik heb er ook eens mee zitten spelen en het ziet er heel goed uit. Schreef ik in mijn vorige blogpost over ACS nog dat het veel configureren en draaien aan knoppen was, met deze toevoeging is dat toch nog simpelere geworden.

Aangezien er nog een Visual Studio 11 tools for Windows Azure zijn, zullen de komende schermprints betrekking hebben op een gewone Website.

clip_image002

In het context menu van een Webproject zit nu een menu item ‘Identity and Access’. Het startpunt om de Access control van je Website in te regelen. Na de keuze verschijnt er een scherm met een beperkt aantal keuzes.

clip_image003

Zo kun je kiezen voor een local development STS, ADFS2 of ACS. Op de twee andere tabbladen kun je dan de settings doen, die voor de gekozen provider van belang zijn. De inhoud van deze tabbladen is context gevoelig.

De local development STS hebben we node gemist in al onze WIF ontwikkeltrajecten. Als je deze kiest en je gaat naar het derde tabblad, dan zie je daar de waarden die de STS terug geeft aan je applicatie. Nu kun je je Website beter testen met de verschillende claims.

clip_image005 clip_image006

Als je de Website start in VS11, dan verschijnt er in de taskbar een LocalSTS tool.

clip_image007

En op je website zal het Login control keurig de naam laten zien uit het derde tabblad.

clip_image008

Ik heb (nog) geen ADFS2 omgeving tot mijn beschikking. Dus dat kan ik helaas niet verder laten zien. Maar wel een Windows Azure ACS omgeving en dat is al even makkelijk. Je geeft je ACS account gegevens op (namespace en management key). Vervolgens selecteer je welke Identity providers voor jouw applicatie relevant zijn. NB deze moet je wel eerst zelf hebben toegevoegd op de ACS administration page.

clip_image009 clip_image010

Nadat je OK geklikt hebt, ratelt er iets en zul je zien dat de web.config ineens allerlei verwijzingen naar je ACS bevat.

clip_image011

En als je runt, krijg je wat je verwacht.

clip_image012clip_image013

Op de ACS management portal zijn ook automatisch een aantal zaken aangepast en toegevoegd.

clip_image014

Geweldig toch! Oke, eea is nog niet helemaal compleet, want SSL kan nog niet via de schermen en er zullen vast nog meer dingen missen. Maar de richting is gezet en het ziet er goed uit.