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 https://release-check.swamid.se/ 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.

Linux

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.

Windows

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, http://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00123.html
  2. Uppgradera Jetty, https://wiki.sunet.se/display/SWAMID/Uppgradera+Jetty
  3. Windows installer for Identity Provider 3.3.3, https://shibboleth.net/downloads/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.

Rekommendationer

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.

Rekommendationer

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.

SWAMID Wiki has moved

The old SWAMID Inside has moved from wiki.swamid.se, i.e. portal.nordu.net, to wiki.sunet.se. We hope that all information has be transferred and all links within the wiki works. If you find any errors please inform SWAMID Operations. Most links on the old wiki.swamid.se are correctly redirected to wiki.sunet.se.

As of July 31 2016 Shibboleth Identity Provider is end-of-life. If you still use version 2 please update to the latest version. For more information in Swedish on howto upgrade please see Uppgradera Shibboleth IdP från version 2 till version 3.

Med början sommaren 2014 kommer vi successivt att byta ut den sida där man väljer sitt lärosäte vid inloggning inom SWAMID, även kallad Discovery Service (DS). Nuvarande "gula" sida med rullmeny ersätts av en modernare sida med sökgränssnitt.

Connect-tjänsten har bytt Discovery Service (11/8), Box kommer att byta under kommande vecka.

För övriga tjänster som använder ds.sunet.se så kommer bytet att ske sist, planerat om två veckor.

Den nya DS-tjänsten väljer automatiskt IdP åt dig baserat på SP:ns domän, dvs om du går till medarbetarportalen.gu.se kommer SP:n att automatiskt att föreslå GUs IdP.

Du kan nu också spara ditt lärosäte - OM du sparat och senare vill återställa ditt val så görs detta på http://md.nordu.net/reset

 

mvh operations

Valter

 

Heartbleed

OpenSSL används i många system som är anslutna till SWAMID. Detta är SWAMID operations rekommendation av hur heartbleed skall hanteras i SWAMID:

Det finns normalt 2 nycklar i en SP eller IdP: en nyckel för den webserver som utgör användargränssnittet för tjänsten eller IdPn och en nyckel som används mellan IdPer eller SPer. Denna andra nyckel (federationsnyckeln) är den som finns i federationsmetadata. SWAMIDs rekommendation är att dessa nycklar bör vara olika: federationsnyckeln kan med fördel associeras med ett sk självsignerat certifikat som inkluderas i metadata. De som satt upp sin SP eller IdP enligt denna rekommendation behöver normalt inte byta federations-nyckeln utom i följande två fall:

  1. En shibboleth idp som uppsatt så att apache hanterar SSL för port 8443 *och* om apache använder en sårbar openssl så bör IdPns federationsnyckel bytas. Förklaringen är att port 8443 använder federationsnyckeln för TLS och om man konfigurerat sin apache att hantera denna port och (tex via ajp) skicka vidare trafiken till shibboleth IdPn så kommer federationsnyckeln att vara tillgänglig för apache-processen och alltså potentiellt blivit exponerad i en heartbleed-attack. Denna port används för SOAP-bindings för AttributeResponse.
  2. En simplesamlphp som kör i mod_php så ska den nycklas om oavsett om det är en SP eller IdP om openssl-versionen är sårbar.

Kontrollera på din OS-distributionsleverantörs hemsida om din installerade version av openssl är sårbar. Har du byggt och kompilerat openssl får du själv kontrollera sårbarheten. De versioner av openssl som levererats av openssl är sårbara i version 1.0.1- 1.0.1f och 1.0.2beta

MSDNAA+SWAMID=Sant

Sedan ett par veckor tillbaka går det att använda SWAMID för att logga in på MSDNAA/ELMS. Läs mer om hur du ansluter din IdP till MSDNAA. För att ansluta till MSDNAA krävs att din IdP är med i SWAMID 2.0.

From http://shibboleth.internet2.edu/secadv/secadv_20111024.txt:

A flaw exists in the algorithms specified by the XML Encryption
standard that can lead to exposure of personal information under
certain circumstances.

There is no simple fix for this issue, so deployers are encouraged
to consider their use of certain software features and possibly
make changes to their configurations if circumstances warrant,
as described below.

The impact for SWAMID is limited since most SPs already use HTTPS. Those SPs that do not today use HTTPS are strongly encouraged to do so as soon as possible.