Så fungerar SEAM

Här följer en allmän översikt över verifieringssystemet SEAM. Mer ingående information finns i "Så fungerar verifieringssystemet".

Ur användarens synvinkel är SEAM för det mesta osynligt när SEAM-sessionen väl har startat. Kommandon som rsh och ftp fungerar i stort sett som vanligt. Att starta en SEAM-session innebär oftast inte mer än att logga in och ange ett Kerberos-lösenord.

SEAM-systemet kretsar kring begreppet biljett. En biljett är en uppsättning elektronisk information som fungerar som identifikation för en användare eller en tjänst som NFS-tjänsten. På samma sätt som ditt körkort identifierar dig och visar vilka fordon du har rätt att framföra, identifierar biljetten dig och dina åtkomsträttigheter i nätverket. När du utför en SEAM-baserad transaktion - t ex om du använder rlogin för att ansluta till en annan dator - skickas transparent en förfrågan om en biljett till en KDC (Key Distribution Center), vilken kontrollerar en databas för att verifiera din identitet. KDC:n skickar tillbaka en biljett som ger dig åtkomstbehörighet till den andra datorn. "Transparent" innebär att du inte uttryckligen behöver begära en biljett, det sker i stället som en del av kommandot rlogin. Eftersom det bara är den verifierade klienten som kan få en biljett för en viss tjänst, kan inte en annan klient använda kommandot rlogin under antagen identitet.

Biljetter har vissa attribut som styr deras egenskaper. En biljett kan t ex vara vidarebefordringsbar (vilket innebär att den kan användas på en annan dator utan ny verifiering) eller efterdaterad (den gäller inte förrän vid en viss angiven tidpunkt). Sättet biljetter används på - t ex vilka användare som får skaffa vissa typer av biljetter - anges av policies som bestäms när SEAM installeras eller administreras.

Du kommer ofta att se uttrycken referens och biljett. I större Kerberos-sammanhang används uttrycken ofta för att beskriva samma sak. Rent tekniskt är dock en referens en biljett plus en sessionsnyckel för sessionen. Den här skillnaden förklaras mer ingående i "Skaffa åtkomst till tjänster med SEAM".

I följande avsnitt beskrivs verifieringsprocessen i SEAM i korthet.

Första verifiering: biljettbeviljarbiljetten (TGT)

Kerberos-verifiering består av två faser: en första verifiering som medger följande verifieringar, samt själva de följande verifieringarna.

Figur 1-1 visar den första verifieringen:

Figur 1-1 Första verifiering för en SEAM-session

1. En klient (en användare eller en tjänst, t ex NFS) påbörjar en SEAM-session genom att begära en biljettbeviljarbiljett (TGT) från KDC:n (Key Distribution Center). Det här görs ofta automatiskt vid inloggningen.

   En biljettbeviljarbiljett behövs för att du ska få andra biljetter för särskilda tjänster. Det går att jämföra funktionen hos biljettbeviljarbiljetten med den hos ett pass. Liksom ett pass identifierar biljettbeviljarbiljetten dig och gör att du kan hämta flera "visum" - där dina "visum" (biljetter) inte är till andra länder utan för andra datorer eller nätverkstjänster. Biljettbeviljarbiljetten och de andra biljetterna har som pass och visum begränsad giltighetstid. Skillnaden är att "Kerberos-anpassade" kommandon ser att du har ett pass och skaffar visumen åt dig - du behöver inte utföra transaktionerna själv.

2. KDC:n skapar en biljettbeviljarbiljett och skickar tillbaka den i krypterad form till klienten. Klienten dekrypterar biljettbeviljarbiljetten med hjälp av sitt lösenord.

3. När klienten nu har en giltig biljettbeviljarbiljett kan den begära biljetter för all typer av nätverksåtgärder, t ex rlogin och telnet, under den tid biljettbeviljarbiljetten gäller. Den brukar gälla ett par timmar. Varje gång klienten utför en unik åtgärd i nätverket begär den en biljett för åtgärden från KDC:n.

Påföljande verifieringar

När klienten har tagit emot den första verifieringen följer alla andra verifieringar mönstret som visas i Figur 1-2:

Figur 1-2 Skaffa åtkomst till en tjänst

1. Klienten begär en biljett för en viss tjänst (t ex rlogin till en annan dator) från KDC:n och skickar sin biljettbeviljarbiljett till KDC:n som bevis på sin identitet.

2. KDC:n skickar biljetten för den begärda tjänsten till klienten.

   Antag t ex att användaren johan använder rlogin på servern boston. Eftersom han redan är verifierad (han har alltså redan en biljettbeviljarbiljett), får han automatiskt och transparent en biljett som en del av kommandot rlogin. Med den här biljetten kan han köra rlogin för att ansluta till boston så ofta han vill till dess biljetten löper ut. Om johan vill köra rlogin för att ansluta till datorn denver hämtar han en ny biljett, som i steg 1.

3. Klienten skickar biljetten till servern.

4. Servern beviljar åtkomst för klienten.

När du har läst den här beskrivningen har du kanske lagt märke till att servern inte verkar kommunicera med KDC:n under processen. Men det gör den - den registrerar sig hos KDC:n på samma sätt som första klienten gör. För enkelhets skull har den delen utelämnats.

SEAM-baserade kommandon

Vilka SEAM-baserade (eller "Kerberos-anpassade") kommandon kan då användare som johan använda sig av? De är:

• ftp

• rcp

• rlogin

• rsh

• telnet

De här programmen är desamma som Solaris-programmen med samma namn, förutom att Kerberos-principaler används för att verifiera transaktioner, vilket ger Kerberos-baserad säkerhet. (Mer information om principaler finns i "Principaler".)

Dessa kommandon beskrivs mer ingående i "SEAM-kommandon".

Principaler

En klient i SEAM identifieras genom sin principal. En principal är en unik identitet till vilken KDC:n kan tilldela biljetter. Principalen kan vara en användare, t ex johan, eller en tjänst, t ex nfs eller telnet.

Principalnamn delas in i tre delar: primär, instans och användarkategori. En typisk SEAM-principal kan t ex vara johan/admin@ENG.ACME.COMdär:

• johan är primär, vilken som i det här fallet kan vara ett användarnamn, eller en tjänst, t ex nfs. Den kan även vara ordet host, vilket visar att det är en tjänstprincipal som tillhandahåller olika nätverkstjänster (ftp, rcp, rlogin, osv).

• admin är instansen. Instansen är valfri för användarprincipaler, men obligatorisk för tjänstprincipaler. Till exempel: om användaren johan ibland fungerar som systemadministratör kan han använda johan/admin för att skilja sig från sin vanliga identitet. Om johan har konton på två olika värdar kan på samma sätt använda två principalnamn med två olika instanser (t ex johan/denver.acme.com och johan/boston.acme.com). Lägg märke till att SEAM behandlar johan och johan/admin som två helt olika principaler.

  För tjänstprincipaler är instansen ett fullständigt värdnamn. Ett exempel på en sådan instans är stordator.eng.acme.com och där kan primär/instans t ex vara ftp/stordator.eng.acme.com eller host/stordator.eng.acme.com.

• ENG.ACME.COM är SEAM-användarkategorin. Mer information om användarkategorier finns i "Användarkategorier".

Här följer en samling giltiga principalnamn:

• johan

• johan/admin

• johan/admin@ENG.ACME.COM

• ftp/värd.eng.acme.com@ENG.ACME.COM

• host/eng.acme.com@ENG.ACME.COM

Användarkategorier

En användarkategori är ett logiskt nätverk, t ex en domän, som anger en grupp system under samma huvud-KDC (se nedan). Figur 1-3 visar hur användarkategorier kan förhålla sig till varandra. Vissa användarkategorier är hierarkiska, men annars icke-hierarkiska, vilket gör att avbildningen mellan två användarkategorier måste anges. Med SEAM går det att verifiera mellan användarkategorier om varje användarkategori har en principalpost för den andra användarkategorin i sin KDC.

Figur 1-3 Användarkategorier

Användarkategorier och servrar

Alla användarkategorier innehåller en server som står för underhållet av huvudkopian av principaldatabasen. Den kallas huvud-KDC-servern. Dessutom bör varje användarkategori innehålla minst en underordnad KDC-server, med kopior av principaldatabasen. Både huvud-KDC-servern och den underordnade KDC-servern skapar biljetter som används för verifiering.

Användarkategorin kan även innehålla två ytterligare typer av SEAM-servrar. En programserver för SEAM-nätverket som ger åtkomst till Kerberos-anpassade program ( t ex ftp, telnet och rsh). Användarkategorier kan även innehålla NFS-servrar, vilka tillhandahåller NFS-tjänster med Kerberos-verifiering.

Figur 1-4 visar vad en tänkt användarkategori kan innehålla.

Figur 1-4 En typisk användarkategori