Erfarenheter från identitetsprojekt

Större IdM projekt är inte så vanliga i Sverige, men jag har fått möjlighet att delta i ett par av dem som IdM-arkitekt. Just för att projekten är så få, så är erfarenheterna från dem också få och väldigt lite spridda. För att öka kunskapsspridningen inom IdM projekt baserade på Suns Identity Manager så kommer jag att hålla ett föredrag på Suns Teknikforum i Akalla den 5:e december 2007. Det är öppet för inbjudna, partners och liknande samt naturligtvis för Sun anställda. Har du möjlighet, så kom gärna och lyssna på IdM föredraget kl 16 i Hörsalen, Sun, Akalla.

För er övriga ges en kort sammanfattning nedan samt länkar till de verktyg vi har använt i projektet. Verktygen kan endast användas för personligt bruk, all annan användning kan innebära krav på licensiering. Ta kontakt med Inserve ifall du är tveksam. Det intellektuella kapital från min sida som ingår i verktygen bjuder jag dock på, det är min investering i att öka IdM företeelsen i Sverige. Gillar du dem, så skicka mej gärna ett mail och berätta. Kanske har du en förbättring att föreslå och då kan den komma alla i IdM Sverige till glädje.

Sammanfattning av min presentation.

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 process projekt, ett SSO projekt, ett säkerhetsprojekt mm, mm. Vare sej leverantör eller kund klarar att göra allt detta på en gång, så dela upp det i bitar 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 att lösningen tas fram gemensamt. Utgå från ett Scenario beskrivet av kunden, prototypa det som 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 ska implementeras på riktigt så finns bra specar 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 ska 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 detta då installationen är minimal och stödet i olika verktyg och IDE:er brukar vara fullgott. Det en utvecklare har gjort checkar han in i CVS:en, det som bara finns installerat i en utvecklingsmiljö räknas inte. Detta synsätt krävs för att release hanteringen ska fungera och att vi ska veta vad som är gjort.

Genom att låta Apache Ant hantera release-skapandet så får vi en automatiserad process som vi kan upprepa allteftersom projektet framskrider. Vi kan tydligt se att vi kör Build 56 i produktionsmiljön, men Build 67 i Acceptansmiljön. I CVS:en kan vi lätt ta fram koden som respektive Build-release är baserad på.

Följande verktyg har använts för att underlätta projektarbetet:

Snabbt sätta upp ett nytt projekt i CVS. Innehåller ett flertal verktyg och HowTo:s (62MB zip).

Snabbt sätta upp en egen utvecklingsmiljö. Kräver ingen installation,
färdig för Windows men kan enkelt fås att fungera i Linux/Solaris
(126MB zip).

Hjälpverktyg för att tvätta XML-filer, hitta förändringar mm (2.5MB jar).

Tvättkommandot är:
javaw.exe -Xmx512m -jar pathtoXmlFiler.jar -t -c clearfiles %1
Lägg upp det som en action på XML filer i Windows Explorer

CVS server. Finns som SMC paket till Solaris.

CVS klient som integreras snyggt i Windows Explorer.

Apache Ant är verktyget för att bygga releaser av IdM.

3. Ett ord på vägen

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

 

/Mattias (mail)