Modules

Classic-, Enterprise-, en Social login

Veel websites maken gebruik van een login. Dit kan gaan om websites met een afgeschermd gedeelte, intranetten of extranetten. Kirra heeft hier enkele standaardoplossingen voor die vaak gekoppeld worden met de module Profielen.


Toegang tot pagina's beheren

Als je een login in je website hebt, dan kun je pagina's afschermen. Als je een pagina afschermt, dan geldt dat ook voor onderliggende pagina's.

Het afschermen van een pagina kun je doen met het icoon van een slot naast de paginatitel.


Classic login

De meestgebruikte oplossing is een classic login. Dit zorgt ervoor dat je gebruikersaccounts kunt hebben met een gebruikersnaam en wachtwoord.

In deze variant kan ingesteld worden of gebruikers zelf een account mogen registreren, of dat ze hiervoor door jou uitgenodigd moeten worden. Nadat een account wordt aangemaakt krijgt de gebruiker een e-mail met verdere instructies. Deze e-mail bevat een bevestigingslink, waarna de gebruiker zelf een wachtwoord kan kiezen. Hierna kan er ingelogd worden.

Als iemand zijn wachtwoord is vergeten of anderszins niet kan inloggen, kan dit hersteld worden via de 'Wachtwoord vergeten'-functie.

Enterprise login

De Enterprise login zorgt ervoor dat de login van je besturingssysteem (ook wel Active Directory of AD genoemd) wordt gebruikt om in te loggen. De login waarmee je inlogt in Windows kan gekoppeld worden aan andere diensten zoals een website. Dit wordt Active Directory Federation Services (ADFS) genoemd.

Voor deze koppeling moet er zowel aan de kant van Kirra als de organisatie een en ander geconfigureerd worden. Het draagt te ver om dit allemaal te bespreken. Als dit eenmaal werkt, dan wordt de login buiten Kirra geregeld. Functies als accounts aanmaken of wachtwoord vergeten zijn daarmee overbodig als je een Enterprise login gebruikt.

Social login

Veel mensen hebben een account op sociale media zoals Facebook of Google. Deze diensten bieden ook de mogelijkheid om te koppelen aan andere applicaties, zoals een website. Zo kun je bijvoorbeeld met je Facebook-account inloggen bij je website. Dit is handig omdat je dan sneller een account kunt maken bij een website, minder accounts nodig hebt en de veiligheid daarvan belegt bij minder leveranciers. Als dit eenmaal werkt, dan wordt de login buiten Kirra geregeld. Functies als accounts aanmaken of wachtwoord vergeten zijn daarmee overbodig als je een Social login gebruikt.

Kirra koppelen met Active Directory (ADFS) via Enterprise Login

De module Enterprise Login maakt het mogelijk om via een koppeling met een Windows-domein (via ADFS - Active Directory Federation Services) in te loggen. Er dienen wat instellingen gedaan te worden om dit werkend te maken zodat de ADFS-server en de Kirra-installatie elkaar vertrouwen.

Configureren van een ADFS-server
Is er nog geen ADFS-server of wil je onderstaande stappen controleren? Zie dan dit voorbeeld met screenshots in de wetenschap dat een ADFS-server per organisatie, omgeving en softwareversie verschillend kan zijn. Gebruik dit voorbeeld daarom als leidraad.

HTTPS op de ADFS-server

Je hebt hiervoor een ADFS-server nodig. Deze server dient HTTPS te ondersteunen. Hiervoor kun je

  • Een bestaand TLS-certificaat gebruiken of aanschaffen (aanbevolen)
  • Zelf een certificaat maken waarbij je zelf als Certificate Authority (CA) optreedt. Je moet dan wel zorgen dat dit certificaat als uitzondering ingesteld wordt in de browsers in de organisatie, anders krijgen medewerkers foutmeldingen te zien. Verder is het belangrijk dat je zelf de geldigheidsduur van het certificaat monitort en tijdig vervangt. 

HTTPS op de intranetserver

Ook de server waarop het intranet gehost wordt, moet HTTPS ondersteunen. Dit kan bijvoorbeeld https://intranet.organisatienaam.nl zijn. Omdat het intranet wordt gehost door iWink, is het aanbevolen dat iWink dit certificaat aanvraagt en beheert.

Voeg de ADFS-Server toe aan de "Intranet" zone

Verder moet de ADFS-server in de instellingen van Internet Explorer toegevoegd zijn aan de "Intranet" zone, anders zal de browser weigeren om inlog-gegevens te versturen tijdens het inloggen. Dit moet gedaan zijn bij alle medewerkers. Voor zover ons bekend hoeft de URL van het intranet zelf niet toegevoegd te worden aan de "intranet" zone, maar mocht je problemen ondervinden bij het inloggen dan kan dat een poging waard zijn om te testen.

Maak een Relying Party Trust (*)

Wanneer de ADFS server is opgesteld, moet een Relying Party Trust worden aangemaakt. We gebruiken aan onze kant het SAML 2.0 WebSSO protocol. De URL die gebruikt kan worden om de koppeling te leggen is op te vragen bij iWink en kan per applicatie verschillen. Ook vragen we je vaak een beta- en acceptatie-omgeving toe te voegen zodat hierop getest kan worden door ons en je eigen organisatie.

Voeg de claim rules toe (*)

Vervolgens moet er een aantal Claim Rules ingesteld worden. Ga hiervoor naar de Claim Rules van de net ingestelde Relying Party Trust. Maak eerst een Transform Incoming Claim aan, en daarna een Claim om de beschikbare informatie uit het AD door te sturen naar Kirra:

  • Transform incoming claim: Windows account name > Name ID (Transient identifier), pass through all claim values
  • Send LDAP attributes (Store: Active Directory): User-Principal-Name > Windows account name + andere beschikbare data

* Let op: Herhaal nu de stappen met een (*) voor alle domeinen (productie, acceptatie en beta) voordat je verder gaat.

Stuur de Federation Metadata naar iWink

Wanneer de server dan goed ingesteld is, hebben wij het Federation Metadata bestand van deze server nodig. Deze is te vinden op https://[ADFS-server]/FederationMetadata/2007-06/FederationMetadata.xml