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.
@Hans Peter
Single Sign On is te implementeren met SAML. Technisch geheel, wat door een expert gedaan kan worden en niet door een eindgebruiker.
Hoe kijk je tegen Single Sign Off aan, waarbij een enkele uitlogactie de toegang naar meerdere applicaties beëindigt?
Dit is nog niet makkelijk te implementeren, gezien de vele bugs die ik bij het testen hiervan heb gevonden bij meerdere klanten.
Apple zet met maverick de eerste stappen in single sign on over apparaten en applicaties heen, single sign on is dan een feature geworden.
Omdat het sign proces steeds meer generiek wordt is single sign on een product dat gaat verdwijnen en uiteindelijk heel normaal gaat worden. Federated wordt ook al vaak toegepast, step up en delegation zijn volgende stappen.
Voor de cloud zijn er ook al standaard toepassingen, dat is een logische stap. okta, one login, Ping indentity en symplyfied hebben allemaal standaard oplossingen met vele connectors, zodat je je om saml niet meer druk hoeft te maken.
In een wereld die draadloos wordt kan dit worden gekoppeld aan 802.1x en je hebt zonder moeizame technische integraties mooie oplossingen. de beveiliging ligt wel geheel bij de gebruiker.
@ Cordney dat is een bekend probleem, een werkbare oplossing (voor ons) staat hier https://blog.surfnet.nl/?p=2570
@Hans-Peter
bedankt, ik ga jullie opl;ossing bestuderen
@Willem Voor diensten die geen sso ondersteunen gebruikt Okta een username/password lijst. Dat vind ik eng. Bij Apple is de vraag of ik mijn online identity bij Apple wil beheren, net als bij login met Facebook of Google account. Ook zit hier een spanningsveld tussen B2B en B2C. Bij B2B zorgt de IT afdeling voor sso.
Hoe breng je een van oorsprong B2C dienst onder in een B2B omgeving? Dat blijft lastig.
je ziet wel vaker dat er zakelijke online diensten zijn waar je met social network-IDs kunt inloggen. Klinkt gebruikersvriendelijke voor de klant, maar wie is dan verantwoordelijk als het mis gaat igv identity theft, de zakelijke dienst, gebruiker of social network??
De eerste vraag die bij me opkomt is waarom we eigenlijk SSO willen?
“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.”
Maar als gebruikers zich niet druk maken om beveiliging dan wordt het weer een IT feestje waarmee er steeds meer ‘waterdragers’ in de kano komen. Vaak hand-in-hand met SSO komt dan ook de behoefte van sterke authenticatie waardoor kosten snel stijgen en naast voordelen zijn er dus even zo veel nadelen, ik noem er 3 op grond van lessen met DigiD:
1. High-value aanvalsdoel (DigiNotar)
2. Single point of failure (Lek Ruby on Rails)
3. Extra interfaces te handhaven (Schijnveiligheid)
Betreffende beheer digitale identiteiten zijn inderdaad ook nog veel vragen te stellen want de provisioning blijkt vaker makkelijker dan deprovisioning.
@ Ewout Tegen hackers en lekken in het algemeen heb ik ook geen oplossing. Voel me toch veiliger met een goede sso implementatie.
Beste Hans-Peter
Bij SSO maak je gebruik van 1 account dus 1 gebruikersnaam/wachtwoord. Het voordeel voor de gebruiker is duidelijk, maar er zit ook een nadeel aan dit systeem. Op het moment dat je SSO inzet heeft een hacker maar 1 gebruikersnaam/wachtwoord nodig om tot al die diensten toegang te krijgen.
Bij SSO moet je dus heel goed kijken naar het Authenticatie proces. Two-factor of multi-factor authenticatie is dan wel te adviseren.
Daarnaast kan het juist vanuit security een overweging zijn om met meerdere gebruikersnamen/wachtwoorden te werken. Hierbij creëer je een extra authenticatie laag aan op de toegang tot de cloud dienst. Of dit wenselijk is, zal per klant verschillend zijn.
Martijn Bellaard
@Martijn
Om die reden migreren sommige bedrijven juist weg van SSO, ze voegen een extra aanlog met een beperkte sessietijd toe. Dit omdat gebruikers nog vaak gaan lunchen zonder hun desktop te locken.
Nu is natuurlijk niet alle informatie belangrijk maar zoals Cordny ook al naar voren bracht, hoe zit het met de verantwoordelijkheid?