Technical information about AKKA

Uppsala universitet har ett antal olika tekniska möjligheter att koppla inloggningar i applikationer mot universitetets gemensamma katalog- och behörighetssystem AKKA. På denna sida beskrivs dessa inloggningsmetoder på ett övergripande plan men också ur universitetets perspektiv prioritering mellan de olika lösningarna.

Webbapplikationer

Prioritet 1: SAML2-baserad inloggning

Att använda den av OASIS standardiserade Interoperable SAML 2.0 Web Browser SSO Deployment Profile är tekniskt och funktionellt den bästa lösningen för webbapplikationer. Förutom inloggnings­möjlig­heten är det via s.k. attributöverföring möjligt att överföra information i samband med inloggningen, t.ex. namn, e-postadress, organisatorisk tillhörighet och roller.

I en webbapplikation är det enkelt att integrera SAML2 genom att en webbservermodul, den rekommenderade är Shibboleth från Internet2 (http://shibboleth.net). Efter konfiguration av webbservermodulen är det väldigt enkelt för applikationen att få inloggningsinformation och attributen som har förts över, dessa finns i webbservervariabler på samma sätt som användaridenti­teten finns i remote_user vid inloggningstypen basic authentication. Shibboleth Native Service Provider (SP) finns för Apache och Internet Information Services. Det går även använda att använda Windows Identity Foundation (WIF) tillsammans med Active Directory Federation Services (AD FS) 2.0 i en windowsmiljö.

För mer information se Gemensam webbinloggning.

Prioritet 2: Central Authentication Service (CAS) för webbapplikationer

CAS (http://www.jasig.org/cas) är en äldre och enklare inloggningsteknik än SAML2. CAS kan med hjälp av 10 rader kod inkluderas i princip vilken webbapplikation som helst men CAS kan endast hantera inloggning, och ingen attributöverföring. Färdiga officiella CAS-moduler finns för Java, PHP, .Net och Apache. Information om användarens, dess roller och dess organisatoriska tillhörigheter hämtas via LDAP.

Läs mer under rubriken "Jasig Central Authentication Service project (CAS)" nedan.

Prioritet 3: Inloggning mot LDAP-katalog

All information som finns registrerad i AKKA finns i en LDAP-katalog. Mot denna LDAP-katalog är det möjligt att göra lösenordsbaserad inloggning men också att hämta upp information om användaren, t.ex. namn, e-postadress och roller, och de organisationsenheter denne tillhör. För att få en fullständig bild över användaren och den information som är kopplad till denne måste flera LDAP-sökningar genomföras. Det finns en fullständig dokumentation över universitetets LDAP-specifikation som kan fås efter begäran.

Läs mer under rubriken "Använda information från AKKA via protokollet LDAP" nedan.

Prioritet 4: Inloggning mot Active Directory

Inloggningsinformationen i AKKA finns även med särskilt lösenord speglat i universitetets gemensamma Active Directory. Informationen om användarna i Active Directory är begränsat till i princip namn, e-post och organisatorisk tillhörighet via grupper och nästlade grupper (grupper i grupper). Universitetets användare ofta är ute och reser eller arbetar från annan plats än universitetets nät och därför är Kerberos via SPNEGO inte att föredra som enda möjliga inloggningsteknik i webbapplikationer.

För mer information se Active Directory.

Feta klienter och mobilappar

Prioritet 1: Inloggning via OAuth 2.0

OAuth2 (http://oauth.net/2/) är en öppen standard för auktorisering av uppgifter som användaren har, t.ex. namn, e-post och organisatorisk tillhörighet. I och med att en användare auktoriserar en applikation att komma åt information om användaren från AKKA har användaren även loggat in i applikationen. Användaridentitet och lösenord sparas inte i klienten utan det skapas särskilda inloggningsuppgifter för användaren för just denna applikation. Denna typ av lösning fungerar alldeles utmärkt för feta klienter såsom klienter för administrativa system och för mobilappar. Exempel på tjänster som använder OAuth2 2.0 är Facebook, Google och Windows Live.

Prioritet 2: Inloggning mot LDAP-katalog

Se ovan.

Prioritet 3: Inloggning mot Active Directory

Se ovan.

Gemensam webbinloggning är en samling tekniker för att tillåta användare med vanliga webbläsare, t.ex. Internet Explorer, Firefox och Safari, att logga in på flera webbaserade applikationer med en enda inloggning istället för en inloggning per webbaserad applikation. Förutom att användaren alltid känner igen inloggningsidan exponeras användarens lösenord endast för Gemensam webbinloggning. Gemensam webbinloggning är byggt på applikationen Shibboleth v2 som använder SAML2 WebSSO genom identitetsfederationen SWAMID men är även tillgängligt genom det äldre protokollet Jasig Central Authentication Service project version 2 (även känt som CASv2).

CAS och SAML2 WebSSO kompletterar varandra på så sätt att det äldre protokollet CAS är väldigt enkelt använda i en webbapplikation men har begränsningen att endast användare vid Uppsala universitet kan logga in. Om det inte redan finns en färdig CAS-klient som passar webbapplikationen är det enkelt att göra en egen anpassning på ca 10-30 rader kod. Läs mer under rubriken "Jasig Central Authentication Service project (CAS)" nedan

SAML2 WebSSO är däremot en mer komplex lösning än CAS men kan förutom inloggning för användare vid Uppsala universitet även tillhandahålla inloggning för de flesta universitet och högskolor i Sverige samt ett stort antal lärosäten i övriga Norden. Förutom själva inloggningen kan information om användaren, t.ex. namn, e-postadress, roller osv., överföras i samband med inloggningen. Uppsala universitet ingår i identitetsfederationen SWAMID (SWedish ACadeMic IDentity) och den akademiska interfederationen eduGAIN. Vill du se exempel på information vi kan skicka över via SAML2 WebSSO gå till https://sp.swamid.se och välj att logga in via SWAMID och därefter Uppsala universitet. Information om SWAMID och användning av SAML2 WebSSO finns på SWAMIDs Wiki.

Gemensam webbinloggning fungerar inte för alla webbtjänster, t.ex. de som skickar vidare användaridentitet och lösenord till en underliggande applikation för inloggning och eventuellt behörighetskontroll. Ett exempel på detta är IIS-baserade webbtjänster som använder säkerhetsmodellen i filsystemet i Windows för access- och behörighetskontroll. Kommersiella webbapplikationer är inte alltid möjliga att anpassa men eventuellt kan dessa använda LDAP för inloggning.

AKKAs LDAP-servrar är AKKAs ansikte utåt och det är primärt dessa som olika applikationer använder direkt eller indirekt för komma åt informationen som finns i AKKA. När information i AKKA ändras i AKKAs databas uppdateras informationen i LDAP inom någon minut.

Det finns tre olika sätt att komma åt AKKAs LDAP:

• En feltollerant lastdelad fullständig LDAP som är tillgänglig efter särskilt godkännande.
• Publik LDAP tillgänglig från hela världen efter inloggning.
• Publik LDAP tillgänglig inom universitetet utan inloggning.

Fullständig LDAP

Den fullständiga LDAPen innehåller all aktuell information som finns i AKKA. Åtkomsten till den skyddade LDAPen är begränsad till endast godkända tjänster och applikationer. Tillgång till AKKAs fullständiga LDAP ges efter ansökan till AKKAs förvaltningsorganisation, se se "Specifikation av implementation av LDAP-schema nedan". I ansökan ska ingå vilken applikation som ska få tillgång till den fullständiga LDAPen samt en kort beskrivning av applikationen och vad applikationen kommer att använda informationen i LDAP till.

Den fullständiga LDAPen kan användas till följande:

• Kataloginformation för alla organisatoriska enheter vid universitetet.
• Kataloginformation för alla anställda och övriga verksamma vid universitetet.
• Inloggning i applikationer för anställda, studenter, övriga verksamma och gäster vid universitetet.
• Användaruppgifter för anställda, studenter och övriga verksamma med aktiva användarkonton.
• Vem som får göra vad i ett antal applikationer (rollhantering).

Publik LDAP

Den publika LDAPen innehåller endast kataloginformation om universitetets organisation samt information om anställda och övriga verksamma. Informationen är dessutom begränsad till sådan som får visas publikt, d.v.s. varken är skyddad eller dold. Detta gör den publika LDAPen lämplig för att använda i e-postprogram men även för applikationer som ska visa information publikt över webben. För information om åtkomst till publik LDAP se "Specifikation av implementation av LDAP-schema nedan".

Den publika LDAPen kan användas till följande:

• Publik kataloginformation för organisatoriska enheter vid universitetet.
• Publik kataloginformation för anställda och övriga verksamma vid universitetet.

AKKA är Uppsala universitetets centrala system för hantering av kataloguppgifter, identiteter (konton), autentisering, auktorisering och styrning av IT-tjänster såsom e-post, webbuppdatering och anslutningstjänster, t.ex. VPN-pooler. Protokollet LDAP är förutom en av modellerna som finns för att tillhandahålla information ur AKKA till andra applikationer även oftast källan till informationen för övriga varianter som tillhandahåller information ur AKKA.

Bifogat dokument definierar AKKAs implementation av LDAP-struktur och scheman. Utgångspunkten vid designen av implementationen har varit att göra så lite ”egna” lösningar som möjligt utan att istället så långt som möjligt använda färdiga scheman från The Internet Engineering Task Force (IETF) och universitetssfären genom Internet2 (http://internet2.edu), Terena (http://www.terena.org), GNOMIS (http://www.gnomis.org) och SWAMI (http://www.swami.se). I de fall där det inte funnits etablerade lösningar har så långt som möjligt etablerats nya lösningar inom ramen för samarbetsorganisationen SWAMI.

AKKA använder version 3 av LDAP-protokollet samt LDAP-servern OpenLDAP för både publik och fullständig LDAP. Vidare används attributoptioner för hantera språk och överlagrad information på enskilda attribut. Dynamiska filter byggda på attributvärden används för att hantera skyddad och dold information.

Specfikationen av AKKAs LDAP-implementation finns i dokumentet "Implementation av LDAP-schema för AKKA Pdf, 641 kB."

Läsanvisningar:

• Sid 6-7: Grundläggande information och åtkomst till publik och fullständig LDAP
• Sid 8-13: Kataloginformation, d.v.s. information om universitetets organisation och dess anställda och övriga verksamhet
• Sid 14-15: Kontoinformation för alla typer av konton i AKKA (undantaget gästidentiteter)
• Sid 16: Kontoinformation för gästidentiteter
• Sid 17-18: Information om generell hantering av skyddade och dold information
• Sid 19-21: Information om roller och funktioner
• Sid 21: Information om ansvarsförbindelser
• Sid 22: Information om förttroendenivåer kopplade till egitimationskontroller
• Sid 21-23: Hur man använder LDAP för autentisering (inloggning)
• Sid 24-61: Detaljerade specifikationer för attribut och objektklasser
• Sid 62-63: Referenser till externa LDAP-scheman
• Sid 64-73: Definitioner av AKKAs lokala attribut och objektklasser