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
