I alla de sammanhang vi har behov av att umgås över
gränserna uppenbarar sig identitetsfederering som en möjliggörare,
inte minst i alla de sammanhang där det inte går att enas i den
detaljgrad som varje enskild lösning ofta kräver. Det är betydligt
enklare att förälska sig i ramverk som även fokuserar på mjuka
frågor som utfärdande utan att på detaljnivå reglera alla tekniska
delar. Kantara Initiative Assurance Framework, som står modell för
den kommande standarden på området ISO/IEC 29115, är ett lysande
exempel.
Nåja, vad är väl en identitetsfederering? Den kan vara dötrist och
långtråkig och alldeles... alldeles underbar!
Det senare stadiet infinner sig först när vi tar steget från att
enbart federera identiteter och ser alla andra möjligheter som en
identitetsfederation kan ge. En bal på slottet kanske är att ta i,
men en och annan ytterligare samverkansknut går definitivt att lösa
upp. För att nå dit hän är det på plats att ånyo reflektera över
historien för att undvika de första klassiska misstagen. Här kommer
två exempel:
Vi behöver samverka över gränserna och min autentiseringslösning
är undermålig. Vi identitetsfedererar! Fel - Identitetsfederering
gör inte den egna autentiseringslösningen bättre!
Vi behöver samverka över gränserna och min autentiseringslösning
uppfyller alla tänkbara krav. Vi identitetsfedererar! Kanske rätt,
men oftast är genomförandet halvhjärtat. Endast identiteten
federeras. Övriga samverkansproblem löses ånyo på klassiskt vis,
där katalogsynkronisering brukar vara först ut följt av andra behov
av bakomliggande synkronisering av information.
Men även en resa på tusen mil börjar med ett steg och det går dock
inte att bortse från att även det första stapplande steget kan vara
förlösande, inte minst ur ett e-tjänsteperspektiv. Glöm alla olika
implementationer för att täcka en flora av autentiseringslösningar
och glöm alla konstlade lösningar för att lösa single-sign-on. Nu
räcker det med att e-tjänsten har förmågan att konsumera intyg
(biljett, ticket). E-tjänsteleverantören behöver nu enbart
kravställa innehållet i intyget. Hur banalt det än låter så är
detta en av de större utmaningarna.
Rätt kravställda intyg är avgörande för hur lyckad en samverkan i
slutändan blir.
I planeringsstadiet där lösningarna endast befinner sig i
presentationsform, är det ofta enkelt att med några streck visa hur
man bäst föder en e-tjänst. Exempelvis att behörighetshanteringen
kan ske inom ramen för attributsintyg, där den egna organisationen,
utöver att berätta VEM vederbörande är, också berättar VAD
vederbörande får rätt att utföra. I det verkliga livet är det
betydligt mer omfattande att realisera ett streck på tavlan,
speciellt utan att göra våld på befintliga system och standarder.
Varje streck bör därför noga motiveras innan det realiseras.
Genom att konsolidera användaradministration och autentisering
till ett antal specialiserade identitetsintygsutfärdare kan flera
av dagens funktioner i e-tjänsten koncentreras till att enbart
använda informationen, inte administrera densamma. En
hanteringsvinst som kanske inte är uppenbar i det första skedet men
vilken kommer förenkla implementationen av e-tjänster
substantiellt.
Ett annat behov som kan tillgodoses är att erforderlig information
för e-tjänsten kan hämtas direkt från källan via standardiserade
procedurer, och först när behovet uppstår. Önskar vi exempelvis
veta vem som företräder en viss organisation så ställs den frågan
bäst till den som redan från början har svaret. En
attributförfrågan kan ställas direkt till källan för att konsumeras
av e-tjänsten som ett attributsintyg. Här kan en
identitetsfederation göra stor skillnad.
Upplevelsen av attributsintyg och konsoliderad
användaradministration liknar kanske inte en bal på slottet, men
rätt tänkt och rätt använt så infinner sig flera
välbehagskänslor.
