Hej,
Igår den 25 maj höll Swamid Board of Trustees sitt första möte för 2026 och protokollet finns publicerat på https://wiki.sunet.se/spaces/SWAMID/pages/318701630/SWAMID+BoT+2026-05-25.
Att notera från mötet är att två nya lärosäten blev godkända för Swamid AL3 och att ytterligare fem fick uppdaterade Swamid AL2 godkända.
Vidare så beslutades att det organisationer som ännu inte blivit färdiga med uppdatering av sina Identity Management Practice Statement och blivit godkända före uppdateringen av tillitsprofilerna 2020 måste slutföra denna uppdatering före 31 oktober, annars blir de avstängda från Swamid tills uppdatering slutförd.
Pål Axelsson
FYI
// Björn M.
> Begin forwarded message:
>
> From: Philip Smart via announce <announce(a)shibboleth.net>
> Subject: WebAuthn plugin V1.4.2 now available
> Date: 20 May 2026 at 11:55:46 GMT+2
> To: "announce(a)shibboleth.net" <announce(a)shibboleth.net>
> Cc: Philip Smart <Philip.Smart(a)jisc.ac.uk>
> Reply-To: users(a)shibboleth.net
>
> The Shibboleth Project has released version 1.4.2 of the WebAuthn authentication plugin.
>
> This patch release primarily updates the Yubico WebAuthn libraries to version 2.9.0, including a fix for a FIDO metadata parsing issue.
>
> Version 2.9.0 also resolves a regression we identified and reported in later releases of the Yubico library, which led to a high-severity impersonation vulnerability [1]. We were not affected by this issue and intentionally deferred upgrading until a fix was available.
>
> For full details, please refer to the release notes [2].
>
> — Phil Smart, on behalf of the team
>
> [1] https://www.yubico.com/support/security-advisories/ysa-2026-02/
> [2] https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3394928781/We…
>
>
> Jisc is a registered charity (in England and Wales under charity number 1149740; in Scotland under charity number SC053607) and a company limited by guarantee registered in England under company number 05747339, VAT number GB 197 0632 86. Jisc's registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
>
>
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
>
>
> For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice
>
> --
> To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net <mailto:announce-unsubscribe@shibboleth.net>
Uppdateringen av Shibboleth som kom förra veckan var ett par viktiga säkerhetsuppdateringar och det är rekommenderat att uppdatera så snart som möjligt.
Pål
> -----Original Message-----
> From: announce <announce-bounces(a)shibboleth.net> On Behalf Of Scott Cantor
> via announce
> Sent: Wednesday, May 13, 2026 10:08 PM
> To: announce(a)shibboleth.net
> Cc: Scott Cantor <scott(a)restingparrotsoftware.com>
> Subject: Shibboleth Identity Provider Security Advisory [13 May 2026]
>
> Shibboleth Identity Provider Security Advisory [13 May 2026]
>
> An updated version of the Identity Provider software is available
> which includes explicit features and updated defaults to correct
> a denial of service vulnerability that can cause unconstrained
> resource consumption using XML that exceeds typical limits on
> certain kinds of content.
>
> Updates to OpenSAML are included in this patch, but this advisory
> refers to the specific impact and mitigations for the IdP itself.
>
> A separate advisory is available for OpenSAML alone.
>
> Maliciously crafted XML causes excessive resource consumption
> =============================================================
> While the XML parser in newer versions of Java includes default
> settings that limit certain kinds of malicious content, older
> versions did not and so can be vulnerable to specially crafted
> XML. These default settings are in any case not set low enough
> to be safe in this usage context.
>
> The OpenSAML library's decoding of SAML and SOAP messages is
> unprotected in its default configuration from such content and
> parsing some messages can result in memory and/or CPU exhaustion,
> causing a denial of service in applications using it, including
> the Shibboleth Identity Provider.
>
> Since most XML message types are parsed either without the
> protection of a signature or in advance of evaluating one, the
> exploit does not require an authenticated attacker and so is
> serious, though as a denial of service issue it remains in a
> lower tier of vulnerabilities.
>
> An updated version of the IdP (V5.2.2) is available which
> add new properties that limit parsing of most content that could
> expose the system to attack:
>
> * idp.xml.elementAttributeLimit (default 30)
> * idp.xml.maxElementDepth (default 25)
>
> In addition, the IdP now uses distinct parser settings when parsing
> SAML Metadata that are less strict than those used in general or
> messaging scenarios (and can be independently controlled). This
> allows for unusually crafted Metadata that has been observed in the
> wild by our community.
>
> Finally, the IdP has been enhanced with several new properties that
> can be set to control the size limits on various types of SAML and
> SOAP messages being decoded. Those limits are not enabled by default,
> but are supported in case they are needed in the future.
>
> See also the Releases Notes [1] and documentation [2].
>
> Recommendations
> ===============
> Update to V5.2.2 (or later) of the Identity Provider software. The
> updated default settings are deemed sufficiently safe at this time.
>
> In the event that upgrading is not possible, in most older versions
> one may directly configure new parser attributes directly by overriding
> the Spring bean used to control the parsing performed in most (but
> not all) cases.
>
> To do so, define a bean like so in conf/global.xml:
>
> <bean id="custom.ParserPool" parent="shibboleth.DefaultParserPool">
> <property name="builderAttributes">
> <map>
> <entry key="jdk.xml.elementAttributeLimit" value="30" />
> <entry key="jdk.xml.maxElementDepth" value="25" />
> </map>
> </property>
> </bean>
>
> Then add a property to conf/idp.properties:
>
> idp.xml.parserPool = custom.ParserPool
>
> This is not a foolproof solution for various reasons, but it mitigates
> the most common attack vectors.
>
> Note that we do not know the specific older versions of Java that
> support these parser attributes, and they are known to have gone by
> different names in some older versions prior to Java 17. If you are
> on an unsupported, older version, refer to the relevant JAXP parser
> documentation in that Java version for details.
>
> Credits
> =======
> Jens Friess and Haya Schulmann, Goethe University Frankfurt.
>
>
> [1] https://shibboleth.atlassian.net/wiki/x/T4C0vg
> [2] https://shibboleth.atlassian.net/wiki/x/AQDJPQE
>
> URL for this Security Advisory:
> https://shibboleth.net/community/advisories/secadv_20260513.txt
> -----Original Message-----
> From: announce <announce-bounces(a)shibboleth.net> On Behalf Of Scott Cantor
> via announce
> Sent: Tuesday, May 12, 2026 8:54 PM
> To: announce(a)shibboleth.net
> Cc: Scott Cantor <scott(a)restingparrotsoftware.com>
> Subject: Shibboleth Jetty plugin updated (V1.0.1)
>
> I wouldn't normally make much of an announcement, but...there's an unfortunate
> logging issue in the command line code in the original Jetty plugin that
> interacts..."badly" with the upcoming IdP patch that's due shortly, so I
> accelerated a patch release of the plugin to correct that issue before the IdP
> lands.
>
> 1.0.1 is out there now.
>
> If you're using the Jetty plugin, I'd advise getting that updated first, or at least be
> aware if you run a Jetty download with the old version and the new IdP...it will be
> very slow and ugly, logging every byte the HTTP client sees.
>
> There are a few other very small bug fixes in it, but that's the only significant
> thing.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to announce-
> unsubscribe(a)shibboleth.net
Uppdateringen av Shibboleth som kom förra veckan var ett par viktiga säkerhetsuppdateringar och det är rekommenderat att uppdatera så snart som möjligt.
Pål
> -----Original Message-----
> 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: OpenSAML Security Advisory [13 May 2026]
>
> OpenSAML Security Advisory [13 May 2026]
>
> An updated version of the OpenSAML Java library is available
> which includes explicit features and updated defaults to correct
> a denial of service vulnerability that can cause unconstrained
> resource consumption using XML that exceeds typical limits on
> certain kinds of content.
>
> Maliciously crafted XML causes excessive resource consumption
> =============================================================
> While the XML parser in newer versions of Java includes default
> settings that limit certain kinds of malicious content, older
> versions did not and so can be vulnerable to specially crafted
> XML. These default settings are in any case not set low enough
> to be safe in this usage context.
>
> The OpenSAML library's decoding of SAML and SOAP messages is
> unprotected in its default configuration from such content and
> parsing some messages can result in memory and/or CPU exhaustion,
> causing a denial of service in applications using it.
>
> Most/all applications using OpenSAML to parse SAML messages may
> be vulnerable to this issue.
>
> Since most XML message types are parsed either without the
> protection of a signature or in advance of evaluating one, the
> exploit does not require an authenticated attacker and so is
> serious, though as a denial of service issue it remains in a
> lower tier of vulnerabilities.
>
> An updated versions of the OpenSAML Java library (V5.2.2) is
> available which establish new defaults for these two parser
> settings when using the OpenSAML internal ParserPool instance:
>
> * jdk.xml.elementAttributeLimit (default 30)
> * jdk.xml.maxElementDepth (default 25)
>
> These properties are supported by Java 17 and later, the minimum
> Java version supported by the library. We believe the parser
> properties alone are sufficient at present to mitigate this issue.
>
> However, note that *only* the ParserPool object installed into
> the OpenSAML library configuration is configured with these settings.
> If your application does its own XML parsing, then you are *not*
> protected and are vulnerable to this and many other security risks
> that you are solely responsible for mitigating. This is something
> we strongly advise against doing.
>
> In addition, the library has been enhanced with several new options
> that can be set to control the size limits on various types of SAML
> and SOAP messages being decoded. Those options are not enabled by
> default, but are present in case they are needed in the future.
>
> Recommendations
> ===============
> Update to V5.2.2 of the library. The updated default settings on the
> internally configured ParserPool are deemed sufficiently safe at this
> time, but *only* under the assumption that the library's ParserPool
> instance is always used.
>
> Another mitigation if our ParserPool is not used is to directly configure
> size limits on the MessageDecoder classes in use, but we have not explored
> the efficacy of this approach.
>
> In the event that upgrading is not possible, for this immediate issue
> one can set the two properties noted above as system properties on the
> command line (typically via a -D<option>=value addition to the
> relevant process' startup command).
>
> Note that this will impact all uses of JAXP in the process globally,
> which can of course create problems when parsing other content that
> might be expected to exceed limits.
>
> Note also that we do not know the specific older versions of Java that
> support these parser attributes, and they are known to have gone by
> different names in some older versions prior to Java 17. If you are
> on an unsupported, older version, refer to the relevant JAXP parser
> documentation in that Java version for details.
>
> Credits
> =======
> Jens Friess and Haya Schulmann, Goethe University Frankfurt.
>
>
> URL for this Security Advisory:
> https://shibboleth.net/community/advisories/secadv_20260513a.txt
FYI
--
jocar
> Begin forwarded message:
>
> From: Scott Cantor via announce <announce(a)shibboleth.net>
> Subject: Shibboleth Identity Provider V5.2.2 now available
> Date: 13 May 2026 at 22:05:50 CEST
> To: announce(a)shibboleth.net
> Cc: Scott Cantor <scott(a)restingparrotsoftware.com>
> Reply-To: users(a)shibboleth.net
>
> The Shibboleth Project has released V5.2.2 of the Identity Provider software (and OpenSAML). [1]
>
> This patch release fixes a few bugs and regressions as well as addresses two security advisories that will be forthcoming. The advisories include mitigation advice for the many people undoubtedly running older versions of both the IdP and OpenSAML.
>
> There are two IdP advisories and one separate advisory for OpenSAML targeted at consumers of that library, but that advisory is subsumed by the IdP advisory with respect to the IdP software.
>
> The Release Notes are partially updated [2] and will mention the advisories [3] shortly.
>
> As I noted yesterday, if you're using the new Jetty plugin, it's a good idea to update that along with this release because the original plugin combined with this one has some ugly logging side effects when downloading Jetty.
>
> The MSI installer will be updated some time tomorrow, but as that is being discontinued in the near future, this would be good time to get off that train and accept that the standard upgrade process should be used.
>
> -- Scott
>
> [1] https://shibboleth.net/downloads/service-provider/latest5/
> [2] https://shibboleth.atlassian.net/wiki/x/T4C0vg
> [3] https://shibboleth.atlassian.net/wiki/x/27C0vg
>
> --
> To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net
Hej!
Enligt SWAMID SAML WebSSO Technology Profile (3.2 och 3.3) ska en entitet årligen bekräfta att den uppfyller teknologi-profilen.
Följande entiteter har trots påtryckning inte bekräftats och kommer därför raderas på datum nedan.
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.
Raderas 2025-05-13:
https://lartorget.sll.se/luvit/shibboleth
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
Vi försöker köra Azure som proxy framför Shibboleth men har stött på några problem.
Vi har användare som kör Windows Hello (passwordless) och det finns tjänster som kräver att inloggning ska ske med lösenord (bl.a. signering i eduSign).
När dessa användare loggar in så frågar inte Azure om lösenord, sedan får man felmeddelande från Azure att inloggningen inte skett med lösenord. *facepalm*
De föreslagna lösningarna är:
- Kräv inte lösenord - Vi kan dock inte kontrollera vad alla tjänster kräver, och att skriva om tjänsternas krav i Shibboleth känns inte rätt.
- Sätt forceAuthn=“true” - Det ska tydligen påtvinga lösenordsinloggning. Jag har inte testa det ännu, men det känns inte som en snygg lösning.
Jag vet att andra kör Azure framför Shibboleth, hur har ni hanterat detta?
P.S. Vi fick även problem med Zoom som har ett entityId som inte är en URI. Det fick vi lösa genom att inte skicka vidare RequesterID till Azure (då det var Azure som klagade på det). Återigen, inte en snygg lösning, men jag såg inget sätt att ändra entiyId på Zoom, så det får vi nog leva med.
Eric Johansson | Linux Drifttekniker
IT-avdelningen | GVS | Karolinska Institutet
171 77 Stockholm | Nobels väg 5, plan 4
eric.johansson(a)ki.se | ki.se
Karolinska Institutet – ett medicinskt universitet
När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter. Här finns information om hur KI behandlar personuppgifter<https://ki.se/om-ki/integritetsskyddspolicy>.
Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI’s processing of personal data here<https://staff.ki.se/data-protection-policy>.
Hej.
I samarbete med eduGAIN har vi utvecklat release-checken en hel del.
Det som påverkar release-check.swamid är :
* MFA tabben har blivit Authentication
* Tidigare kontrollerade vi enbart Refeds MFA .
* Nu finns även möjlighet att testa REFEDS SFA / PasswordProtectedTransport / request utan någon AuthnContextClassRef.
* Dock sparas fortfarande enbart resultatet för REFEDS MFA !
* Tidigare gav CoCo testerna OK även om INGA attribut skickades. Nu krävs det att det kommer några men inga extra
* Release-check finns nu även översatt till flera språk.
* Svenska
Vad vi gjort och som kommer att användas i den framtida release-check.edugain.org<http://release-check.edugain.org> som kommer att köras av eduGAIN och andra nationella federationer.
* Möjlighet att även få det översatt till fler språk (vi har valtatt enbart köra på Engelsa och Svenska i vår)
* Italienska
* Rumänska
* Serbiska
* Franska (på gång)
* Turkiska (på gång)
* Möjlighet att anpassa utseendet
* Möjlighet att anpassa vilka tester som skall köras.
// Björn Mattsson
Swamid Operations
Hej!
Vi har lite problem med Elsevier SP (entityID="https://sdauth.sciencedirect.com/").
Någon mer som har det?
Med vänlig hälsning,
/Peo
Högskolan i Halmstad
Per-Ola Månsson (Peo)
IT-avdelningen
+46 35 167224
Per-Ola.Mansson(a)hh.se
http://www.hh.se
