Hej,
Idag höll SWAMID Board of Trustees årets tredje och sista möte. Protokollet
finns på adressen https://wiki.sunet.se/display/SWAMID/SWAMID+BoT+2023-12-19.
På detta möte godkändes uppdateringar av 6 organisationers IMPSer och några
fem informations- och diskussionspunkter togs upp.
God jul och gott nytt år på er alla!
Pål
Hej
Det har dykt upp ett fel när jag försöker logga in på https://metadata.swamid.se/admin. Får följande error " Missing member in either eduPersonScopedAffiliation or eduPersonAffiliation in SAML response".
När jag kollar releasecheck då är bägge attribut med. Någon som vet vad det kan bero på?
Vyacheslav Lytvynenko
IT-avdelningen
Högskolan i Skövde
Inloggning med Freja eID+ eller BankID
Studenter utan aktivt studentkonto kan nu logga in i en begränsad version av Ladok för studenter: Ladok för alumner. Inloggningen sker genom att besöka www.student.ladok.se<https://ladok.us13.list-manage.com/track/click?u=a1fd40c89d4197fd42c0981ab&…> och välja Ladok för alumner. Där går det sedan tidigare att logga in med Freja eID+, och från och med 6 december kan studenten även logga in med med BankID. De nya inloggningsmetoderna ger tillgång till en begränsad version av systemet där studenten bland annat kan hämta intyg och ansöka om examen. Det kommer också bli möjligt att hämta sitt examensbevis där när lärosätet väljer att börja använda den funktionaliteten. Så länge som studenten har ett aktivt studentkonto ska denne logga in med det kontot till Ladok för studenter. Inloggning med studentkonto ger tillgång till all funktionalitet som finns i Ladok för studenter, inklusive att hämta intyg och ansöka om examen.
Ingen inloggning för studenter utan svenskt personnummer eller studentkonto
För studenter utan svenskt personnummer finns för tillfället ingen möjlighet att logga in i Ladok när studentkontot inte längre är aktivt. För dessa studenter gäller att de fortfarande behöver kontakta sitt lärosäte i den här typen av ärenden. Vissa studenter har ett användarkonto på Antagning.se<https://ladok.us13.list-manage.com/track/click?u=a1fd40c89d4197fd42c0981ab&…> med sitt interimspersonnummer. Dessa kan fortsätta logga in i Ladok med konto från Antagning.se<https://ladok.us13.list-manage.com/track/click?u=a1fd40c89d4197fd42c0981ab&…> så länge det finns kvar. Gallring sker normalt 10 år efter senaste ansökan.
Steg mot ökad säkerhet i inloggningen
Ladokkonsortiet arbetar kontinuerligt med säkerhetsarbete. En viktig del i det arbetet är att säkerställa att de som loggar in i Ladok är de som de utger sig för att vara. Under 2023 infördes krav på att alla användare i Ladok för personal måste ha bekräftat sin identitet för att få tillgång till systemet, en säkerhetsnivå kallad SWAMID AL2. Under 2024 påbörjas arbetet med att införa säkerhetsnivån även i Ladok för studenter. Studenter kan vända sig till sitt lärosäte för mer information om när och hur bekräftelse av konto ska ske.
Idag loggar drygt 70% av alla studenter med svenskt personnummer in i Ladok med ett bekräftat användarkonto. 15 av 40 lärosäten har redan konfigurerat krav på AL2-nivå vid inloggning i Ladok för studenter med svenskt personnummer från 2024-01-01 eller tidigare. Dessa lärosäten har också konfigurerat ett varningsmeddelande som visas för studenter som loggar in med ett obekräftat användarkonto före startdatum för kravet på AL2-nivå.
Om ni inte kommer åt länkarna nedan, kontakta er Lokala tekniska kontaktperson för Ladok: https://ladok.se/om-oss/parter/lokal-teknisk-kontaktperson
För mer information om detta, se SWAMID AL2 i Ladok<https://ladok.us13.list-manage.com/track/click?u=a1fd40c89d4197fd42c0981ab&…>.
För mer detaljerad information om inloggning i Ladok för studenter utan svenskt personnummer, se Inloggning för studenter<https://ladok.us13.list-manage.com/track/click?u=a1fd40c89d4197fd42c0981ab&…>.
Nej.
Det jag skrev om handlar om validering av xml-filerna som du hämtar från mds.swamid.se.
Ditt problem beror på att er IdP inte skickar med member i eduPersonScopedAffiliation.
Testa på release-check.swamid.se och se vad den levererar.
// Björn M.
> On 4 Dec 2023, at 15:57, Sjöblom Alex <alex.sjoblom(a)fhs.se> wrote:
>
> Hej Björn
> Jag kan inte längre logga in mot https://metadata.swamid.se/ och får följande fel. Är det detta fel du menar?
>
> Errors:
> Missing member in either eduPersonScopedAffiliation or eduPersonAffiliation in SAML response
>
> / Alex
>
>
> -----Ursprungligt meddelande-----
> Från: Björn Mattsson <bjorn(a)sunet.se>
> Skickat: Monday, 4 December 2023 15:33
> Till: Swamid saml-admins <saml-admins(a)SWAMID.SE>
> Ämne: [Saml-admins] Ev problem med Metadatavalidering
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Hej.
> Vi har fått in 2 förfrågningar idag ang validerings-problem med SWAMID:s metadata.
>
> I samband med att vi publicerade bank-IdP:n dök det upp några XML-taggar som inte funnits tidigare.
>
> För er som validerar metadata och inte redan har följande schemat för (urn:oasis:names:tc:SAML:metadata:algsupport) inlagt bör lägga till detta för att inte få problem.
>
> Är inget nytt schema då det har funnits sedan 2010 men har som sagt inte använts i SWAMID fram tills nu.
>
> Schemat finns att hämta på
> http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-algsupp…
>
> // Björn Mattsson
>
> _______________________________________________
> Saml-admins mailing list -- saml-admins(a)lists.sunet.se To unsubscribe send an email to saml-admins-leave(a)lists.sunet.se
Hej.
Vi har fått in 2 förfrågningar idag ang validerings-problem med SWAMID:s metadata.
I samband med att vi publicerade bank-IdP:n dök det upp några XML-taggar som inte funnits tidigare.
För er som validerar metadata och inte redan har följande schemat för (urn:oasis:names:tc:SAML:metadata:algsupport) inlagt bör lägga till detta för att inte få problem.
Är inget nytt schema då det har funnits sedan 2010 men har som sagt inte använts i SWAMID fram tills nu.
Schemat finns att hämta på
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-algsupp…
// Björn Mattsson
Hej hej hallå,
Från och med nu kan man använda BankID med eduID.
Inför lanseringen hade vi ett utskick om eduID i info-brevet från Sunet,
som såg ut ungefär så här:
*Från och med nu går det att bekräfta sitt konto med BankID. Ett konto som
bekräftas med BankID uppnår samma tillitsnivå som med Freja, det vill säga
AL2. För att uppnå AL3 behöver en säkerhetsnyckel läggas till och bekräftas
med antingen Freja eller BankID.*
Passar på att skriva mer här, för de som är intresserade.
Vi använder oss av Sunets BankID-IdP (e-legitimation som tjänst) som
backend för våra förfrågningar.
eduID har ett eget certifikat som vi beställt och som används i vår
BankID-IdP. Det är bara eduID som kan prata med just vårt BankID-certifikat
- detta utgår från en vitlistning av entities som den tilliåts prata med -
det gör att det bara är eduID som kan göra uppslag med dess certifikat (som
debiteras eduID månatligen enligt Valfrihetssystem).
BankID kan i eduID användas på samma sätt som Freja, det vill säga för att
bekräfta sitt konto (koppla ett svenskt personnummer till kontot) samt vid
lösenordsåterställning som en andra faktor.
I början av nästa år kommer vi ta bort möjligheten att bekräfta konton i
eduID med hjälp av en telefonverifiering (alltså där ett mobilnummers
abonnentuppgifter jämförs med uppgifter i eduID-kontot). Under en
övergångsperiod kommer vi låta de verifieringar som redan gjorts med
telefon ligga kvar, medan vi samtidigt berättar för användarna som berörs
att de behöver göra en ny verifiering med en metod som även fortsatt kommer
vara godkänd, för att slutligen ta bort verifierings-status från de
återstående konton som inte genomgått en ny godkänd verifiering.
Vi känner att vi kan ta bort mobilverifiering som metod då den för
användargruppen med svenskt personnummer ersätts av BankID som på samma
sätt fungerar för majoriteten av användarna att snabbt få ett bekräftat
eduID-konto.
-- Zacharias, eduID
Hej!
Har en fråga som inte rör Swamid direkt.
Vi har startat en diskussion om e-postadresser hos oss. Anledningen är att en e-postadress i dagsläget inte kan ses som unik.
Har detta diskuteras i era egna organisationer?
Vad har ni kommit fram till och har ni infört något för detta hos er?
Roger Mårtensson
System specialist / Systemspecialist
MID SWEDEN UNIVERSITY
Avdelningen för infrastruktur / Division of infrastructure
E-mail: roger.martensson(a)miun.se<mailto:roger.martensson@miun.se>
Hej!
Historiskt har en Shibboleth Identity Provider per automatik fått Attribute Authority konfigurerat i sin metadata. Denna inställning ändrades i IdP version 4 där "SAML2.AttributeQuery" och "SAML1.AttributeQuery" kommenterats ut vilket skapar en metadata där AttributeAuthority är utkommenderat och tjänsten är avstängd.
Har en IdP uppgraderats från v3 till v4 är det ett ganska troligt att konfigurationen för detta (conf/relying-party.xml) lämnats orörd och således är AttributeAuthority fortsatt aktiverat. Många av SWAMID registrerade IdPer har kvar AttributeAuthority i sin metadata även om det mest troligt inte används alls (eller till och med avstängt i IdPn).
AttributeAuthority-sektionen i metadatan som är uppladdad till SWAMID innehåller SAML-certifikat som behöver underhållas och hållas giltiga likt övriga certifikat i övriga sektioner. SWAMID Operations uppmanar därför alla IdP-administratörer att slå ett öga på er konfiguration kring AttributeAuthority och samtidigt er metadata. Är AttributeAuthority påslaget och inget som ni vet med er används rekommenderas ni stänga av detta samt vid tillfälle uppdatera er metadata (går enkelt att ta bort via SWAMIDs metadata-verktyg). Är AttributeAuthority avstängt men ni ändå har kvar sektionen i metadatan uppmanas vi er till att när tillfälle ges ta bort sektionen i vårt verktyg.
Shibboleths dokumentation på ämnet finns här:
https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631691/SAML2Att…
Shibbolethens metadata går att komma åt via en webförfrågan på /idp/shibboleth. Exempel med curl och xmllint:
curl -ks https://idp2.test.inacademia.org/idp/shibboleth | xmllint --format -
I exemplet ovan är AttributeAuthority utkommenderat och tjänsten således avstängd.
--
jocar
SWAMID Operations
*Det går att skaffa en Freja e-legitimation med pass och använda som Svensk
e-legitimation*
Det innebär att metoden kan användas för att bekräfta sitt eduID-konto även
för de med svenskt personnummer och ett svenskt pass som inte redan har en
svensk e-legitimation, och som inte har möjlighet att besöka ett ATG-ombud.
Under genomgången igår var det fortfarande oklart om Frejas distansmetod
för att skapa en e-legitimation var godkänd av Digg. Vi fick sen klartecken
om att Freja+ som skapas med ett pass, på samma sätt som besök hos ett
ATG-ombud, är godkänd av Digg för LoA3 (tillitsnivå 3).
Osäkerheten uppstod då det är olika regelverk som Digg har ansvar för
gällande svensk e-legitimation, och nationell e-legitimation som används
inom eIDAS, vilket gjorde att vi om vartannat tidigare fått information att
Freja fått godkänt för sin pass-metod och inte än fått godkänt för den.
-- Zacharias
Hej
Repost från https://forum.sunet.se/s/swamid/
Jag har, efter gårdagens webinarium, funderingar kring vår tänkta implementation av en algoritm för att automatiskt matcha uppgifter från eduID mot Ladok (eller annat källsystem), det kan vara så att vi är på väg att göra några tankevurpor och behöver därför synpunkter/svar på några frågeställningar.
Först och främst tänker vi använda Levenshtein Distance <= 1 för att avgöra om två strängar(namn) kan anses vara samma, det ska hantera Thomas-Tomas, Andersson-Anderson etc.
Förnamn
Om vi från eduID får ANNA, ANDERSSON och vi i Ladok har en anna, anderson så är det en matchning - samma namn (i alla fall en tillräckligt liten skillnad).
Om det från eduID istället kommer ANNA BEDA, ANDERSSON så matchar fortfarande anna - det förnamn som finns i Ladok ingår bland de som finns i ID.
Samma med ANNA BEDA CLARA som matchas av anna clara - alla namn i Ladok finns i ID.
Har man exemplet ANNA BEDA och anna diana så bör det vara så att de inte matchar - olika namn även om anna är del av båda, alla namn i Ladok finns inte i ID.
Och då borde det även vara så att ANNA mot anna diana inte heller matchar - diana finns inte med i ID.
Regeln bör bli att alla namn i Ladok måste finnas i ID men att alla namn i ID inte behöver finnas i Ladok.
Tänker jag rätt här?
Finns det andra fall att ta hänsyn till?
Användande av e-post
Här blir jag mer osäker på hur man ska tänka.
Om vi har exemplet ANNA, ANDERSSON, född 19010101 med e-post aaa(a)example.org<mailto:aaa@example.org> och vi i Ladok hittar dessa personer med födelsedatum 1901-01-01
anna, andersson, pnr: 19010101-0000, e-post: aaa(a)example.com<mailto:aaa@example.com>
anna, anderson, 19010101-1111, bbb(a)example.org<mailto:bbb@example.org>
beda, bertilsson, 190101-2222, ccc(a)example.org<mailto:ccc@example.org>
Då blir det en skillnad om man applicerar jämförelse av e-post ihop med matchningen av varje tänkbar kandidat jämfört med om man först, enbart baserat på namn, plockar fram tänkbara kandidater och sedan verifierar att man endast hittat en (1) möjlig kandidat samt att den har rätt e-post.
I detta första fallet ser anna-0000 ut att vara en entydig matchning även om så kanske inte är fallet medans man i det andra fallet har två möjliga kandidater anna-0000 och anna-1111 och alltså inte kan göra en säker identifiering, eller?
Om man i det andra fallet använder e-post som "tiebreaker", använder man inte även då e-post för identifiering?
\Anders
