Single Sign On: hoe support je alle applicaties?

Bij een Enterprise Single Sign On oplossing gaat het er vooral om hoe je zoveel mogelijk applicaties kunt ondersteunen voor wat betreft het inlogproces, maar ook het proces van omgaan met verlopen wachtwoorden en delegatie van credentials.

De meeste traditionele applicaties starten hun eigen vensters met daarin een inlogscherm wat bestaat uit een veld voor inlognaam, een veld voor wachtwoord en een button om in te loggen. De manier hoe je dit kunt tonen kan echter enorm verschillen waardoor een SSO applicatie moeite kan hebben om dit te ondersteunen.

Een SSO applicatie kijkt constant of er een “bekend” inlogscherm wordt gesignaleerd en reageert met het uitvoeren van een aantal stappen, zoals het invullen van inlognaam, password en het klikken van een button. Om ervoor te zorgen dat de SSO applicatie de inlognaam in het juiste veld gaat invullen kun je werken met control ID’s, waarbij elk invulveld zijn eigen ID heeft om ze zo te kunnen onderscheiden. Het komt echter voor dat, vooral bij moderne .NET applicaties, deze ID’s elke keer random worden gegenereerd bij het opstarten van de applicatie. Een oplossing die uitgebreide SSO applicaties hiervoor hebben is het dynamisch kunnen opzoeken van control ID’s op basis van criteria zoals relatieve positie in het window, naam en object-class.

Een andere uitdaging is het ondersteunen van web-applicaties met hun eigen inlogschermen. Het komt voor dat een inlogpagina bestaat uit frame-delen die dynamisch worden ingeladen, waardoor de velden die ingevuld moeten worden niet werkelijk op de inlogpagina staan, maar juist in een pagina die via een frame wordt getoond. Een meer complexe SSO applicatie kan dit ondervangen door in de browser dit te herkennen en zo vanuit een hoofdpagina ondersteuning bieden aan invulvelden die ingeframed worden getoond.

Een laatste type “lastige” applicatie is waar het gaat om Terminal emulaties naar bijvoorbeeld UNIX en AS/400 systemen, die nog vrij veel gebruikt worden in de financiele wereld. Deze applicaties gebruiken veelal niet echt een dialoog of window om in te loggen, maar komen met een DOS/telnet prompt waarbij login gegevens moeten worden ingevoerd. Hierbij wil je niet dat een SSO applicatie uitgaat van een dialoog, maar dat er automatisch een keyboard simulatie moet kunnen worden uitgevoerd, waarbij het voor de applicatie lijkt alsof er een sequentie van toetsaanslagen binnenkomt en het zal reageren alsof het een “echte” gebruiker is.

Bij Gemeentes en in de Zorgsector zien we vaak applicaties die bovenstaande “problemen” kennen waardoor veel eisen gesteld worden aan een SSO applicatie. Tools4ever heeft een SSO applicatie in ontwikkeling die kan voldoen aan alle genoemde eisen en zo voor een nette sluitende Single Sign On oplossing kan zorgen. Wellicht is het interessant om eens over een Proof of Concept (PoC) na te denken, het is namelijk goed mogelijk om in 1 dag een aantal applicaties voor SSO in te richten in een pilot omgeving en er een goed beeld gegeven kan worden hoe dit voor eindgebruikers zal gaan werken.

Klik hier voor meer informatie over Single Sign On (SSO).

• single sign on
• sso
• applicaties
• inloggen