Hej.

Ja, vi skickar alltid tillbaka det som begärs (om det uppfylls).

Då Entra ID inte kan enforca lösenordsinloggning så skriver vi om ett inkommande lösenordskrav till ett MFA-krav mot Entra. När Entra svarar med MFA skrivs det tillbaka till det lösenordskravet som tjänsten begärde.

Om en inloggning inte begär någon speciell authnContext så svarar Entra med urn:oasis:names:tc:SAML:2.0:ac:classes:Password om det var en lösenordsinloggning, eller med urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified om det var lösenordslös inloggning.

Den enda tjänsten hittills som vi sett blir påverkad av detta är eduSign, som sparar svaret från inloggningen och begär samma metod vid signering. D.v.s. eduSign kan begära Unspecified vid signering om det var det den fick vid inloggningen.

Länken beskriver det vi redan gör. Den metoden mappar dock bara svaren mot en ursprunglig inkommande request. Vi har inte lyckats får den att skriva om svaret till PasswordProtectedTransport när det från början var odefinierat och Entra valde att skicka Password.

/Eric

On 14 Oct 2026, at 14:55, Björn Mattsson <bjorn@sunet.se> wrote:

Hej.

För att vara tydlig 
RequestedAuthnContext/AuthnContextClassRef är vad SP:n skickar till IdP:n. Kan vara en eller flera värden eller tomt.
AuthnContext/AuthnContextClassRef är vad som returneras från IdP:n till SP:n och är ett singelvärde och FÅR bara vara ett av de som fanns i RequestedAuthnContext/AuthnContextClassRef eller valfritt om det var tomt.

Dvs begär någon urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport så får ni inte svara med urn:oasis:names:tc:SAML:2.0:ac:classes:Password !!

Är inte många SP:er som faktiskt begär någon RequestedAuthnContext/AuthnContextClassRef och då är det helt OK att svara med  urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified i annat fall måste ni faila !

Med det sagt så bör ni nog skriva om urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified till urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport i de fall det begärs från SP:n. Skulle nog föredra det framför att faila inloggningen då det ger en sämre användarupplevelse. MEN det förutsätter att ni är 100% säkra på att det är likvärdigt eller bättre säkerhetsmässigt. Har inte helt koll på vad som kan generera urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified .


// Björn M.

On 14 Oct 2026, at 14:08, Eric Johansson via Saml-admins <saml-admins@lists.sunet.se> wrote:

Hej.

Vi vill stämma av en sak gällande hur vår IdP hanterar authnContextClassRef, då vi ibland kommer skicka värdet urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified till tjänster i federationen.

Vår inloggning kommer bygga på Microsoft Entra ID där användare ofta loggar in helt lösenordslöst. För oss känns det mest korrekt att skicka detta värde som det är, istället för att maskera inloggningen och skriva om den till urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, vilket inte är sant.

Entra ID skickar även urn:oasis:names:tc:SAML:2.0:ac:classes:Password. Vårt mål är att skriva om det till PasswordProtectedTransport, men det har vi inte lyckats med ännu. Så det kan också vara ett värde vi kommer skicka.

Vi utgår från att detta kommer fungera i federationerna, men säg till om ni ser några tekniska problem med det eller om ni har några invändningar.

Med vänlig hälsning,

Eric Johansson
Karolinska Institutet



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. 

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. 
_______________________________________________
Saml-admins mailing list -- saml-admins@lists.sunet.se
To unsubscribe send an email to saml-admins-leave@lists.sunet.se

<OpenPGP_0x8E2DA8EB05F646D7.asc>