Shibboleth konsortiet skickade ut nedanstående Security Advisory den 16 december 2022. Alla som använder Shibboleth Identity Provider eller OpenSAML-Java rekommenderas starkt att följa konsortiet rekommendationer snarast.

Hash: SHA512

Shibboleth Identity Provider Security Advisory [12 December 2022]
OpenSAML-Java Security Advisory [12 December 2022]

Older releases of the Shibboleth Identity Provider and OpenSAML-Java
library are potentially vulnerable to attacks ranging from denial of
service to remote code execution when given specially-crafted
encrypted XML to decrypt. Some decryption use cases include
unauthenticated message processing, so are widely accessible.

While the current releases of both software products (V4.2.0+) are
believed to be protected from the worst implications of this issue,
many people operate older releases of both the Identity Provider and
OpenSAML, so we are publishing this advisory in part as a courtesy.

It is believed that the worst outcomes on older versions also depend
on the use of non-current releases of the Java JDK, even as recent
as those prior to July of 2022.

At this time, it is believed that the risk of similar attacks in the
Shibboleth SP are not significant. We will update this, and publish a
second advisory in the event this determination changes.

OpenSAML and IdP mis-handle malicious encrypted XML content
The XML Encryption specification, much as the original XML Signature
specification, contains an over-abundance of generality in various
areas, including the potential use of XSLT and XPath "transforms"
as processing instructions while calculating the encrypted content
to decrypt.

SAML provides very specific guidelines for how signed XML needs to
look, allowing pre-validation to prevent many problems. It provides
much less guidance on this matter for encrypted XML.

The OpenSAML Java library, up to and including V4.2.0, does not
perform sufficient validation on the content to outright prevent
execution of some malicious transforms. (OpenSAML V4.2.0 is present
in the V4.2.x releases of the Shibboleth Identity Provider.)
However, the Santuario XML Signature/Encryption library release (2.3.0)
used by these versions of our software contains a default-on secure
processing mode that precludes the worst of these attacks out of the
box, and so we know of no immediately practical attacks against these
versions of our software.

Unfortunately, older versions of our software rely on older Santuario
versions that do not default to this secure processing mode. They are
therefore potentially vulnerable, and these attacks are able to exploit
critical security vulnerabilities in versions of Java whose XSLT
implementation has not been patched.

There have been at least two remote code execution vulnerabilities
reported against Xalan-J, and in turn against Java, in the past 8 years,
one as recent as this past summer. As a result. versions of Java with
patch levels older than August 2022 are believed to be vulnerable to
at least one such issue.

Note that the actual Java LTS release (Java 8, Java 11, Java 17) is
not the relevant issue, but the underlying patch level of a given Java
version. All of the sources of OpenJDK provide routine patch updates
on a quarterly basis and these updates are critical. It is also crucial
to use these LTS releases rather than "feature releases" such as
Java 12-16, etc. due to the risk of missing out on such fixes.

We will include an enhancement in all future releases of OpenSAML 
to harden the library against this class of attacks to the greatest
extent possible.

Review the versions of Java and the Identity Provider and OpenSAML
software in your deployment. Make sure that Java is fully patched
and current for whichever LTS release you are using, and take steps
to ensure this remains true.

Note that the Shibboleth Project does not distribute Java in any of
our packaging, most particularly on Windows, where there is no
built-in source of Java and maintaining currency requires additional
effort. Some third-party packaging sources do include Java and you
should ensure you are staying up to date via those sources.

This Red Hat bug report [1] on one of the vulnerabilities mentions
the specific patch levels released this summer that address the
latest issue. Those Oracle patch levels refer to Java "in general"
and may not apply in specific instances where vendors have distributed
Java themselves (e.g., Debian and so on). When in doubt, always use
"the latest" Java for your LTS version and platform.

Obviously you should be taking steps to upgrade to a current IdP
version, but the advice above is critical if you cannot do so quickly.

While we do believe the older versions of our software are likely safe
from the worst of the vulnerabilities provided Java is current, we do
not believe that the risk of future attacks is insignificant, and so
this is not a recommended long term answer.

In the event that upgrading promptly is impossible (which would imply
you should be considering alternatives), a reasonable precaution is to
update your older deployment to xmlsec-2.3.0.jar by following these

1. Stop servlet container.
2. Remove the existing version of xmlsec-X.X.X.jar from
3. Download, verify, and copy in the newer version from [2] to
that same location (or if you prefer, to edit-webapp/WEB-INF/lib).
4. Rebuild the war via the usual command.
5. Start servlet container.

This is a compatible change for all V4.x IdP releases. We do not know
whether this is compatible with older versions.

Khoadha of Viettel Cyber Security


URL for this Security Advisory:



För knappt en månad sedan den 20 oktober presenterade SWAMID på Sunetdagarna att vi inför fyra nya GDPR-vänliga entitetskategorier. En av dessa nya entitetskategorier ersätter SWAMIDs gamla entitetskategori SWAMID Research and Education för alla tjänster som idag har den. Eftersom de gamla entitetskategorin kommer att fullständigt avvecklas vid årsskiftet rekommenderar vi alla identitetsutfärdare att införa stöd så fort som möjligt för de nya entitetskategorierna.

Följande är de nya entitetskategorierna:

  • REFEDS Anonymous Access Entity Category - Kategorin avser tjänster som erbjuder en servicenivå baserad endast på bevis på framgångsrik autentisering samt vissa organisationsattribut, möjliggör ingen personifiering baserat på en användaridentifierare.
  • REFEDS Pseudonymous Access Entity Category - Kategorin avser tjänster som erbjuder en servicenivå baserad på bevis på framgångsrik autentisering samt möjliggör personifiering baserat på en pseudonym användaridentifierare.
  • REFEDS Personalized Access Entity Category - Kategorin avser tjänster som erbjuder en servicenivå baserad på bevis på framgångsrik autentisering samt möjliggör personifiering baserat på en organisationsunik användaridentifierare, namn och e-postadress, ersätter SWAMID Research and Education.
  • REFEDS Data Protection Code of Conduct Entity Category (CoCov2) - Kategorin avser tjänster som antingen inte uppfyller kraven för övriga kategorier eller har behov andra attribut, t.ex. personnummer, än de som erbjuds i övriga kategorier, ersätter på lång sikt CoCov1 men bägge behöver stödjas parallellt.

Följande är de gamla entitetskategorierna som behålls:

  • REFEDS Research and Scholarship Entity Category (R&S) - Kategorin avser tjänster som direkt stödjer forskning och utbildning baserad på bevis på framgångsrik autentisering samt möjliggör personifiering baserat på en organisationsunik användaridentifierare, namn och e-postadress.
  • Géant Data Protection Code of Conduct Entity Category (CoCov1) - Kategorin avser tjänster som antingen inte uppfyller kraven för övriga kategorier eller har behov andra attribut, t.ex. personnummer, än de som erbjuds i övriga kategorier, ersätts på lång sikt CoCov2 så bägge behöver stödjas parallellt.
  • European Student Identifier Entity Category (ESI) – Kategorin avser tjänster som har behov av European Student Identifier, t.ex. tjänster runt Erasmus+.

Följande är de gamla entitetskategorierna som slutligen avvecklas:

  • SWAMID Research and Education - Ersätts av både Personalized Access och R&S beroende på vilken typ av tjänst det är. Även CoCov2 och CoCov1 används som ersättare i vissa fall.
  • SWAMID SFS 1993:1153 - Ersätts av CoCov2 och CoCov1.

Som ni ser så hör REFEDS tre nya entitetskategorier Anonymous Access, Pseudonymous Access och Personalized Access ihop i en hierarki. De tjänster som endast behöver veta att en användare tillhör en viss organisation använder Anonymous Access, de tjänster som vill kunna ge användaren en mer personifierad åtkomst men utan behov av namn och e-postuppgifter använder Pseudonymous Access och till sist de tjänster som behöver full personalisering använder Personalized Access. Denna hierarki gör att tjänster inte behöver begära mer information än de behöver för att leverera tjänsten till användarna, s.k. dataminimalisering runt personuppgifter. SWAMIDs standardmallar för både Shibboleth och ADFS tar hänsyn till minimeringen på så sätt att om en tjänst begär mer än en av dessa tre får tjänsten attribut baserat på den som är mest dataminimerande, dvs. begärs både Anonymous Access och Pseudonymous Access används den förstnämnda.

För er som använder ADFS Toolkit finns nu en ny version 2.2.0 som har stöd för både de nya entitetskategorierna samt de nya identitetsattributen som krävs. Ni hämtar senaste versionen på adressen Praktisk information finns i sunetdagarpresentationen 11-11.45 den 20 oktober.

För er som använder Shibboleth IdP finns detaljer om hur ni kommer i gång med de nya entitetskategorierna även de i sunetdagarpresentationen 11-11.45 den 20 oktober. Självklart innehåller även standardmallarna för Shibboleth på SWAMIDs wikisidor denna konfiguration.

Att signalera tillit

Som alla lärosäten vet börjar Ladok kräva att de personer som har tillgång till modulen nationell översikt uppfyller kraven för SWAMID AL2 från och med kommande årsskifte. Förutom att alla aktuella användarnas måste valideras för SWAMDI AL2 enligt de metoder som ni är godkända för måste identitetsutfärdaren även signalera godkända tillitsnivåer till Ladok och andra tjänster. Ladok kommer att från och med sommaren kräva SWAMID AL2 för alla anställda som loggar in i Ladok från och med halvårsskiftet 2023. Om ni inte är godkända för SWAMID AL2 eller om ni inte signalerar SWAMID AL2 för de användare som uppfyller kraven kommer de inte kunna logga in i Ladok. Aktuell status för vilka som är godkända för SWAMID AL2 finns i medlemslistan på SWAMIDs wiki, De lärosäten som ännu inte är godkända för SWAMID AL2 arbetar för fullt med att bli det.

Från och med i januari kommer även EuroHPC-datorn Lumi via identitetsinfrastrukturerna MyAccessId och Puhuri börja kräva tillitssignalering via REFEDS Assurance Framework (RAF). SWAMID tillitsramverk uppfyller kraven i RAF och det är enkelt att signalera RAF baserat användarens tillitsprofiler. Även detta finns stöd för i standardmallarna för både Shibboleth och ADFS. Tänk på att de flesta lärosätena och andra forskningsorganisationer i Sverige har minst en användare eller forskningsgrupp som är beroende av att kunna använda Lumi inom ramen för sin forskning.

För att få veta mer om förändringarna runt entitetskategorier och att signalera tillitsnivåer kan ni ta del av presentationerna från den 20 oktober på Sunetdagarnas wikisida Om ni som identitetsutfärdare behöver mer information eller lite hjälp hör av till SWAMID Operations,

Så i korthet behöver ni göra följande före julledigheterna:

  • Aktivera stöd för de nya entitetskategorierna i era identitetsutfärdare
  • Konfigurera så att ni kan släppa både SWAMIDs tillitsprofiler och REFEDS Assurance Framework till de tjänster som behöver det
  • Testa attributreleasen i SWAMIDs testverktyg
  • När ni får grönt på attributreleasen gå in på och uppdatera vilka entitetskategorierna ni stödjer i er identitetsutfärdare

Efter 10 år har nu alla utom två av SWAMIDs medlemsorganisationer blivit godkända för en eller flera tillitsprofiler. De som ännu inte är godkända måste bli det i samband med årets första möte med SWAMID Board of Trustees i början på mars, annars kommer de att stängas av från SWAMID.

I tillitsprofilernas avsnitt 3 om efterlevnad och revision står det att en medlemsorganisation årligen ska bekräfta att det som står i organisationens identitetsutgivares (IdP) Identity Management Practice Statement (IMPS) fortfarande stämmer. Det står vidare att medlemsorganisationen måste uppdatera och skicka in IMPS för godkännande innan ändringar. Den uppdaterade IMPS:en måste vara godkänd av SWAMID Board of Trustees innan ändringar genomförs i organisationens IdP och underliggande system. Från och med 2022 kommer SWAMID Operations aktivt begära att medlemsorganisationerna rapporterar enligt dessa krav.

För att underlätta uppfyllelsen av kravet kommer SWAMID Operations att skicka ut en påminnelse till alla medlemsorganisationer under året med en kopia av den IMPS som senast har blivit godkänd av SWAMID Board of Trustees. Om inte medlemsorganisationen inom rimlig tid och efter påminnelser besvarar denna begäran kommer aktuella identitetsutgivare avregistreras från SWAMID tills denna process har genomgåtts. Vi kommer att skicka ut påminnelsen till administrativa och tekniska kontakter i metadata. Kontrollera att dessa kontaktuppgifter för identitetsutfärdaren stämmer via och uppdatera snarast om de inte stämmer.

SWAMID Operations
Pål Axelsson

I vår strävan att få SWAMID att fungera bättre och säkrare fastställde SWAMID Board of Trustees (BoT) i december den uppdaterade teknologiprofilen för SAML WebSSO efter konsultarationen som pågick mellan oktober och november 2021. Vid BoT-mötet beslutades även att alla idag registrerade entiteter (identitetsutfärdare och tjänster) i SWAMID ska ha fram till årsskiftet 2022/2023 på sig att åtgärda eventuella felaktigheter i metadata som identifierats baserat på den uppdaterad teknologiprofilen. De som inte åtgärdar felaktigheterna innan årsskiftet kommer att avregistreras från SWAMIDs metadata under januari 2023. Under denna övergångsperiod avvecklas också SWAMIDs gamla entitetskategorier SWAMID Research & Education och SWAMID SFS 1993:1153.

För att underlätta arbetet med att åtgärda felaktigheterna i metadata samt att generellt förenkla metadataadministrationen har SWAMID Operations tagit fram ett verktyg för självadministration av metadata. Det nya verktyget ska alltid användas, från och med januari 2022, vid registrering och uppdatering av metadata i SWAMID. Det nya självserviceverktyget är tillgängligt via SeamlessAccess-inloggningsknappen på Metadataverktyget kommer att presenteras på ett webinar torsdagen den 20:e januari, se

Den internationella samarbets- och standardiseringsorganisationen REFEDS kommer under 2022 uppdatera sina entitetskategorier för att ännu bättre kunna ge användarna tillgång till de tjänster de behöver logga in i samtidigt som aktuell dataskyddslagstiftning beaktas. Detta betyder att SWAMID kommer att uppdatera SWAMIDs rekommendationer runt entitetskategorier senare i år. Det kommer att tillkomma fyra nya entitetskategorier: en för personaliserad åtkomst till tjänster, en för pseudonymiserad åtkomst till tjänster, en för anonymiserad åtkomst till tjänster samt en GDPR-anpassad Data Protection Code of Conduct. Skillnaden mellan de tre första är hur mycket personuppgifter som skickas av identitetsutgivaren till tjänsten. SWAMID Operation kommer under året att uppdatera wikisidorna om entitetskategorier för att beskriva hur de nya entitetskategorierna ska användas i framtiden. Det kommer också hållas webinarer om hur de nya entitetskategorierna konfigureras i av SWAMID stödda identitetsutgivare (Shibboleth IdP och ADFS). Vidare kommer SWAMIDs testverktyg att utökas med tester för de nya entitetskategorierna så snart de är beslutade av REFEDS.

SWAMID kommer under året fortsätta utveckla ADFS Toolkit för att följa de nya standarderna från REFEDS men också hantera standardiserad multifaktorinloggning enligt REFEDS standardsignalering och SWAMIDs tillitsprofiler. Version 2.1.0 kommer att släppas under första kvartalet. SWAMID kommer även här att genomföra webinarer för att beskriva hur ADFS Toolkits kan användas inom SWAMID.

SWAMID kommer som vanligt att delta under Sunetdagarna i vår och i höst. Vårens Sunetdagar kommer genomföras digitalt under andra hälften av mars, program kommer när det närmar sig.

Välkomna till 2022!
SWAMID Operations

I princip har alla IdP-administratörer gjort sitt jobb när det gäller förändringen av entitetskategorier i SWAMID och nu är det dags för er som administrerar tjänster i SWAMID att göra samma sak.

Enligt SWAMIDs metadata finns det idag runt 100 tjänster som via entitetskategorin SFS 1993:1153 får tillgång till personnummer för användarna som loggar in. Det finns några få nationella tjänster från t.ex. UHR och Ladok men de flesta är lärosäteslokala. Några av de lärosäteslokala hanteras dessutom av externa tjänsteleverantörer på uppdrag av resp. lärosäte. Vanliga typer av tjänster är kontoaktiveringsportaler och CMS men det finns även andra typer. De flesta lärosäteslokala tjänsterna begränsar från vilken identitetsutfärdare inloggning är möjlig, t.ex. lärosätets egna eller eduID och

Vad händer nu? Detta brev är en första varning om att de tjänster som inte har bytt från den gamla entitetskategorin SFS 1993:1153 till Géant Data Protection Code of Conduct (CoCo) inte lägre att få tillgång till personnummer efter 2021-12-31 om inte en förändring görs. Observera att detta datum inte kommer att flyttas framåt! Detta gör att ni som har tjänster som får personnummer i samband med inloggning och som ännu gjort detta arbete måste nu planera in aktiviteter under hösten runt bytet av entitetskategorier.

För att kontrollera om ni är berörda av denna förändring finns nedanstående lista men ni kan även gå till och klicka på ert entityId. Den resulterande sidan med information om er tjänst ser ni vilka entitetskategorier som er tjänst har registrerade. Observera att SWAMIDs gamla entitetskategori Research and Education också avvecklas 2021-12-31 och därför är det bra om ni ser till så att alla attribut ni måste ha för att tjänsten ska fungera för användaren hanteras samtidigt via entitetskategorin CoCo.

Om ni vet att ert lärosäte har tjänster som är beroende av personnummer vid inloggning med hjälp av SWAMID sprid denna information till personer som arbetar med tjänsterna.

För mer information om kraven för att få använda entitetskategorin CoCo se

Lista på tjänster och tillhörande test- och utvecklingsmiljöer som berörs:


SWAMID har nu publicerat en ny web-site för att presentera Metadata. 

På går det att se samtliga av SWAMID publicerade IdP/SP:er
Mycket info finns där redan men mer kommer säkert att dyka de närmaste månaderna beroende på efterfrågan.

ADFS Toolkit 2.0.0

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. (smile)
Det är mycket som hänt sedan 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:

Dokumentation kring hur man installerar eller uppgraderar finns också på GitHub:

Läs igenom instruktionerna noga innan uppgradering. Det är lite olika steg som behöver göras vid uppgradering från till 2.0.0.
Vidare uppgraderingar kommer gå betydligt lättare!

Upplever du några problem eller har funderingar, kontakta

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 och 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 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å

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.

[2] chrome://flags/#same-site-by-default-cookies

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?

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 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.


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.


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

  1. Jetty Security Announcement,
  2. Uppgradera Jetty,
  3. Windows installer for 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.


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.


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.