Single Sign On, SSO

Introduktion

Vad är SSO? Jo, det har ju med inloggning att göra och det ska helst ske bara en (single sign on) gång, då är det bra. Men vad menar vi på SecMaker när vi säger ”Net iD SSO”? Menar vi samma sak som CA, Citrix, Cybercom, Oracle, Microsoft, IBM, NordicEdge m.fl.?

Nej, vi menar inte riktigt samma sak!

Innan vi går vidare kan vi kanske få komma med ett förslag till ny definition av begreppet SSO…

”SSO är den varma känsla som kan infinna sig hos en användare som på ett enkelt sätt når merparten av den information som behövs för arbetets utförande”

Om vi låter detta definitionsförslag gälla invänder sannolikt ansvarig IT-arkitekt;
– Jovisst, det låter ju fint, men hur  bygger vi bäst upp den infrastruktur som krävs?
– Sant, ska en känsla av enkel inloggning byggas lär det behövas tid, kompetens, kod, system, applikationer, biljetter, pengar och handfast projektledning. Man vill självklart dra nytta av de smarta kort man införskaffat, både avseende säkerhet men framförallt gällande enkelheten för användarna.

Några klipp från nätet om vad SSO sägs vara:

Wikipedia på svenska

Single sign on, SSO, är en metod inom sammansatta datasystem för att hantera användare med aspekt på användarbehörighet (auktorisering) och användarverifiering (autentisering), så att dessa användare endast behöver logga in en enda gång för att nå de system som är anpassade till tjänsten. Fördelen för användaren är att man inte behöver hålla reda på flera olika lösenord.

Wikipedia på engelska (ganska lika men med ett viktigt tillägg)

Single sign on (SSO) is a property of access control of multiple, related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. Single sign-off is the reverse property whereby a single action of signing out terminates access to multiple software systems.
As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication.

Hur angripa problemet?

Innan vi tittar närmare på olika metoder för att åstadkomma SSO måste vi först backa bandet.

Olika applikationskoncept

Bilden här under visar några exempel på olika applikationskoncept som kan förekomma i en tänkt infrastruktur. Som du ser är floran av lösningar stor både på klientsidan och på serversidan. Det är i denna struktur som vi ska försöka åstadkomma SSO baserat på tvåfaktorsautentisering.
(bilden gör inte anspråk på att vara heltäckande)

appkoncept

I en stor organisation med många olika typer av arbetsuppgifter och personalkategorier hittar man nästan undantagslöst något i stil med bilden ovan. Dvs. man har ett stort antal applikationer som implementerat olika typer av inloggningsmekanismer men vanligast är att användaren matar in användarnamn och lösenord.

Prioriteringsordning och applikationsmatris

När man har klart för sig vilka applikationer som berörs och olika inloggningssätt de använder bör man staka ut en strategi för att den kommande SSO-lösningen inte ska behöva bli spretigare än nödvändigt. Denna strategi är helt nödvändig för att kunna fatta beslut om vägen framåt. Till att börja med behöver det inte vara mer omfattande än att man ställer upp en enkel matris. Men innan man fyller i matrisens beslutskolumn är det några frågor man bör ställa sig:

¤ Åt vilket håll vill vi styra vår infrastruktur på lite sikt?

¤ Hur många dispenser från SSO-känslan ”tål” användarna?

¤ Hur pigga är våra applikationsleverantörer på att BIF-, SAML, Kerberos- smartkort-ifiera sina applikationer?

¤ Kan vi hitta referenser rörande lyckade SSO-projekt som vi kan ge oss värdefull input?

Svaren på bl.a. dessa frågor ger underlaget för att fatta beslut för hur applikationerna ska hanteras:

En prioritetsordning som denna skulle kunna fungera:

I första hand
Den primära autenticeringen sker med kort/certifikat, då kan många applikationer dra nytta av denna primära inloggning (ofta mot AD) genom att applikationerna använder Kerberos.

I andra hand
I vissa fall sker ingen påloggning mot AD med kortet och ingen Kerberosbiljett finns tillgänglig. Då kan en SAML-baserad lösning med en intern ”Identity Provider” passa. För externa kopplingar mellan huvudmän används BIF som är ett SAML-baserat koncept.

I tredje hand
Certifikats-enabla applikationen

I fjärde hand
Nyttja en SSO-programvara som hanterar automatisk ifyllnad av namn och lösenord

I femte hand
Ge applikationen dispens och förklara samtidigt varför just denna applikation visat sig ”hopplös”.

En prioriteringsordning som mindre troligt fungerar:

I första hand
Ge många dispenser för att köra vidare med namn och lösenord

I andra hand
Hitta applikationer som nyttjar OTP via SMS

I tredje hand
Migrera till Kerberos-medvetna applikationer

I fjärde hand
Certifikats-enabla applikationen

Här är ett exempel på hur man kan resonera kring vägen framåt för olika applikationer relaterat en tänkt infrastruktur
(inte heller denna bild gör anspråk på att vara heltäckande eller ge de ”rätta” svaren)

matris

Kontentan är alltså att om man inte går igenom sin applikationsflora och skapar en strategi för den så får man inte den nytta av sin nya PKI-infrastruktur baserad på smarta kort med certifikat som man hade hoppats. SSO är inget som kommer med PKI-tekniken i sig själv.