Uppdateringen av Shibboleth som kom förra veckan var ett par viktiga säkerhetsuppdatering och det är rekommenderat att uppdatera så snart som möjligt.
Pål
From: announce <announce-bounces(a)shibboleth.net> On Behalf Of Scott Cantor via announce
Sent: Wednesday, May 13, 2026 10:09 PM
To: announce(a)shibboleth.net
Cc: Scott Cantor <scott(a)restingparrotsoftware.com>
Subject: Shibboleth Identity Provider Security Advisory [13 May 2026]
OpenPGP meddelande
Vänta medan meddelandet verifieras...
Shibboleth Identity Provider Security Advisory [13 May 2026]
The Shibboleth Identity Provider has, for some time, included a
library known as "JavaMail", more recently "JakartaMail", used
by the Logback logging library to support sending log output
via SMTP mail.
A vulnerability in this library, while not deemed critical in
its own right, has led us to make the unusual decision to remove
this library from the IdP distribution due to the risk of a more
serious vulnerability in the future.
The Jakarta Mail vulnerability was recorded as CVE-2025-7962.
Injection vulnerability in SMTP Library included with IdP
=========================================================
The Shibboleth Identity Provider dating back to at least V3.0
includes a library not used by the IdP itself but present to
support an optional Logback feature, an SMTP Appender [1]
that supports log output via SMTP.
It is typically used in conjunction with a filter to limit
the use of the feature to specific log messages of particular
import.
The version of the library shipped with recent versions of the
IdP includes a vulnerability, CVE-2025-7962, that allowed
for SMTP injection based on specially crafted log messages.
The most likely vector for exploit would involve logging
that can be influenced by user input.
Because we believe this feature is very little used and because
we are more concerned about the possibility of future exploits
that could be more serious, we have taken the step of removing
this library from a patch release of the IdP and will not be
replacing it with a fixed version.
Recommendations
===============
Update to V5.2.2 (or later) of the Identity Provider software.
If making use of the Logback SMTP Appender feature, inject a fixed
version of the Jakarta Mail library via the IdP's "edit-webapp"
customization mechanism and rebuild the IdP.
See [2] for the project's home page. The self-contained version
of the library that corrects the specific CVE reported is V2.0.2;
note that this is true despite the official CVE claiming otherwise.
Newer versions (V2.1.x) have a separate implementation jar along
with the original API jar. Refer to their documentation for
specifics.
Notably, use this feature at your own risk. We as a project do
not consider it wise to include an SMTP implementation on the
class path given the risk of a more serious issue causing
exfiltration vulnerabilities.
Credits
=======
Philip Brusten
[1] https://logback.qos.ch/manual/appenders.html#SMTPAppender
[2] https://jakartaee.github.io/mail-api/
URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20260513b.txt
Hej.
I samband med en översyn av våra processer kring samordningsnummer så noterar vi en sak som väcker frågor. Vår implementation gällande generering av schacDateOfBirth baseras på informationen på SWAMID:s Wiki https://wiki.sunet.se/spaces/SWAMID/pages/69042390/Svenska+personnummer+nor… samt https://wiki.sunet.se/spaces/SWAMID/pages/69042384/Example+of+a+standard+at…. Där förespråkas (i princip) att direkt bara plocka de första 8 tecknen från norEduPersonNIN, vilket innehåller personnummer eller samordningsnummer, dock ej interimspersonnummer. Vad som blir fel här är i så fall att schacDateOfBirth innehåller ett värde som inte är ett datum i de fall vi använder norEduPersonNIN som källa. Taget från specen på https://wiki.refeds.org/display/STAN/SCHAC+Releases?preview=/44957731/12890… så skall värdet vara av formatet "Numeric value YYYYMMDD, using 4 digits for year, 2 digits for month and 2digits for day as described in RFC 3339 'Date and Time on the Internet:Timestamps' as reference using the 'full-date' format from paragraph 5.6 but without the dashes.".
Nu vill jag justera vår implementation så att vi justerar bort de extra 60 dagarna från samordningsnummer, detta så att vi följer standarden så att vi för en person släpper samma schacDateOfBirth som t.ex. en annan tjänst gör. Rätt eller fel?
Är det någon som ser problem/risker med att byta implementationen? Vi kommer ju i så fall släppa ändrade schacDateOfBirth för personer. Är det någon annan som tidigare noterat detta och som vill dela med sig av erfarenheter av en justering? Har vi inom SWAMID ett undantag i hanteringen av detta fält, som gör att vi oss emellan förväntas kunna skicka samordningsvärden istället? Problemet jag upplever blir när vi autentiserar mot tjänster som förväntar sig "korrekta" datum.
Med vänlig hälsning
/Johan
_________________________________________
Johan Hjortskull
Systemarkitekt
Linnéuniversitetet
IT-avdelningen
391 82 Kalmar / 351 95 Växjö
Lnu.se
Vi sätter kunskap i rörelse för en hållbar samhällsutveckling. Linnéuniversitetet - ett modernt, internationellt universitet i Småland.
Vi behandlar personuppgifter enligt reglerna i Dataskyddsförordningen, se Lnu.se/personuppgifter<https://lnu.se/mot-linneuniversitetet/kontakta-och-besoka/personuppgifter/>.
Hej på er alla som använder ADFS Toolkit,
Hashalgoritm SHA1 är utfasad (deprecated) av säkerhetsskäl. Standardkonfigurationen av ADFS Toolkit är att den ställer in SHA1 som standardalgoritm för SHA* eftersom verktyget inte kan se skillnad på de olika varianterna. Det är nu dags att åtgärda så att SHA256 är standard istället för SHA1. Vi har uppdaterat vår tips- och trixsida ADFS Toolkit Tips & Trix - Sunet Wiki<https://wiki.sunet.se/spaces/SWAMID/pages/254182664/ADFS+Toolkit+Tips+Trix> för hur man gör detta genom konfiguration av ADFS Toolkit. Två lärosäten har redan gjort detta efter att Swamid Operations har fått önskemål från den danska federationen WAYF, de tillåter inte längre SHA1.
Pål
Tjo!
Har det diskuterats i eduGAIN eller REFEDS om best practices kring OpenID Connect ännu?
Det jag syftar mest på är:
* Namngivning av attribut (typ eduPersonEntitlement t.ex.)
* Tillåtna grant types
* Krav på PKCE
* Krav på DPoP
MVH
- Simon
Hej!
Enligt SWAMID SAML WebSSO Technology Profile (3.2, 3.3 och 6.6.2) ska en entitet årligen bekräfta
att den uppfyller teknologi-profilen samt ha tidsmässigt giltigt certifikat.
Följande entitet har trots påtryckning inte bekräftats eller har ett certifikat som gått ut och kommer därför raderas 2026-09-30 ur federationen.
* https://sam.control.lth.se/shibboleth
Vet ni med er att entiteten används vid ert lärosäte behöver ni skyndsamt eskalera detta
till rätt instans inom er organisation.
Det går att följa status på dessa entiteter via vår felsida:
https://metadata.swamid.se/admin/?action=ErrorList
Finns entiteten kvar är den ännu inte hanterad (uppdateras varje onsdag morgon). Last
Confirmed/Validated uppdateras dock löpande.
--
jocar
Swamid Operations
Hej.
FYI
Shibboleth SP 3.6 är nu släppt. Ingen säkerhetsrelaterad release utan mer som en förberedelse för Shibboleth SP 4.
De flesta distributioner paketerar 3.5.x så om ni vill köra 3.6 måste ni bygga den själva.
Den stora fördelen med 3.6 är att den flaggar upp konfig som inte längre kommer att fungera i SP 4. Så de som vill förbereda sig inför uppgraderingen kan vilja köra 3.6 en period, övriga kan sitta lugnt i båten :-)
// Björn M.
> Begin forwarded message:
>
> From: Scott Cantor via announce <announce(a)shibboleth.net>
> Subject: Shibboleth Service Provider V3.6.0 now available
> Date: 16 September 2026 at 02:44:01 GMT+2
> To: announce(a)shibboleth.net
> Cc: Scott Cantor <scott(a)restingparrotsoftware.com>
> Reply-To: users(a)shibboleth.net
>
> The Shibboleth Project has released the final minor update to the legacy Service Provider software, V3.6.0.
>
> Source and Windows packages are available [1] and the RPMs are going out to the mirrors now.
>
> There are a couple of notes regarding packages:
>
> - We have published a newer version of libcurl-openssl for Amazon Linux 2, but the OpenSSL version there limits that to a version well behind the latest, best we can do without leveraging non-default packages or doing further custom work.
>
> - We can't maintain build images for CentOS 7 with any reasonable effort at this point, so I have not produced any packages for it. That's in line with our support policy as that has not been a supported platform for a while.
>
> Per the release notes [2], there are no functional changes in this version; it is a "final" release to add deprecation warnings in many places to flag features that are disappearing from the forthcoming V4.0 Agent that replaces this software. Its purpose is to aid deployers in cleaning up Apache (and RequestMapper) configurations to make migration to that version simpler later, and identify deployments using to-be-removed features.
>
> While there may be future patch releases to fix major bugs, fix security issues, or add further warnings, there will be no further feature releases of this software.
>
> Should anybody left be using it, I have produced a final synced up release of the old Moonshot Shibboleth Attribute Resolver library (with deprecation warnings) as well. [3]
>
> Next stop, 4.0.
>
> -- Scott
>
> [1] https://shibboleth.net/downloads/service-provider/3.6.0/
> [2] https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065335693/ReleaseNo…
> [3] https://shibboleth.net/downloads/service-provider/extensions/shibresolver/3…
>
> --
> To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net
Tjo!
Mitt minne är ju notoriskt dåligt men jag minns det som att det förut skiljde sig i hur leg-kontrollen skulle göras mellan AL2 och AL3?
Att med AL3 så var man tvungen att kontrollera legitimationen noggrannare genom att ringa register och grejer t.ex.?
Minns jag helt fel?
I v1.2 av https://wiki.sunet.se/spaces/SWAMID/pages/83494432/Identity+Assurance+Level… så under 5.2.5 så nämns "how the Member Organisation minimises the risk of identity fraud;” så det kanske är inkluderat i det?
Jag minns det som att det var tydligare och mer explicit dock?
Tack!
MVH
- Simon
