Skip to end of metadata
Go to start of metadata

Inledning

Content Studio integreras som standard med användarkatalogen Active Directory eller den lokala användarkatalogen. I Content Studio v5 .NET finns en ny och alternativ mekanism som gör det möjligt att använda externa authentiseringstjänster eller användarkataloger – både för redaktörer, administratörer och intranätanvändare.

De externa katalogtjänsterna kan vara allt från fristående databastjänster, OpenLDAP, Novell e-Directory osv. För att underlätta kommunikation mellan Content Studio och de externa användarkatalogerna bör tjänsterna kunna kommunicera via WebServices eller motsvarande teknologier, men det är inget krav.

Integration med de externa tjänsterna handlar i praktiken om att implementera ett antal händelser i Content Studio API, och knyta dessa till de externa katalogtjänsterna. För Content Studio kommer integrationen att bli helt sömnlös – detta gäller allt från användare, redaktörer, Active Scripting-komponenter och programkod.
Integrationen sker "on-the-fly", dvs när användaren försöker ansluta sig till Content Studio eller ett intranät skapad i Content Studio.

Windows integrerad autentisering

Den inbyggda autentiseringen i Content Studio är alltså baserad på att användaren identifieras mot användarkatalogen Active Directory eller den lokala användarkatalogen. Själva inloggningen mot webbservern (IIS) sker dock utanför Content Studio genom att den anonyma åtkomsten mot webbplatsen stängs av och man anger att inloggningen på webbplatsen ska vara av typen Windows Authentication. Om webbplatsen konfigureras för att tillåta anonym åtkomst kommer ingen inloggning av användare att ske och användare kan inte heller idenitifieras av Content Studio.

Då den nu inloggade användare kommer till Content Studio upptäcker systemet detta genom att det användarens session-id saknas. I detta läge anropar webbplatsen Content Studio server och dess autentiseringsmetod SessionManager.OpenSession(). Koden i denna modul kan identifiera användaren och via tekniken "impersonifiering" får tag på användarens "client access token". Client Access Token är ett digitalt bevis som utfärdas av den server som loggade in användaren då webbläsaren gick mot Content Studios webbplats.

Detta bevis innehåller användares säkerhetsidentifierare och säkerhetsidentifierare på alla de säkerhetsgrupper som den inloggade servern anser att användaren är medlem i. Den server som sköter inloggningen kallas "authority" eller utfärdare och kan under inloggningsprocessen även behöva konsultera sin egen utfärdare för att inhämta mer uppgifter om användaren. Det sistnämnda inträffar då både webbservern och användaren är medlem i samma Active Directory.

Webbservern får då en lista över användarens domängrupper vilken bara kan sammanställas av en domänkontrollant. En mycket viktig term i dessa sammanhang är säkerhetsidentifieraren eller SID och som används överallt i Content Studio, liksom i operativsystemet, för att identifiera en person eller säkerhetsgrupp samt ange vad dessa för göra på ett viss objekt (exempelvis ett dokument eller en mapp) i systemet.

Beskrivning av SecurityIdentifier (SID)

En SID är en binär identifierare med dynamisk längd av ett säkerhetsindivid (Trustee) i Microsofts säkerhetssystem. Säkerhetsindivider kan vara av flera slag där de viktigaste är användare, säkerhetsgrupper, kända grupper, alias och datorer. En SID är garanterat unik inom en säkerhetsdomän och ett Active Directory samt med mycket hög sannolikhet unik gentemot andra domäner i världen. Kända grupper och alias är dock lika i alla installationer.

Varje skyddat objekt (och det är så gott som alla förekommande objekt) i Microsoft Windows har en säkerhetsbeskrivning kopplad till sig och SID används för att identifiera ägaren till objektet. Varje säkerhetsbeskrivning har en åtkomstkontrollista som beskriver vilka som får eller inte för göra vad på objektet och varje post i listan innehåller en säkerhetsindivid och beskriver vad individen får göra.

En SID är alltså en binär struktur av dynamisk längd som inte är läslig för människan men som i programspråket C++ kan skrivas som t.ex.
0x0105000000000005150000004E6ED07AA0149F4A6872FE2450040000

För att visa en SID eller lagra den på annat sätt finns även en textversion t.ex.
S-1-5-21-2060480078-1251939488-620655208-1104

Content Studio och SID

Content Studio integrerar sig mot Microsoft Windows säkerhetssystem via SID som kan förekomma både i binär form och i textform. Även Content Studio har säkerhetsbeskrivningar och åtkomstkontrollistor som fungerar på samma sätt som i filsystemet. Dessutom speglas de SID i Content Studio som rör behörigheten "Läsa på webbplats" till det underliggande filsystemet som behörigheten Read/Execute. I filsystemet lagras också SID för Content Studio runtime som är den enda säkerhetsindivid som garanteras fullständig behörighet till alla filer och kataloger.

Förutsättningar för extern autentisering

Det är inte alltid att extern autentisering är det som föredras inom en organistation, kanske finns en extern användarkatalog som används av flera befintliga system och man bedömmer att detta system ger fler fördelar än de nackdelar det innebär att sköta identifieringen av användare externt.

Eftersom Content Studio integrerar sig så intimt på alla ställen med Windows behöver det externa systemet på många sätt "imitera" Windowssystemet och använda samma typer av säkerhetsidentifierare, SID. För detta ändamål tillverkar man en programvara, en modul som tjänar som brygga mellan Content Studio och den externa användarkatalogen.

Krav på extern auteniseringsmodul

En extern modul ska verifiera användaren mot den externa katalogen och kunna få svar på följande frågor.

  • Vilken säkerhetsidentifierare (SID) har användaren?
  • Vilka grupper i det externa systemet ingår användaren i?
  • Vilka kända windowsgrupper är användaren medlem i?

Dessa frågor verkar till en börja vara omöjliga att ge svar på om man inte pratar med en Windowsbaserad användarkatalog, men en SID är en generell struktur som inte kräver en Windowsmiljö för att fungera eller för att vara giltiga. De kan mycket väl vara giltiga i ett annat system än i Windows och kan därför utfärdas av olika typer av system. Den externa auteniceringsmodulen skrivs i .NET 2.0 och ska ärva från basklassen AuthenticationBase i namnrymden ContentStudio.Security i Content Studio server API. Där finns metoder för att registrera användare samt registrera de grupper användaren är medlem i.

Baserat på de identifierare på användaren och grupperna som den externa katalogen returnerar konstruerar auteniceringsmodulen de säkerhetsidentifierare som behövs. Det är viktigt att dessa är fullt reproducerbara så att de alltid får samma värden för samma användare. De identifierare som genereras bör vara möjliga att skilja från de som används i Windows och för detta ändamål innehåller en SID fältet authority, utgivare.

Om vi betraktar SID:en S-1-5-987549-53253-364 är utgivaren identifierad med den andra siffran i sekvensen, 5. Windows använder bara de värdena 0 till 5 och man kan därför använda ett eget värde som skiljer sig från dessa. Dessutom finns värdet 9 dokumenterat och tanken med den är att den ska representara ett tredjepartssystem. Man kan alltså använda detta värde men även andra avvikande värden borde duga i detta sammanhang. Om Content Studio finner en SID med en okänd utgivare kommer dessa behörigheter inte att speglas till filsystemet eftersom de inte har någon mening där.

Autentiseringsmodulen blir en del av Content Studio server och måste därför konfigureras att köras i samma context som denna och via remoting. Det sistnämda konfigureras enkelt via webbplatsens och Content Studio servers konfigurationsfiler.

Då användaren är identifierad och gruppernas identifierare finns ska användaren registreras i Content Studio. För detta ändamål finns metoden RegisterUser som returnerar användarens sessionsidentifierare. Efter detta registreras de grupper som användare är medlem i och som har registrerats i Content Studio och för detta ändamål finns metoden BuildUserGroupMappings().
I samband med registreringen av användaren registreras följande uppfter:

  • SID
  • Domännamn
  • Inloggningsnamn
  • Fullständigt namn
  • Kort beskrivning (kan utelämnas)
  • Datum då konton upphör att gälla
  • Epostadress (kan utelämnas)

Användarnamn och domännamn i kombination ska vara unikt i systemet och SID måste vara unikt. Det är autenticeringsmodulen uppgift att hålla reda på detta med hjälp av uppgifter från i första hand det externa systemet. Det är också möjligt att ange ytterligare uppgifter om användaren som kan hämtas från katalogen några av dem är fördefinierade i Content Studio andra kan man själv skapa. De fördefinierade fälten är

  • title
  • office
  • address
  • zip
  • city
  • country
  • phone
  • cellphone
  • fax
  • company
  • homephone
  • startdoc (anger startsida i Content Studio)
  • infodoc (anger personlig startsida i Content Studio)
  • webviewbool (anger om trädvyn ska visas)
  • pflang (anger användarens språkinställning)

Dessa uppgifter anges med hjälp av klassen UserProperties i namnrymnden ContentStudio.Security.

Webbplatsen vid extern autenisering

Vid extern autenisering sätter man upp en Content Studio-webbplats på valigt sätt med Windowsautentisering denna används för administrativa och avancerade ändamål. Parallellt med denna sätts webbplatsen som integerar ot det externa systemet upp. Denna pekar på samma filer och utnyttjar samma underliggande database (sk. multihoming) men sätts upp att stödja anonym åtkomst.

Då Content Studio upptäcker att en användare är anonym och saknar sessionsidentifierare kontrolleras via en inställning om denna webbplats använder externe autentisering och om så är fallet omdirigeras användare till en sida som loggar in användaren mot det externa systemet. Användaren kan också vara inloggad mot en webbportal och i sädana fall identifieras hon via en cookie som autentiseringsmodulen förstår och som används mot den externa katalogen.

Content Studio under extern autentisering

Eftersom användaren har en giltig sessionsidentifierare men en extern SID och är mappad till grupper från det externa systemet som är registrerade fungerar Content Studios kraftfulla behörighetssystem precis som vanligt. Den mest tydliga skillnaden är att behörigheter i filsystemet inte synkroniseras med de i ContentStudio eftersom de externa identifierarna inte har någon mening i Windows och som sådana skulle varken neka eller bevilja något i filsystemet.


Labels
  • None