Je kunt providers configureren op volgorde van voorkeur om zo een verificatieketen te maken waarbij elke provider opeenvolgend wordt bevraagd totdat de gebruiker is aangemeld of niet kan worden geverifieerd. Gebruik de volgorde om te zorgen dat er sprake is van failover als de verbinding met de bron van een provider is verbroken. Als je bijvoorbeeld drie LDAP-providers hebt en de standaardprovider is ingesteld op Actief, neemt het verificatieframework contact op met de eerste provider, en als de gebruiker niet wordt gevonden, wordt de volgende provider bevraagd totdat de gebruiker is gevonden en de verificatie is gelukt of mislukt. Als de gebruiker bij geen enkele provider wordt gevonden, mislukt de verificatie.


De volgorde van providers instellen

Ga als volgt te werk om de volgorde van providers in te stellen:

  1. Ga naar het configuratiescherm voor systeembeheer en selecteer Verificatie in de sectie Building Blocks.
  2. Selecteer Volgorde van providers op de pagina Verificatie.
  3. Sleep de providers om ze in de gewenste volgorde te zetten, van eerst naar laatst. Je kunt dit trouwens ook doen met de tool Volgordeaanpassing toegankelijk via toetsenbord.
  4. Zet de optie Doorgaan bij fout eventueel in op Ja. De standaardwaarde is Nee. Deze optie bepaalt of volgende providers moeten worden verwerkt als bij de verwerking van een eerdere provider een fout is opgetreden. Deze optie is algemeen voor de keten van providers.

    Doorgaan bij fout is alleen van toepassing als de lijst meer dan een actieve provider bevat.

  5. Je kunt bij Verificatiemodus kiezen uit twee providertypen: REDIRECT en USER_PASS.

    • Providers van het type REDIRECT, zoals CAS, geven de verificatie door aan de externe verificatiebron. Deze typen worden niet vermeld bij Volgorde van providers aangezien ze worden beschouwd als de gezaghebbende bron voor verificatie en ze hun eigen verificatiefouten afhandelen.
    • Providers van het type USER_PASS, zoals Learn Standaard en LDAP, sturen een query naar de verificatiebron, met als resultaat een van vier statuswaarden. Providers van dit type kunnen worden opgenomen in een keten.
      • Aanmelding gelukt.
      • Gebruiker niet gevonden (framework probeert de volgende provider).
      • Gebruiker gevonden maar wachtwoord ongeldig (framework breekt de aanmelding af).
      • Er is iets mislukt (framework gaat alleen door als Doorgaan bij fout is ingesteld).

Wat is Doorgaan bij fout?

Als je verificatieproviders opneemt in een keten, kun je instellen of bij het mislukken van verificatie van een gebruiker door een vorige provider de verificatie moet worden overgedragen aan de volgende provider in de keten. Kennis van de mogelijke foutcondities en de gevolgen hiervan is handig voor het oplossen van aanmeldingsproblemen.

Het is niet mogelijk om een volledige lijst van potentiële oorzaken van mislukte verificaties te geven, maar we kunnen ze wel onderverdelen in drie groepen: - 1) Servicebeschikbaarheid: fouten die het gevolg zijn van het feit dat de service die door de verificatieprovider wordt aangeboden, niet beschikbaar is; 2) Verificatieservice: de gebruiker is niet gevonden in de service die door de verificatieprovider wordt aangeboden of het gebruikerswachtwoord is onjuist; 3) Onbrekend Blackboard Learn-account.

Enkele voorbeelden van 'Doorgaan bij fout' waarbij de volgende actieve verificatieprovider wordt aangeroepen:

  • Servicebeschikbaarheid en gebruiker niet gevonden in de opgegeven naamdirectory van de provider.
  • Fout bij verbinding met de verificatieprovider. Bijvoorbeeld: Learn kan geen contact opnemen met de geconfigureerde LDAP-server.
  • Gebruikersnaam niet gevonden in de opgegeven naamdirectory van de verificatieprovider. Bijvoorbeeld: gebruiker is niet gevonden in de geconfigureerde LDAP-directory.

Enkele voorbeelden van 'Doorgaan bij fout' bij verificatieproblemen waarbij de volgende actieve verificatieprovider niet wordt aangeroepen:

  • Verificatieprovider heeft de gebruiker gevonden, maar er is een ongeldig wachtwoord doorgegeven.
  • Verbinding met de verificatieprovider en de daaropvolgende gebruikersverificatie zijn gelukt, maar de gebruikersnaam is niet gevonden in Blackboard. Bijvoorbeeld: de gebruiker is geverifieerd via LDAP maar heeft geen Blackboard Learn-gebruikersaccount.
  • Verbinding met de verificatieprovider is gelukt en de gebruiker is gevonden, maar er is een onjuist wachtwoord doorgegeven aan de verificatieprovider, waardoor de gebruiker niet kan worden geverifieerd. De gebruiker kan wel of niet een Blackboard Learn-gebruikersaccount hebben. Bijvoorbeeld: de gebruiker voert een juiste gebruikersnaam in maar een ongeldig wachtwoord voor zijn of haar LDAP-account. De gebruiker wordt dan wel gevonden door LDAP, maar verificatie is niet mogelijk.