Single Sign On

Single Sign On
Single sign on er konceptet hvori en bruger kun authentificerer sig op imod ét systemer, der derefter gør brugeren i stand til at tilgå en række andre systemer Læs evt mere på wikipedia

Der findes en række opensource tiltag der kan bruges til at implementere Single SignOn, det mest kendte er nok OpenID.

Implementering i Korpset
Der har ind til videre været to bud på hvordan selve SSO-serveren skal implementeres.

Som en del af Blåt Medlem

Ud over de normale medlems-data lagres også De umiddelbare argumenter imod denne løsning har været at udvikling og vedligeholdelse af selve SSO kernen skal ske hos CBrain, samt at vi for at understøtte SSO for ikke-medlemmer bliver nødt til at kunne oprette dem i Blåt Medlem
 * Listen over hvilke sites brugeren må tilgå, samt med hvilken rettighed
 * mapping imellem medlems-nummer og brugernavn hvis folk ikke skal logge ind med deres medlemsnummer
 * medlemmets password
 * overblik over hvem der er logget ind på et givent tidspunkt

Som en "hjemmelavet" server

Vi laver en central SSO-server der indeholder den centrale SSO relaterede data, dvs Umiddelbare argumenter imod denne løsning har været at man gerne ville købe sig til det for at få det lavet hurtigt, samt at man gerne vil kunne kontrollere mest muligt fra ét system (Blåt Medlem)
 * Brugernavn samt mapping imod et evt medlemsnummer
 * password, evt kan man lade passwordet være lagret i BM for brugere der ikke er medlemmer
 * Overblik over hvem der er logget ind et givet tidspunkt

Når brugeren er logget ind udstikker SSO-serveren (Dvs BM eller den hjemmelavede) på en eller anden måde et token som brugeren derefter kan bruge til at logge ind på diverse sites. Dette token stiller også sitet i stand til at indhente diverse data fra systemer der understøtter SSO.

Hvilket leder til en sidste vigtig komponent: Data-adgang. (find gerne på et bedre navn).

Data Adgang vha SSO
Imod et gyldigt token kan et site indhente bruger-data fra en central data-adgangs komponent. Komponenten har to vigtige roller: 1: Giver et simpelt interface til at hente data 2: Danner ét enkelt punkt hvor vi kan lave adgangskontrol

Komponenten kan i princeippet være en del af BM, men vil nok være lettest at lave som en central komponent kørende fra Holmen. Dette er især vigtigt den dag hvor vi skal kunne tilgå data fra andre steder end Blåt Medlem.

Det bør som eksempel være mulig at bede om at få "alle kurser et medlem deltager i", uden at skulle tage stilling til hvilke krumspring der skal laves i BM og kurusdatabasen for at få indhentet disse data. Skulle en bruger af data-adgangs komponenten prøve at tilgå et andet medlems data er det også her der skal hakkes en bremse i.

En række tanker og spørgsmål
Her er nogle af de spørgsmål, vi skal have afklaret - der kommer sikkert flere, når vi får tænkt det mere igennem:

1). Hvis Blåt Medlem skal bruges til adgangsstyring, hvilke oplysninger kræves så fra BM (f.eks. kræver udvalgsdatabasen nok oplysning om en given person er medlem af et givent udvalg). 2). Hvilke oplysninger er ønskelige (f.eks. navn, tlf., email)? 3). Hvordan identificeres brugere p.t. (email, selvvalgt ID, andet)? 4). Er det vigtigt, at brugeren selv kan rekvirere eller nulstille sit password? (Hvis det er muligt nu, hvor ofte bliver det så brugt?) 5). Er der (potentielle) brugere af systemet, som ikke er registreret i Blåt Medlem? 6). Er der udsigt til større ændringer i systemet?

Proof of concept 1
Jonathan har lavet en POC af en central SSO server på http://spejder.dk/sso/ssotest.php Beskrivelse: Modellen kan testes på: http://spejder.dk/sso/ssotest.php http://1fredensborg.dk/ssotest.php http://dingo.dds.dk/100/ssotest.php Man kan teste på eget site ved at kopiere http://spejder.dk/sso/ssotest.phps til ssotest.php på eget site. Der er p.t. oprettet 3 brugere (test1, test2 og test3 - alle har password "sso"). Da brugernavne kan ændres, får man et unikt "SSO-ID", som er h.h.v. id001, id002 og id003 for de tre brugere.