Inom SWAMID är det många organisationer som använder Shibboleth Identity Provider för organisationens SWAMID-kopplade identitetsutfärdare. Nu är det dags att uppgradera till en nyare huvudversion eftersom den tidigare huvudversionen går End-of-Life senare i år. Det är av säkerhetsskäl alltid viktigt att endast använda aktuella och underhållna versioner av programvara och detta är också ett krav i SWAMIDs teknologiprofiler. För er som använder Shibboleth Identity Provider finns det två sätt att hantera att näst senaste huvudversion blir End-of-Life, antingen genom att uppgradera till version 5, att byta till annan programvara än Shibboleth Identity Provider, t.ex. ADFS med ADFS Toolkit, eller att byta till Sunets nya tjänst eduID Connect¹ som lanseras senare i vår. Vilken väg ni än väljer så måste ni bli klara med detta absolut senast under november 2024 och genomför helst arbetet i god tid. Vi uppmanar er därför att aktivt delta på webinar och diskussionsmöten under våren.

Uppgraderingar av huvudversioner innebär alltid mer arbete än uppgradering inom samma huvudversion och det är därför särskilt viktigt att göra ett bra förberedelsearbete. SWAMID Operations kommer att ge er information om hur ni både förbereder och genomför uppgraderingen på ett bra sätt via webinar och öppna diskussionsmöten.

¹ eduID Connect är en avgiftsbelagd tjänst som använder eduID för användarkonton och ett administrativt gränssnitt för att koppla dessa till organisationen.

SWAMID finns som stöd i uppdateringen

För att underlätta arbetet med att uppdatera från äldre versioner kommer SWAMID Operations att genomföra två olika arrangemang, dels ett inledande webinar som beskriver uppdateringsprocessen och därefter öppna mötestillfällen varannan vecka under våren där vi hjälper varandra i uppdateringsprocessen. Detta betyder att vi inte kommer att ha något hackaton där alla gör jobbet på plats. Orsaken till detta är att vi alla har olika förutsättningar och är på olika plats i uppgraderingsprocessen redan nu.

Webinar om uppgradering till Shibboleth IdP v5

Öppna diskussionsmöten om frågor som dyker upp på vägen

Vad händer om vi inte uppgraderar i tid?

I SWAMID teknologiprofil för SAML2 WebSSO under avsnitt 5.4 finns kraven på den federativa programvaran för identitetsutfärdare beskriven och krav 5.4.11 definierar att medlemsorganisationer ej får använda programvara som inte längre underhålls eller innehåller kända säkerhetsproblem. Detta innebär att alla som idag använder Shibboleth IdP version 4 eller tidigare måste uppdatera innan 1 september 2024. Om inte uppdatering genomförs i god ordning kommer SWAMID Operations att föreslå SWAMID Board of Trustees att fatta beslut om att organisationens identitetsutfärdare avregistreras från SWAMID 2024-12-01. Detta kommer innebära, efter beslut har fattats, att organisationens användare inte kommer att kunna logga in i tjänster anslutna till SWAMID förrän uppgraderingen är gjord. Denna process beskrivs kortfattat i SWAMIDs policy under avsnitt 6.3.

Viktigt om uppdateringsprocessen

Om ni inte redan använder Shibboleth 4.3.1 uppdatera till denna version! Detta för att både få rätt konfiguration och rätt varningsmeddelanden i loggar. Samma metod för uppdatering ska användas som nedan. Observera att varningsmeddelandet om stödet för eduPersonTargetId är felaktigt skrivet och är i avvecklat i version 5.

Shibboleth Consortium beskriver i release-notes för IdP v5, ReleaseNotes - Identity Provider 5, att befintliga konfigurationsfiler bara kan användas om uppgraderingen görs i befintlig installation. Följ anvisningarna och installera inte den nya versionen separat för att därefter försöka använda de gamla konfigurationsfilerna. IdP:n behöver istället uppgraderas "på plats" genom att använda en installationskatalog som innehåller en kopia av en tidigare fungerande konfiguration av V4.3.1.

Vidare skriver de att plugins behöver uppdateras innan själva IdP:n uppgraderas och att plugins också ska uppdateras efteråt. Detta eftersom stora interna förändringar skett mellan v4 och v5. Uppgradera och testa alla plugins innan IdP-uppgraderingen påbörjas, och uppdatera åter alla plugins efter IdP-uppgraderingen slutförts, innan IdP:n startas. Installationsprogrammet varnar om detta och rapporterar vilka plugins som behöver en uppdatering.

SWAMID Operations
Pål Axelsson och Paul Scott

På Sunetdagarna nu i höst informerade vi om att SWAMIDs gamla testfederation kommer att avvecklas och ersättas av SWAMIDs QA-federation. QA-federationen finns på plats redan idag med samma uppsättnings verktyg som i SWAMIDs produktionsfederation.

SWAMIDs testfederation kommer att stängas av vid halvårsskiftet 2024. Nyregistreringar i SWAMIDs testfederation är inte längre tillåtna!

Adresser till verktyg i SWAMIDs QA-miljö:

• Metadataverktyget: https://metadata.qa.swamid.se/
• Metadata via MDQ (nya modellen): https://mds.swamid.se/qa/
• Metadata via aggregat (gamla modellen): https://mds.swamid.se/qa/md/
• Hänvisningstjänst: https://ds.qa.swamid.se/ds
• Release-check: https://release-check.qa.swamid.se/.

SWAMIDs alla instruktioner för både identitetsutfärdare och tjänster går att använda men ni behöver byta aktuella URLar enligt ovan i konfigurationsfilerna.

Mer och aktuell information publiceras på wikisidan QA for SWAMID SAML WebSSO.

Pål Axelsson

SWAMID Operations
Pål Axelsson

Since 2016 SWAMIDs metadata has been signed with a key in a HSM. This has been fine since we previously only were creating a handful of metadata aggregation files (of different sizes). The problem with the aggregated feeds is that it takes time and memory(!) to load an in SWAMID's case 80 MB XML file in to the Identity Providers and Service Providers. Had a conversation recently with a new SP in our federation. They guessed that shibd crashed on start since it  appeared to just hang - told them to take a deep breath and relax.

One solution for this memory and size problem isto  start using the MDQ Protocol instead of big aggregated files. By using the MDQ protocol the SPs and IdPs don't need to load the whole federation. Instead they loads requested entities on the fly. So if both an IdP and an SP uses MDQ the SP will first fetch the IdPs metadata from the MDQ server and then redirect for login. The IdP will then fetch the SPs metadata from the MDQ server, prompt for authentication and then redirect the user back to the SP. Pretty easy flow but it requires the MDQ server to be fast and always available!

Our software of choice, pyFF, can act as a MDQ server and serve signed metadata files on request. But connecting pyFF to the HSM makes the signing too slow and would in a case of many requests in a short time create a heavy load on our HSM servers, which we would like to avoid. pyFF can be run in batch mode which will sign all entities and output them to disk (e.g for mirroring) but that would still require us to sign around 9500 entities each run which once again would put our HSMs at risk. Another factor why we chose the design we ended up with is that we would like to protect the machines (signers) connected to the HSM from the internet.

So what we came up with is tools and wrappers around pyFF which fetches SWAMIDs and eduGAINs metadata (a total of around 9500 entities), splits them up in parts, and signs all entities over the current day. That's around 400 per hour and we run it 4 times an hour via cron. This creates a reasonable load on the HSMs. We prioritises new, updated or removed entities which are usably published 15 minutes after we detect a change. The tooling is based on a python script we call mdqp which have som pre and post scripts written in sh.
The basic flow looks like:

• Metadata is fetched from git (a signed commit is verified) and eduGAIN
• pyFF reloads the metadata
• The given amount of entities (new, updated or removed prioritised) are fetched from pyFF via mdqp
• Our aggregated feeds are fetched from pyFF
• All signed entities and files are rsynced to the publishers (web servers)

There are two ways of getting an entity through the MDQ protocol:

• Getting them by entitiyId, e.g /entities/https://connect.eduid.se/sunet
• Getting them by the sha1sum of the entityid, e.g entities/{sha1}47918903a357c193bcd985a23c5958a8a43278c0

Both methods should be url encoded which makes things complicated. "Regular" webservers (e.g apache2 or nginx) decodes an incoming encoded url string before processing the request  which would make it impossible for us to store the first alternative on disk (contains slashes). We also would like to support both alternative with the same file on disk so for that purpose we ended up writing ourself a very small and simple web server in golang which will serve our very niche set of requirements.

The web servers themselves are protected by a geo distributed cluster of HAProxy to even out the load and terminating TLS.

Happy MDQing. 

See our wiki for more information about getting started with MDQ in SWAMID.

-- 
jocar

SWAMID Operations