De vorige keer schreef ik een eerste blog over de uitdagingen van een cloudservicebroker. In dit tweede deel een belangrijke eigenschap die niet mag ontbreken bij clouddiensten waarmee een broker werkt; single sign-on.
Bij het ‘go to market’ model van cloud service-providers doen ze graag rechtstreeks zaken met de (eind)gebruiker. Als de consument een dienst eenmaal geïntroduceerd heeft binnen een bedrijf en het gebruik ervan groeit, dan volgt altijd de behoefte naar enige integratie met andere bedrijfssystemen. De schaduw- it (it-diensten die buiten medeweten van de it-afdeling gebruikt worden) moet weer wit worden.
Een voorbeeld van deze intergratiebehoefte is de gebruiker met behulp van single sign-on in te laten loggen op verschillende diensten. Veel diensten met elk een eigen gebruikersnaam en wachtwoord leiden namelijk of tot de keuze van dezelfde gebruikersnaam en wachtwoord bij verschillende diensten, of de keuze van eenvoudige wachtwoorden. Beide opties zijn onwenselijk, want daarmee creëer je een zwakke beveiligingsschakel.
De oplossing is een single sign-on (sso)-infrastructuur. In de b2b-markt zou single sign-on de standaard moeten zijn. Bij federated single sign-on kan een dienst een gebruiker binnen laten die elders geauthentiseerd is. Gartner verwacht dat in 2016 80 procent van de bedrijven de stap zullen hebben gemaakt naar federated single sign-on. Het hoger onderwijs in Nederland loopt hierin voorop door gebruik te maken van Surfconext.
Als cloudservicebroker kan je toegevoegde waarde liggen in het bieden van deze single sign-on-infrastructuur. Het meest gebruikte protocol hiervoor is SAML 2.0.
De uitdaging hierbij is dat veel diensten geen sso ondersteunen. Gelukkig gaan de ontwikkelingen heel hard. Een paar jaar geleden moest ik nog constateren dat minder dan 10 procent van de diensten sso-functionaliteit hadden. Veel service providers hebben sindsdien sso op hun productontwikkel-roadmap gezet.
Ik hoop dat de volgende stap een standaard is op het gebied van provisioning en de-provisioning.
