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/.
Mijn eigen test site http://cloudtest.marcelmeijer.net maakt hier gebruik van.
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.
Via het Claims mechanisme van ACS krijgen we dan enkele gegevens terug. Die kunnen we dan weer gebruiken in onze applicaties etc.
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.
En via de SDK kun je graph en dus de gegevens van deze Active directory opvragen en gebruiken. Super!
En ik kan gebruikers toevoegen.
De gebruiker krijgt dan een mailje met een tijdelijk wachtwoord.
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.
Aan de Cloud AD kun je dan applicaties toevoegen.
Dit is helemaal top. Ik kom later terug met een meer uitgewerkt voorbeeld van de werkelijke toepassing.