Hej,
Under 2022 har SWAMID arbetat med att förbättra kvalitén på publicerad
metadata för registrerade identitetsutfärdare och tjänster. Idag finns det
inga identitetsutfärdare som inte uppfyller SWAMIDs krav men det finns för
ögonblicket runt 70 tjänster som inte gör det även om vi försökt kontakta
dem alla ett flertal gånger. Inga sunettjänster finns kvar i den
kvarvarande listan!
Nu på måndag kommer vi att avregistrera alla tjänster som inte uppfyller
kraven i SWAMIDs regelverk och inom ett dygn kommer användarna få problem
att logga in i dessa. Om ni upptäcker problem ska ni hänvisa tjänsten till
operations(a)swamid.se. Vi har beredskap för att hantera frågorna samt hjälpa
till med handledning för hur man löser problemet.
De enda två undantagen vi gör är för tjänsterna ProjectPlace och Egencia.
Dessa byter entitetskategori för att få behövda attribut till REFEDS
Personalized Entity Category från SWAMIDs gamla entitetskategori SWAMID
Research and Education. Orsaken till undantaget är att ni som har
identitetsutgivare ska hinna få in stöd för den nya entitetskategorin.
Undantaget gäller fram till 28 februari!
Pål Axelsson
Hej!
Såg att det dök upp lite frågor om MFA så jag slänger ut min fråga i hopp om att någon har lite tips.
Vår IDP är konfad att använda vår ADFS via SAML Proxy. Fungerar finfint och plockar bort en del jobba onödiga inloggningar. Uppskattas av både personal och studenter.
Jag har försökt att sätta upp MFA-flödet för detta men får det inte riktigt att fungera mot vår M365 MFA-integrerade ADFS. Finns bra dokumentation om detta för Azure man kan inspireras av på Shibboleth wikin.
Problemet ligger i att det SAML-svar vi får som säger att nu har du loggat in med MFA kommer i ett eget attribut. Dvs "på fel sätt".
Enligt shibboleth-listan så ska det vara möjligt att skriva om svaret så att shibboleth stoppar in värdet på rätt ställe i SAML-svaret så att REFEDS-konfigurationen kan mappa om ADFS-svaret på ett korrekt sätt.
Så, är det någon som har några tips på vad man kan titta på för att komma vidare?
Förvirrad,
Roger Mårtensson
System specialist / Systemspecialist
MID SWEDEN UNIVERSITY
Avdelningen för infrastruktur / Division of infrastructur
E-mail: roger.martensson(a)miun.se<mailto:roger.martensson@miun.se>
Information about the processing of personal data at Mid Sweden University: www.miun.se/en/personaldata<http://www.miun.se/en/personaldata>
Hej,
Här kommer goda nyheter för er som kör SimpleSAMLphp i era system.
[image: :mega:] Great news! SimpleSAMLphp 2.0
<https://simplesamlphp.org/download/> has been released after many years of
preparation and it might be among the best versions of SimpleSAMLphp
released to date. Since many things have been cleaned up, it's essential to
read the upgrade notes
<https://simplesamlphp.org/docs/stable/simplesamlphp-upgrade-notes-2.0.html>
.
Pål
Hej
Med hänsyn till AL2 så kommer vi att utveckla en portal där våra användare kan logga in i för att höja sin AL-nivå.
Vi har pratat om att det kan ske via BankID, Freja eID och/eller federering mot AL2-konto hos eduID eller annat svenskt lärosäte i SWAMID.
Är det någon här som har gått igenom samma process och kan ge några tips?
Om ni har något att dela med er så får ni gärna kontakta mig: eric.johansson(a)ki.se<mailto:eric.johansson@ki.se>
Vi kommer utveckla vår lösning i .NET, så har ni erfarenhet eller t.o.m. kod så är vi intresserade av samarbete.
Hälsningar,
Eric Johansson | Drifttekniker
IT-avdelningen | 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<https://ki.se/medarbetare/integritetsskyddspolicy>.
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<https://ki.se/en/staff/data-protection-policy>.
En ganska enkel lösning är att bygga ett API som returnerar information om vilken MFA metod en användare har valt och konfigurerat.
Man kan anropa API:t från skriptet i mfa-authn-config.xml för att bestämma vad nextFlow ska vara. T.ex
var authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
var mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
var requestContext = input.getSubcontext("net.shibboleth.idp.profile.context.SpringRequestContext").getRequestContext();
usernameLookupStrategyClass = Java.type("net.shibboleth.idp.session.context.navigate.CanonicalUsernameLookupStrategy");
usernameLookupStrategy = new usernameLookupStrategyClass();
var userName = usernameLookupStrategy.apply(input);
if (mfaCtx.isAcceptable()) {
nextFlow=null
} else {
// Call to API to ascertain user's chosen MFA method
<insert code here to call external API and return method-info for userName>
if (hasMethod1) {
nextFlow="authn/method1";
} else if (hasMethod2) {
nextFlow="authn/method2";
} else {
// A flow to show a message about how to configure MFA
nextFlow="authn/none";
}
nextFlow; // pass control to second factor or end with the first
}
/Paul.
On 2022-02-15 10:15, Björn Wiberg wrote:
Hej allihopa!
Har någon av er implementerat logik i MFA-flödet i Shibboleth IdP som kollar vilken/vilka sorts MFA-varianter som tjänsten begärt?
Vid MFA så brukar man ju sätta idp.authn.flows=MFA i conf/authn/authn.properties och sedan implementera logiken i conf/authn/mfa-authn-config.xml för att kräva först användarnamn och lösenord och sedan vid behov en andra faktor.
Men hur gör man om den andra faktorn skall kunna variera?
T ex om man i Apache-konfigurationen för mod_shib (Shibboleth SP) angett:
ShibRequestSetting authnContextClassRef https://refeds.org/profile/mfa<https://refeds.org/profile/mfa%20%20för%20U2>
(för U2F)
...eller:
ShibRequestSetting authnContextClassRef saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken
(för TOPTP)
…och vill kunna stödja vilken som av dessa i Shibboleth IdP?
Man kan ju även ange flera "acceptabla" värden efter varandra och då får väl IdP:n välja bland dessa beroende på vad den stödjer och den ordning som den önskar tillämpa på de metoder den stödjer, och den ordningen får man väl förmodligen definiera själv på något sätt gissar jag…
Om man vill snappa upp det i checkSecondFactor() i conf/authn/mfa-authn-config.xml, hur gör man då?
Så här ser det ut i dagsläget:
<entry key="">
<bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/Password" />
</entry>
<entry key="authn/Password">
<bean parent="shibboleth.authn.MFA.Transition" p:nextFlowStrategy-ref="checkSecondFactor" />
</entry>
<bean id="checkSecondFactor" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">
<constructor-arg>
<value>
<![CDATA[
nextFlow = "authn/U2f";
authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
if (mfaCtx.isAcceptable()) {
nextFlow=null;
}
nextFlow; // pass control to second factor or end with the first
]]>
</value>
</constructor-arg>
</bean>
Här skulle jag alltså vilja läsa av mängden av begärda MFA-metoder och välja någon slags ordning för dessa (t ex i första hand TOTP och i andra hand U2F).
Hittar inget om detta i Shibboleth IdP-dokumentationen, även om jag börjat snegla på getPreferredPrincipals() (http://shibboleth.net/sites/release/java-identity-provider/4.1.5/apidocs/ne…)
Tacksam för alla tips! 😊
Med vänliga hälsningar / Best regards
Björn Wiberg
Uppsala universitet / Uppsala University
Avdelningen för universitetsgemensam IT / University IT Services
Infrastruktur och drift / Infrastructure and Operations
System Unix/Linux
---------------------------------------------------------------
saml-admins-at-swamid.se mailing list
Medlemskap/Arkiv etc finns p�:
http://segate.sunet.se/cgi-bin/wa?A0=saml-admins
---------------------------------------------------------------
--
Paul Scott <paul.scott(a)kau.se><mailto:paul.scott@kau.se>
Systemutvecklare, IT-avdelningen, Karlstads universitet
Tel: +46 (0)54-700 23 07
När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://www.kau.se/gdpr>.
When you send an e-mail to Karlstad University, we will process your personal data<https://www.kau.se/en/gdpr>.
För kännedom.
--
jocar
SWAMID Operations
> Begin forwarded message:
>
> From: "Cantor, Scott via announce" <announce(a)shibboleth.net>
> Subject: Shibboleth Service Provider Windows Service Release
> Date: 8 February 2023 at 15:03:47 CET
> To: "announce(a)shibboleth.net" <announce(a)shibboleth.net>
> Cc: "Cantor, Scott" <cantor.2(a)osu.edu>
> Reply-To: users(a)shibboleth.net
>
> A service patch to the SP Windows installer (V3.4.1.1) is now available. This patch includes an updated version of OpenSSL to address a set of security vulnerabilities disclosed yesterday. While the SP is likely not greatly (if at all) at risk, at least one of them was quite nasty so I updated it as a precaution.
>
> The patch release is available from the usual location. [1]
>
> The Release Notes [2] also highlight the fact that it's a strong suggestion at this point for any SP deployments to make sure the PKIX TrustEngine support is disabled, as it is essentially unused at this point but was left enabled implicitly for compatibility. Including it adds a lot of unnecessary attack surface and turning it off is a simple matter.
>
> -- Scott
>
> [1] http://shibboleth.net/downloads/service-provider/latest/
> [2] https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065335693/
>
>
> --
> To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net
Hej alla.
Vi håller på och byter ut vår Shibboleth-IdP och går från version 3.4.4 till 4.1.4 och allting ser ut att fungera bra förutom re-authentication vid attestering i Ladok.
Man möts av följande felmeddelande när man klickar på OK för att komma till vår IdP för en andra inloggning:
[cid:d358e3be-c146-4e98-b47d-48bf08b3dc80]
Utdrag ur idp-process.log:
2023-02-08 09:57:39,364 - 176.71.252.232 - INFO [net.shibboleth.idp.authn.impl.FilterFlowsByForcedAuthn:86] - Profile Action FilterFlowsByForcedAuthn: No potential authentication flows remain after filtering
2023-02-08 09:57:39,365 - 176.71.252.232 - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:455] - Profile Action SelectAuthenticationFlow: None of the potential authentication flows can satisfy the request
2023-02-08 09:57:39,366 - 176.71.252.232 - WARN [org.opensaml.profile.action.impl.LogEvent:101] - A non-proceed event occurred while processing the request: RequestUnsupported
2023-02-08 09:57:39,385 - 176.71.252.232 - INFO [Shibboleth-Audit.SSO:283] - 176.71.252.232|2023-02-08T09:57:39.341515Z|2023-02-08T09:57:39.385863Z||https://www.test.ladok.se/gui-sp||||||||false||Redirect|POST||Requester|urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext||Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0
Är det någon som har stött på någonting liknande i version 4.1+ av Shibboleth-IdP eller har idéer om hur man skulle kunna lösa problemet?
Vi signalerar inte att vi supportar MFA, varken i den nya eller den gamla IdP:n.
Med vänliga hälsningar
Jonny Ehrnberg
IT-arkitekt
Avdelningen för digitalisering och IT
Örebro universitet
