}

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).

SAP koppeling met Active Directory

Bij 1 van grootste ziekenhuizen van Nederland heb ik recentelijk een SAP koppeling naar Active Directory opgeleverd met behulp van UMRA van Tools4ever. Het scenario is dat SAP elke x minuten een feed aanleverde in CSV formaat met alle wijzigingen, die vervolgens in Active Directory verwerkt moeten worden. Met behulp van specifieke codes voor bepaalde mutaties (instroom, doorstroom, uitstroom) weet de UMRA engine welke business logica uitgevoerd moet worden.

Lees meer

Categorieën

Single Sign On

active directory, sap, umra, user management

User- en toegangsbeheer in cloud applicaties: een uitdaging

Cloud applicaties als Google Apps, Salesforce.com, GoToMeeting, Office 365, itslearning, AFAS Online en RAET Online worden steeds meer ingezet in het bedrijfsleven. Bij cloud applicaties is het lastiger om exact te weten wie toegang heeft tot welke applicaties en data. Leveranciers van cloud oplossingen geven helaas weinig prioriteit aan het ontwikkelen van beter beheer van user accounts en toegangsrechten in hun applicaties.

Lees meer

Categorieën

Single Sign On

authenticatie, authentication, user provisioning

De vooroordelen van Single Sign On

Veel IT managers en Security Officers zijn terughoudend als het gaat om het implementeren van een Single Sign On (SSO) oplossing, hoewel de voordelen van SSO duidelijk zijn. Namelijk onder andere gebruikersgemak voor de eindgebruiker en minder wachtwoord reset calls naar de helpdesk. De terughoudendheid ten aanzien van SSO wordt in de hand gewerkt door een aantal vooroordelen over SSO.

Lees meer

RBAC: sleutelrol, beheer en evolutie

Veel organisaties zijn bezig met RBAC in meer of mindere vorm; verkenning, project, implementatie, vulling of beheer. We zien dat dit gestuurd wordt door normen als NEN7510, waarin voornamelijk staat beschreven dat je moet kunnen aantonen waarom iemand een autorisatie nodig heeft en hoe deze tot stand is gekomen. Inmiddels weten we dat RBAC niet een heilige graal is, maar dat veel implementaties stuk lopen door de te grote scope en complexiteit.

Lees meer

Single Sign On met terminal emulatie (VAX64, AS/400, Linux, SSH)

We zien dat veel organisaties steeds bewuster bezig zijn met security, waarschijnlijk mede ingegeven door regelgeving zoals NEN7510 en ICT-audit trajecten. Naast het autorisatiebeheer binnen applicaties, waar we al verschillende oplossingen voor bieden zijn we ook actief op het authenticatie-vlak, namelijk met een Single Sign On (SSO) oplossing.

Lees meer

Categorieën

Single Sign On

e-ssom, single sign on, passwords, productiviteit, sso, wachtwoorden