Att använda en inloggningstjänst i en applikation

Innehåll:

Uppsala universitet har ett antal olika 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.

För mer information se CAS.

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.

För mer information se LDAP.

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.