Volgorde van providers
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:
Selecteer in het configuratiescherm voor systeembeheer in de sectie Integraties de optie Verificatie.
Selecteer op de pagina Verificatie Providerorder.
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.
Zet de optie Doorgaan bij fout eventueel in op Ja. De standaardinstelling is Geen. Deze optie geeft aan of volgende providers moeten worden verwerkt als een vorige faalt door een fout. Deze optie is algemeen voor de keten van providers.
Opmerking
Doorgaan bij fout is alleen van toepassing als de lijst meer dan een actieve provider bevat.
U kunt verificatieproviders baseren op twee typen Verificatiemodus: 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.
USER_PASS type providers, zoals Blackboard Default en LDAP, voeren een query uit op de verificatiebron die een van de vier statussen retourneert. 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.
Opmerking
Het is niet mogelijk om een uitgebreide lijst van mogelijke storingsoorzaken binnen een authenticatiearchitectuur te geven, maar ze kunnen in drie groepen worden ingedeeld: 1) Beschikbaarheid van diensten: storingen die het gevolg zijn van het niet beschikbaar zijn van de door de authenticatieprovider aangewezen dienst; 2) Authenticatieservice: de gebruiker die niet wordt gevonden in de door de authenticatieprovider aangewezen dienst of een onjuist gebruikerswachtwoord heeft; 3) Gebrek aan Blackboard-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: Blackboard kan mogelijk geen verbinding maken met de geconfigureerde LDAP-server.
Gebruikersnaam niet gevonden in de opgegeven naamdirectory van de verificatieprovider. Bijvoorbeeld: de gebruiker wordt 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-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 al dan niet een Blackboard-gebruikersaccount hebben. Bijvoorbeeld: de gebruiker voert een correcte gebruikersnaam maar een ongeldig wachtwoord in voor zijn LDAP-account - LDAP vindt de gebruiker maar kan niet verifiëren.