Identitetshantering – Nu behöver du inte längre vara pionjär

En av de som arbetat i det främre ledet när det gäller identitetshantering hos svenska företag är Inserves Mattias Odén. Även om Sverige fortfarande ligger efter USA och de större europeiska länderna har IdM enligt Mattias Odén fått en mer framskjuten position på agendan och avståndet är inte längre lika stort. Att svenska företag generellt legat efter har givetvis också sin förklaring i att vi har färre stora företag i Sverige.

Belöning att vänta, men välj rätt infallsvinkel

”Frågan om identitetshantering aktualiseras ofta i samband med att företaget får anmärkningar vid revision. Kraven blir här allt tuffare och det är långt ifrån bara Sox som driver på utvecklingen. För de företag som tar sig an frågan handlar det dock inte bara om att möta regler och lagkrav. Här finns flera andra incitament; effektivare hantering av licenser som ”skvalpar”, smidigare och billigare lösenordsadministration samt minskade kostnader för kontouppläggning. Det blir också enklare och säkrare att hantera medarbetare som börjar, slutar eller byter arbetsuppgifter.” Enligt Mattias Odén är det samtidigt viktigt att ta sig an identitetshanteringen som ett integrationsprojekt där gränsytorna mellan olika applikationer måste utvecklas snarare än ett tekniskt konfigurationsprojekt. ”Det blir både dyrt och dåligt att köpa det här som en produktlösning, det är betydligt mer framkomligt att från början behandla IdM som ett utvecklingsprojekt men att starta med en effektiv verktygslåda.”

De flesta IdM-projekt involverar förutom IT-avdelningen också HR- och ekonomifunktionen. Är det sedan inte frågan om ett rent tekniskt ”synkprojekt” är ledningens medverkan, i varje fall i de lite större projekten, central. En iakttagelse är också att äldre företag generellt sett har det något trassligare och en historik att hantera. Behoven ökar med detta.

Nya beteenden

Förändringsarbete tar ofta emot och förknippas gärna med långbänk och komplexa besluts- och implementeringsprocesser. Mattias Odén menar att nya beteenden inte är en del av IdM:s projektplan men att de kan förväntas uppstå som ett resultat av införandet. I samband med att befintliga processer ofta kan ”streamlinas” och rationaliseras påverkas det allmänna sättet att hantera behörigheter och identiteter. Hos ett större svenskt verkstadsföretag noterade man bl a en beteendeförändring efter införandet av ”password management” som en del i arbetet med IdM.

”Ingen bryr sig om dig när du slutar…”

Genom att samla identitetshanteringen från olika system på ett ställe väcks naturligtvis frågan om säkerhet. Blir organisationen inte väldigt sårbar om den som kommer åt informationen kommer åt allt? ”Sant, till saken hör dock att det i väldigt många fall redan är så men att då även ”fel” personer har tillgång till informationen.” Med IdM ökar alltså möjligheterna att arbeta säkert. Vinsten blir att det är betydligt enklare att kunna rensa kontinuerligt och få bort felaktiga användare. Idag har företagen ofta usel kontroll, inte minst när människor slutar men behåller möjligheten att komma åt information osv. En undersökning från IT-barometern visar att hälften av alla större företag inte har koll på om deras tidigare anställda ännu har tillgång till affärskritisk information via företagets interna nätverk.

Med en genomtänkt identitetshantering är det t ex möjligt att låta verksamhetsansvariga, inte nödvändigtvis IT-avdelningen, hantera användarkonton. På så vis kan man minska risken att personer som slutar fortsätter ha kvar aktiva konton. En avslutande iakttagelse från Mattias Odén är att det framöver sannolikt kommer att finnas större likheter sett till de lösningar som finns på marknaden.

Några råd från Mattias Odén för konsultkollegor som står inför ett IdM-projekt baserat på Suns Identity Manager:

1. Projektets uppstart

Som i alla mjukvaruprojekt gäller det att dela upp projektet i hanterliga faser. Varje fas bör kunna motivera sin egen existens i form av kundnytta. Detta krav är ännu större i ett IdM-projekt då IdM lätt kan växa till ett roll- och processprojekt, ett SSO projekt, ett säkerhetsprojekt osv. Oavsett om leverantör eller kund klarar att göra allt detta på en gång, är rådet att dela upp arbetet i delar som vardera inte bör ta mer än 6 månader att genomföra.

Ofta vet inte kunden precis vad de vill ha, de vill bli vägledda och uppleva att lösningen tas fram gemensamt. Utgå här från ett scenario beskrivet av kunden, utveckla en ”dummy” i IdM och föreslå fördelar som ändringar i scenariot kan innebära. Först här får kunden en möjlighet att förstå vad IdM kan leverera. Det här är en iterativ process där du som utvecklare väver in allt mer fungerande kod i lösningen tills scenariot till slut är det rätta. När det sen skall implementeras på riktigt så finns bra specifikationer och en kodstomme att utgå ifrån. Tidsplaner och prissättning blir också korrekta.

2. Verktyg och metoder

När det finns några ”specar” att börja jobba efter så är det dags att  IdM-utvecklarna kommer med i projektet. Då gäller det att snabbt få dem att jobba ihop på ett effektivt sätt. Allt som görs i IdM kan sparas som textfiler, antingen det är kod eller konfigurations-ändringar i databasen. Dessa textfiler skall sparas i ett versionshanteringssystem som möjliggör att det går att spåra ändringar och jämföra med tidigare versioner. Jag har använt CVS för det arbetet då installationen är minimal och stödet i olika verktyg och IDE:er brukar vara fullgott. Det en utvecklare har gjort checkar han eller hon in i CVS:en, det som bara finns installerat i en utvecklingsmiljö räknas inte. Detta synsätt krävs för att releasehanteringen skall fungera och för att veta vad som är gjort.

Genom att låta Apache Ant hantera releaseskapandet så får man en automatiserad process som kan upprepas allteftersom projektet framskrider. Det går tydligt att se om man kör Build 56 i produktions- miljön, men Build 67 i Acceptansmiljön. I CVS:en kan man lätt ta fram koden som respektive Build-release är baserad på.

3. Ett ord på vägen

Till sist, glöm som sagt flosklerna om att IdM-projekt är konfigurations-projekt! Det är de inte. Du lurar bara dig själv och kunden genom att lägga fram det så. Snart nog sitter ni där och kodar workflows i XML.