Instruktion för integration mot CAS

Transkript

1 IT-enheten Instruktion för integration mot CAS Per Hörnblad Instruktion Sid 1 (7) Instruktion för integration mot CAS Projektnamn Instruktioner för Integration mot CAS Fastställt av Per Hörnblad Dokumentansvarig Per Hörnblad Dokumentidentitet Version 1.2 Datum Status Fastställt

2 Dokumenthistorik Version Datum Ändrad av Utförda förändringar Bo Sehlberg Skapat dokumentet Per Hörnblad Reviderat dokument Per Hörnblad Reviderat dokument Per Hörnblad Mindre upprättning Innehållsförteckning INSTRUKTION FÖR INTEGRATION MOT CAS INLEDNING MÅLGRUPP TERMINOLOGI FÖRUTSÄTTNINGAR ALLMÄNT OM CAS INFRASTRUKTUR GÄLLANDE CAS PÅ UMEÅ UNIVERSITET Inledning Användarnamn Certifikat Test och testanvändare Användarattribut Proxande autentisering INSTRUKTIONER INLOGGNING AUTENTISERING I APPLIKATIONEN AUKTORISERING UTLOGGNING...7

3 1 Inledning Syftet med detta dokument är att beskriva de regler som gäller för hur system skall integrera med den centrala autentiserings tjänsten vid Umeå Universitet. Alla system skall implementera integrationen på ett enhetligt sätt. Den centrala autentiserings tjänsten är baserad på CAS (Central Authentication Service) som är en öppen programvara som förvaltas av Ja-Sig. 2 Målgrupp Systemutvecklare, arkitekter och ägare för system som ska ansluta sig till CAS-inloggning vid Umeå Universitet. 3 Terminologi Begrepp CAS Beskrivning Central Authentication Service SAML Security Assertion Markup Language Shibboleth Ett öppen källkodspaket för webbaserad single sign-on mellan eller inom organisatoriska gränser. simplesamlphp Ett öppen källkodspaket för webbaserad single sign-on mellan eller inom organisatoriska gränser. CWAA Ett öppen källkodspaket för webbaserad single sign-on mellan eller inom organisatoriska gränser. Radius Remote Authentication Dial-In User Services, är ett nätverksprotokoll som används för autentisering av användare och inkopplade utrustning på nätverk mot en central databas, men även för att hantera rättigheter LoA Level of Assurance, förtroendenivåer d v s hur säker man kan vara på en identitet. CAS-brukare Den tjänst (applikation) som använder CAS för inloggning

4 4 Förutsättningar 4.1 Allmänt om CAS Dokumentation om hur CAS fungerar och är uppbyggt återfinns på adressen Klienter och exempel för ett flertal olika programspråk och system återfinns på CAS använder sig av s.k. http(s)-redirects (dvs. att man omdirigerar adressen som anges i användarens webbläsarklient) mellan klienten, den applikation (tjänst) man vill använda sig av, samt själva autentiseringstjänsten (CAS). Dessutom används s.k. engångsbiljetter, vilket innebär att en biljett som utfärdas av autentiseringstjänsten till klienten endast är giltig för en inloggning, därefter måste användaren autentisera sig på nytt. Nedan följer ett flöde som beskriver autentiserings förfarandet vid CAS. 1. Användaren ansluter via sin webbläsare till den önskade tjänsten och klickar där på "Logga in". 2. Användaren skickas då automatiskt (redirect) vidare till autentiseringstjänsten. 3. Användaren fyller, på autentiseringstjänstens startsida, i sitt användarnamn och lösenord och klickar på knappen "Logga in" 4. Autentiseringstjänsten kontrollerar att angivet användarnamn och lösenord är korrekt mot en underliggande datakälla där dessa finns lagrade. 5. Om användarnamnet och lösenordet var korrekt utfärdas en biljett (ticket) och användaren skickas automatiskt tillbaka (redirect) till den önskade tjänsten. I samband med detta sätts också en cookie i användarens webbläsare för att autentiseringstjänsten vid en ev. senare inloggning ska kunna se

5 att användaren redan är inloggad. Är användarnamnet och/eller lösenordet felaktigt ombeds användaren att ange det igen. 6. Den önskade tjänsten kontrollerar (validerar) mot autentiseringstjänsten att den nyss anlända biljetten är korrekt och giltig. 7. Ifall biljetten är korrekt och giltig svarar autentiseringstjänsten på den önskade tjänstens kontroll genom att skicka svaret "yes" samt användarens användarnamn. Är biljetten ogiltig eller felaktig svarar autentiseringstjänsten med ett "no" och användaren tillåts ej få access till den efterfrågade tjänsten. 8. Användaren får access till den efterfrågade tjänsten. 4.2 Infrastruktur gällande CAS på Umeå Universitet Inledning Umeå universitet har implementerat CAS i den form som CAS levereras, bortsett från att användarnamn med gemener returneras när en biljett verifieras oavsett hur användarnamnet angivits. Den server som används i dagsläget är CAS 3.x Användarnamn Användarnamn består alltid av åtta tecken och med en blandning av bokstäver och siffror. Användarnamn kan endast bytas under särskilda omständigheter. När så sker kommer den unika identifierare som finns på alla objekt (inkl användarnamn) i vår katalogtjänst inte att förändras utan endast uppdateras med det nya användarnamnet. System som använder CAS bör därför även implementera en anslutning mot katalogtjänsten (via SAML eller direkt via LDAP) för att kunna hantera byten av användarnamn och lagra den unika identifieraren i stället för användarnamnet som nyckel i sitt system. Detta är dock inget krav utan ett val som systemägaren måste göra Certifikat CAS-servern använder sig av certifikat som signerats av Terena. Rotcertifikat för dessa återfinns på Test och testanvändare Umeå universitet tillhandahåller inga användare för teständamål. Om det behövs en bakdörr till systemet för att kunna utföra tester i detsamma är det upp till systemägaren att lösa detta i systemet. Ett alternativ är att använda sig av den CAS-server som finns för teständamål på adressen Denna server accepterar valfritt användarnamn och samma lösenord som det användarnamn man angett Användarattribut Inga användarattribut utöver användarnamn erhålls från CAS. Om användarattribut behövs i applikationen skall dessa hämtas från den centrala katalogtjänsten, eller utnyttja SAML2- inloggning via idp.umu.se.

6 4.2.6 Proxande autentisering Umeå universitet tillåter inte av säkerhetsskäl att applikationer använder proxande autentisering via CAS enligt CAS-protokollet (version 2). 5 Instruktioner 5.1 Inloggning Inloggning skall göras genom en medveten handling från användaren dvs. genom ett klick på en länk eller en knapp, som tydligt anger vad användaren skall göra. Systemet bör använda sig av benämningarna Logga in, Logga in via CAS eller de engelska motsvarigheterna. Systemet skall inte kräva att inloggningslänken ligger på det aktuella systemet, utan skall kunna ligga på en fristående sida. När användaren väljer att använda inloggningslänken skall användarens webbläsare omdirigeras till autentiseringsservern på följande sätt: där xxx är adressen till den funktion som skall erhålla den biljett som utfärdats av CAS efter en genomförd autentisering. Applikationen skall vid omdirigering inte förändra storleken på webbläsarfönstret, undanhålla adressfältet eller på annat sätt försöka dölja funktioner i detsamma. Omdirigeringen skall göras av hela webbläsarfönstret, dvs inte ske i en frame eller på något motsvarande sätt. 5.2 Autentisering i applikationen Efter en lyckad autentisering kommer applikationen att erhålla en engångsbiljett från CAS till den url som angetts i inloggningslänken. Detta innebär att användaren efter autentisering kommer att vidarebefordras till applikationen på formen Applikationen skall i samband med detta ta emot angiven biljett (ST-xyz123) och validera denna emot CAS. Detta sker genom att göra en uppkoppling emot en specifik url tillsammans med erhållen biljett och den url som biljetten utfärdats till. Validering av biljetten skall ske mot Exempel: icket=st-8290-dfrcurz84k0m5gzpcc7r CAS kommer vid en lyckad verifiering av den tjänst och biljett som angavs att svara yes / no samt user vilket medför att man får reda på att det var en lyckad autentiseringsförfrågan och vilket användarnamn som erhållit den aktuella biljetten. Därefter kan målapplikationen ge användaren tillgång till den efterfrågade tjänsten. Om autentiseringen misslyckas kommer CAS att svara no. Detta sker vid två olika tillfällen, antingen då fel användaruppgifter angivits eller om biljetten inte längre är giltig. Det sista inträffar då biljetten redan använts, (CAS använder engångsbiljetter) eller om tiden från det att biljetten utfärdades överskridit en viss tidsperiod.

7 5.3 Auktorisering Alla CAS-brukare som inte ska vara allmänt tillgängliga inom UmU, måste ha möjlighet att göra behörighetskontroll (via SAML 2.0 eller direkt via LDAP) för att säkerställa att användaren har rätt att använda tjänsten. I vissa fall är det nödvändigt för applikationer att hantera detta lokalt genom att hålla information om vilka användare som har behörighet till tjänsten. Dock skall denna lösning undvikas i största möjliga mån. Om fallet är så att CAS inloggning är lyckad men användaren är inte behörig att använda tjänsten så skall detta meddelas till användaren. 5.4 Utloggning När användaren väljer att avsluta sessionen med aktuellt system skall det finnas en utloggningslänk där det står Avsluta eller Logga ut. Efter att användaren klickat på länken skall sessionen med systemet avslutas och användaren bör mötas av ett meddelande som säger Du har avslutat din session med xxx. Du är fortfarande inloggad via CAS. Besök för att logga ut. Glöm inte att stänga alla webbläsarfönster när du är färdig..