Nu finns ADFS Toolkit 2.0.0 i skarp version!
Efter en lång tids utveckling och testande har vi äntligen kunnat släppa den nya versionen av ADFS Toolkit. 
Det är mycket som hänt sedan 1.0.0.0 och modulen har betydligt fler konfigureringsmöjligheter än tidigare och är mer robust och uppgraderingsbar.
Vi uppmanar alla som kör en Release Candidate att uppdatera till den skarpa versionen.
För att läsa mer om vad som ändrats, läs release notes på GitHub:
https://github.com/fedtools/adfstoolkit/releases/tag/v2.0.0
Dokumentation kring hur man installerar eller uppgraderar finns också på GitHub:
https://github.com/fedtools/adfstoolkit
Läs igenom instruktionerna noga innan uppgradering. Det är lite olika steg som behöver göras vid uppgradering från 1.0.0.0 till 2.0.0.
Vidare uppgraderingar kommer gå betydligt lättare!
Upplever du några problem eller har funderingar, kontakta operations@swamid.se
Inloggning med hjälp av SWAMIDs infrastruktur används idag i väldigt många tjänster, t.ex. Ladok, Prisma, Box och det nationella antagningssystemet. För att inloggningen ska fungera behöver vissa personuppgifter såsom attribut överföras från identitetsutfärdare (IdP) till tjänsten (SP). Inom SWAMID använder vi s.k. entitetskategorier för att organisera hanteringen av dessa attribut. Sedan Sunetdagarna hösten 2019 har SWAMID genomfört flera aktiviteter för att underlätta lärosätenas, och övriga organisationers, hantering av dessa entitetskategorier, med speciellt fokus på Microsoft-miljöer.
I arbetet med att göra överföringen av attribut mer strömlinjeformad och mer i andan av gällande personuppgiftslagstiftning beslutades det hösten 2019 att de gamla entitetskategorierna SWAMID Research and Education och SFS 1193:1153 (även kallat R&S respektive SFS) avvecklas och ersätts med utökad och tydligare användning av REFEDS Research and Scholarship (R&S) och GÉANT Data Protection Code of Conduct (CoCo). All användning av personnummer överförs till CoCo beroende dels på att personnummer används i fler tjänster än studentrelaterade och att CoCo ställer tydliga krav på att tjänsten tydligt måste informera användarna om hur personuppgifterna används.
Från och med 1 september i år har vi börjat flytta över tjänster från de gamla entitetskategorierna till de två som vi behåller och uppdaterar användningen av. Detta kommer att innebära att användare vid organisationer som ännu inte infört uppdaterat stöd för R&S och CoCo i sin identitetsutfärdare (IdP) inte längre kommer att kunna logga in i de tjänster som har flyttats över till den nya hanteringen. Användarnas problem kommer att smyga sig på tjänst för tjänst och kommer för lärosätena att bli väldigt tydlig när tjänster såsom Ladok och det nationella antagningssystemet flyttas. I och med detta får inte heller några nya tjänster de gamla entitetskategorierna (R&E respektive SFS).
Identitetsutgivarna för Antagning.se och eduID.se hanterar idag korrekt de entitetskategorier som kommer att användas i SWAMID framöver och därför har vi nu påbörjat arbetet tillsammans med de som äger tjänsterna att flytta över tjänster som kräver personnummer till entitetskategorin CoCo. Detta betyder att samtliga kontoaktiveringstjänster vid lärosätena som kräver personnummer snarast behöver flytta från den gamla SFS-kategorin till CoCo. Samtidigt måste alla identitetsutfärdare som har användare som loggar in i Antagning.se, Universityadmissions.se och Ladok för studenter se till så att de stödjer överföring av personnummer via entitetskategorin GÉANT Data Protection Code of Conduct (CoCo).
För att kontrollera att er identitetsutfärdare (IdP) är konfigurerad korrekt finns SWAMIDs testverktyg:
För er som har studenter och personal som loggar in i Ladok så finns ett specifikt test för just Ladok:
Om ni har några frågor och funderingar kontakta SWAMID Operations på operations@swamid.se.
SWAMID operations har tagit fram ett "How-to" dokument för uppgradering av Shibboleth Identity Provider till version 4.
Shibboleth IdP v3 är end-of-life vid årsskiftet 2020-12-31 på grund av att Spring framework 4.3 som den använder är också end-of-life.
SWAMIDs rekommendation är att göra en uppgradering av befintlig IdPn och inte en nyinstallation. För att uppgradera måste man ha redan anpassat sina attribute-resolver och attribute-filter till nyare syntax (för v3.4). I samband med uppgraderingen måste man också byta Java och Jetty till nyare versioner. Därför ska man räkna med ett litet längre driftavbrott (vår erfarenhet är runt 30 minuter).
Läs mer: Shibboleth IdPv4 uppgradering
Shibboleth konsortiet har publicerat en sammanfattning av deras testning av Chrome SameSite förändringen. Det finns på [1].
SWAMID operations rekommenderar att läsa igenom informationen. Man kan testa det nya beteendet med Google Chrome genom att sätta [2] till enabled i Chrome 79. Från och med Chrome 80 blir denna inställningen default.
Det finns en patch för ADFS som man måste installera för Windows Server 2016. Information om patchen finns på [3].
Det är för stunden svårt att begripa vad konsekvenserna kommer att bli under februari. Det finns en risk att det sker förändringar hos Service Providers som kommer att medföra olika beteende beroende på användares val av webbläsare, framför allt mellan de som kör Chrome 80+ resp Safari på macOS 10.14 och äldre samt Safari på iOS 12 och äldre. En beredskap för att det kan komma att rapporteras in udda användarproblem rekommenderas därför.
[1] https://wiki.shibboleth.net/confluence/display/IDP30/SameSite
[2] chrome://flags/#same-site-by-default-cookies
[3] https://support.microsoft.com/sv-se/help/4534271/windows-10-update-kb4534271
Inom SWAMID har vi länge använt villkorsstyrd automatiserad attributrelease genom s.k. entitetskategorier för att på ett standardiserat sätt överföra personuppgifter i samband med inloggningen från hemmaorganisationens identitetsutfärdare till den webbtjänst som användaren försöker logga in i. SWAMID Operations har under en längre tid jobbat med att ta fram en ny best practice för hur identitetsutgivare släpper attribut till olika webbtjänster för att göra detta både enklare och tydligare. På Sunetdagarna i Falun under hösten presenterade vi SWAMIDs nya best practice.
I korthet innebär förändringen att SWAMIDs egna entitetskategorier SWAMID Research & Education och SWAMID SFS 1993:115 kommer att avvecklas och ersättas med REFEDS Research and Scholarship (R&S) och GÉANT Dataprotection Code of Conduct (CoCo). Vi har flyttat överföring av personnummer till entitetskategorin CoCo dock med vår rekommenderade begränsning att personnummer endast släpps till tjänster registrerade i SWAMID.
Tidplan för förändringen
- Från och med nu får nya tjänster både de gamla och de nya entitetskategorierna.
- Från och med 2020-05-01 får inga tjänster längre SWAMID Research & Education och SWAMID SFS 1993:1153 inlagda i metadata.
- Från och med 2020-10-31 kommer metadata vara rensat från de avvecklade entitetskategorierna.
I korthet betyder detta att före 1 maj nästa år bör ni ha uppdaterat ert system så att ni kan hantera SWAMIDs nya best practice. Ni behöver inte ta bort SWAMIDs gamla entitetskategorierna förrän vi säger till i slutet på nästa år.
Hur vet jag som tjänsteleverantör om min tjänst är berörd av förändringen av SWAMIDs Best Practice?
På wikisidan SWAMID Service Providers including interfederations finns en lista på samtliga tjänster som är tillgängliga inom SWAMID. Det enklaste sättet att ta reda på om ni berörs av förändringen är att leta upp er tjänst i listan och därefter titta i kolumnen Entity Categories. Står det research‑and‑education eller sfs‑1993‑1153 berörs ni av förändringen.
Vad behöver jag som tjänsteleverantör göra för att fortsätta få attribut?
Om ni idag har en tjänst registrerad i SWAMID som får attributrelease genom de gamla entitetskategorierna SWAMID Research & Education och SWAMID SFS 1993:1153 behöver ni titta på vilken av entitetskategorierna REFEDS Research and Scholarship (R&S) och GÉANT Dataprotection Code of Conduct (CoCo) som passar er bäst. På wikisidan Entity Categories for Service Providers finns det beskrivet vad som gäller för de bägge entitetskategorierna. Är det så att ni i er tjänst måste använda personnummer så är det GÉANT Dataprotection Code of Conduct som gäller. Under perioden 2020-05-01 till 2020-10-31 måste ni som använder SWAMIDs gamla entitetskategorier uppdatera till de två som kommer att finnas i framtiden.
Hur gör vi i vår identitetsutfärdare för att följa den nya best practice?
- För Shibboleth IdP har SWAMID Operations tagit fram nya exempelfiler på SWAMID s wiki för attributresolver och attributfilter tillsammans med en uppdaterad rekommendation av hur personnummer hanteras.
- För ADFS håller SWAMID Operations på att ta fram en ny version av ADFStoolkit, mer information kommer när den är klar.
SWAMIDs nya testverktyg för entitetskategorier
SWAMID Operations håller även på att skapa ett nytt testverktyg för att testa att man som identitetsutfärdare följer den nya rekommendationen. Denna finns redan i beta på adressen https://release-check.swamid.se/ men allt fungerar ännu inte, t.ex saknas sista testet samt informationstexter som beskriver test och resultat.
Vad händer nu?
Mer information kommer att skickas ut framöver och vi kommer att hålla minst ett webinar framöver.
SWAMID har på wikisidan Entity Category attribute release in SWAMID gjort en tydlig tabell över vilka attribut som ingår i vilka entitetskategorier. Observera att CoCo är lite krångligare eftersom endast attribut som begärs ska släppas.
Shibboelth IdP använder Jetty som applikationsmotor och under senaste tiden har det upptäckts 5 säkerhetsbrister i Jetty[1]. Detta gör att ni som använder Shibboleth IdP inom SWAMID måste uppdatera era installationer av Jetty. Linux- och Windowsinstallationerna av Shibboleth IdP uppdateras med två olika metoder.
Linux
Om ni har använt SWAMID installationsscript för att installera Shibboleth IdP och inte uppdaterat Jetty tidigare kan ni följa instruktionerna på wikisidan Uppgradera Jetty[2], detta gäller även om du installerat på annat sätt men använder Jetty 9.2.x. Om du använder Jetty 9.3.x kan du eventuellt behöva anpassa uppdateringen.
Windows
Hämta hem och installera senaste versionen av Windows installer for Identity Provider 3.3.3[3] och därefter köra installationsprogrammet. Det är endast Jetty som uppdateras om du redan kör senaste version av Shibboleth IdP.
Mer information
- Jetty Security Announcement, http://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00123.html
- Uppgradera Jetty, https://wiki.sunet.se/display/SWAMID/Uppgradera+Jetty
- Windows installer for Identity Provider 3.3.3, https://shibboleth.net/downloads/identity-provider/3.3.3/
SimpleSAMLphp har skapat en Security Advisory om en sårbarhet i SimpleSAMLphp där det är möjligt att:
- om SImpleSAMLphp är en IdP kan någon som genomför en attack utge sig för att vara en SP och få dess attributrelease eller
- om SmpleSAMLphp är en SP kan någon som genomför en attack totalt lura tjänsten om vem det är om loggar in.
Rekommendationer
Uppgradera till senaste versionen med av det inbyggda verktyget composer genom att köra "composer update".
Mer information
Shibboleth Consortium har skapat en Security Advisory om en sårbarhet i Shibboleth Service Provider där det är möjligt att genomföra dataförfalskning baserad på felaktig XML.
Rekommendationer
Uppgadera biblioteket XMLTooling-C till V1.6.4 eller senare och starta sedan om påverkade processer (shibd, Apache, etc.).
Hur gör jag detta?
- Linuxinstallationer som använder de officiella RPM-paketen kan uppgradera dessa till senaste versionen för fixen ska installeras.
- MacPORT av Shibboleth SP måste uppdateras från aktuell webbplats.
- Windowsversionen av Shibboleth SP uppgraderas till senaste versionen(V2.6.1.4).
Mer information
Den 31 januari 2018 kommer att vara den sista dagen det är möjligt att använda Shibboleth Identity Provider version 2 i SWAMID. Det har då gått 1½ år sedan den blev ”end of life”. Även om det ännu inte har uppstått några kända säkerhetshål anser vi att det är dags att sätta ett sistadatum. Tjänsteleverantörer som använder SWAMID, direkt eller via eduGAIN, sätter sin tillit till att SWAMIDs medlemsorganisationer sköter sin identitetshanteringsmiljö på ett bra och säkert sätt och att då efter 1½ år efter end-of-life fortsätta använda en nyckelkomponent urholkar tilliten.
The old SWAMID Inside has moved from wiki.swamid.se, i.e. portal.nordu.net, to wiki.sunet.se. We hope that all information has be transferred and all links within the wiki works. If you find any errors please inform SWAMID Operations. Most links on the old wiki.swamid.se are correctly redirected to wiki.sunet.se.
As of July 31 2016 Shibboleth Identity Provider is end-of-life. If you still use version 2 please update to the latest version. For more information in Swedish on howto upgrade please see Uppgradera Shibboleth IdP från version 2 till version 3.
Med början sommaren 2014 kommer vi successivt att byta ut den sida där man väljer sitt lärosäte vid inloggning inom SWAMID, även kallad Discovery Service (DS). Nuvarande "gula" sida med rullmeny ersätts av en modernare sida med sökgränssnitt.
Connect-tjänsten har bytt Discovery Service (11/8), Box kommer att byta under kommande vecka.
För övriga tjänster som använder ds.sunet.se så kommer bytet att ske sist, planerat om två veckor.
Den nya DS-tjänsten väljer automatiskt IdP åt dig baserat på SP:ns domän, dvs om du går till medarbetarportalen.gu.se kommer SP:n att automatiskt att föreslå GUs IdP.
Du kan nu också spara ditt lärosäte - OM du sparat och senare vill återställa ditt val så görs detta på http://md.nordu.net/reset
mvh operations
Valter
OpenSSL används i många system som är anslutna till SWAMID. Detta är SWAMID operations rekommendation av hur heartbleed skall hanteras i SWAMID:
Det finns normalt 2 nycklar i en SP eller IdP: en nyckel för den webserver som utgör användargränssnittet för tjänsten eller IdPn och en nyckel som används mellan IdPer eller SPer. Denna andra nyckel (federationsnyckeln) är den som finns i federationsmetadata. SWAMIDs rekommendation är att dessa nycklar bör vara olika: federationsnyckeln kan med fördel associeras med ett sk självsignerat certifikat som inkluderas i metadata. De som satt upp sin SP eller IdP enligt denna rekommendation behöver normalt inte byta federations-nyckeln utom i följande två fall:
- En shibboleth idp som uppsatt så att apache hanterar SSL för port 8443 *och* om apache använder en sårbar openssl så bör IdPns federationsnyckel bytas. Förklaringen är att port 8443 använder federationsnyckeln för TLS och om man konfigurerat sin apache att hantera denna port och (tex via ajp) skicka vidare trafiken till shibboleth IdPn så kommer federationsnyckeln att vara tillgänglig för apache-processen och alltså potentiellt blivit exponerad i en heartbleed-attack. Denna port används för SOAP-bindings för AttributeResponse.
- En simplesamlphp som kör i mod_php så ska den nycklas om oavsett om det är en SP eller IdP om openssl-versionen är sårbar.
Kontrollera på din OS-distributionsleverantörs hemsida om din installerade version av openssl är sårbar. Har du byggt och kompilerat openssl får du själv kontrollera sårbarheten. De versioner av openssl som levererats av openssl är sårbara i version 1.0.1- 1.0.1f och 1.0.2beta
Sedan ett par veckor tillbaka går det att använda SWAMID för att logga in på MSDNAA/ELMS. Läs mer om hur du ansluter din IdP till MSDNAA. För att ansluta till MSDNAA krävs att din IdP är med i SWAMID 2.0.
From http://shibboleth.internet2.edu/secadv/secadv_20111024.txt:
A flaw exists in the algorithms specified by the XML Encryption
standard that can lead to exposure of personal information under
certain circumstances.There is no simple fix for this issue, so deployers are encouraged
to consider their use of certain software features and possibly
make changes to their configurations if circumstances warrant,
as described below.
The impact for SWAMID is limited since most SPs already use HTTPS. Those SPs that do not today use HTTPS are strongly encouraged to do so as soon as possible.