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
Hej,
Under maj kommer vi att genomföra fysiska hackatons på Tulegatan i
Stockholm för att stödja processen att börja använda multifaktorinloggning
i sin IdP enligt SWAMIDs krav.
- SWAMID Hackaton 3-4 maj - Att i ADFS hantera multifaktorinloggning som
uppfyller SWAMIDs krav
<https://wiki.sunet.se/display/SWAMID/SWAMID+Hackaton+3-4+maj+-+Att+i+ADFS+h…>
- SWAMID Hackaton 23-24 maj - Att i Shibboleth IdP hantera
multifaktorinloggning som uppfyller SWAMIDs krav
<https://wiki.sunet.se/display/SWAMID/SWAMID+Hackaton+23-24+maj+-+Att+i+Shib…>
Mer information kommer senare men boka redan nu in detta i era kalendrar
och se till så att ni kommer till Stockholm på det hackaton som gäller er
programvara. Målet med hackatonet är att när ni gått därifrån så ska ni ha
fått verktygen för att implementera tekniskt stöd i er identitetsutfärdare.
Vi kommer även ge tips och rekommendationer om processerna om utfärdande av
multifaktormöjligheter till användare och hur ni skriver detta er i er
Identity Management Practice Statement (IMPS).
Pål
Hej
På dagens möte tog jag upp ett problem med inloggning till SDN som jag efter dagens session fick tillräckligt med info om för att kunna felsöka.
Det visade sig att jag hade <eduPersonPrincipalNameRessignable>true</eduPersonPrincipalNameRessignable> i config.SWAMID.xml vilket i vårt fall är fel då vi inte återanvänder samAccountName som vi använder för att bygga ePPN. När jag ändrat till <eduPersonPrincipalNameRessignable>false</eduPersonPrincipalNameRessignable> och importerat på nytt med
Import-AdfsTkMetadata -EntityId https://sp.snd.gu.se/module.php/saml/sp/metadata.php/default-sp -ConfigFile C:\ADFSToolkit\config\institution\config.swamid.xml -ForceUpdate
Så fungerar det som det skall. Vår ADFS släpper nameid-format:transient som den skall. (måste dock erkänna att jag inte riktigt förstår sambandet 😉 )
Mvh
Anders Persson
Systemarkitekt
Ekonomi och verksamhetsstöd - EoV
IT
D: +46 10 516 56 48 | V: +46 10 516 50 00
anders.persson(a)ri.se<mailto:anders.persson@ri.se>
RISE Research Institutes of Sweden | ri.se<http://ri.se/>
Brinellgatan 4 | Box 857, SE-501 15 Borås
Hej,
Ni som använder Shibboleth, antingen som IdP, SP eller bägge, får gärna
svara på denna enkät. Det är ett sätt för Shibboleth konsortiet att få
reda på mer om hur de ska jobba vidare med produkterna.
Pål
> -----Original Message-----
> From: members <members-bounces(a)shibboleth.net> On Behalf Of Cantor,
> Scott
> Sent: Wednesday, January 11, 2023 6:12 PM
> To: Shibboleth Consortium Members <members(a)shibboleth.net>
> Subject: Shibboleth Consortium Survey
>
> Hi,
>
> The Consortium Board asked me to circulate this to the membership, and
I'll
> be sending this to users afterward to cast a wider net.
>
> The Consortium has put together a survey to gather feedback about
current
> and future state of the project and the consortium, and we're hoping to
get
> as much feedback as we can, so your help is appreciated.
>
> In the case of NRENs, circulating this to your own membership would be
> welcome and appreciated.
>
> https://online1.snapsurveys.com/shibboleth
>
> Thanks.
> -- Scott
>
>
> _______________________________________________
> members mailing list
> members(a)shibboleth.net
> https://shibboleth.net/mailman/listinfo/members
FYI
Happy upgrading!
--
jocar
SWAMID Operations
> Begin forwarded message:
>
> From: "Cantor, Scott via announce" <announce(a)shibboleth.net>
> Subject: Shibboleth Identity Provider V4.3.0 now available
> Date: 18 January 2023 at 17:48:34 CET
> To: "announce(a)shibboleth.net" <announce(a)shibboleth.net>
> Cc: "Cantor, Scott" <cantor.2(a)osu.edu>
> Reply-To: users(a)shibboleth.net
>
> The Shibboleth Project is pleased to announce that the latest upgrade to the IdP is now available [1]. Please review the Release Notes for any pertinent information. [2]
>
> This is a minor release that is fully compatible with previous V4 releases, but does include some additional deprecation warnings in advance of the release of V5, which will be removing a number of features and APIs.
>
> One particular change can result in a number of warnings, particularly when using older versions of some plugins, so those plugins have been adjusted to report themselves incompatible with V4.3, and we have altered the documentation to suggest that people upgrade any plugins first, prior to applying this upgrade, to limit the noise encountered.
>
> We expect this to be the final release of the V4 branch, barring security issues, with all further work shifting to V5.
>
> -- Scott
>
> [1] https://shibboleth.net/downloads/identity-provider/latest/
> [2] https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631499
>
>
> --
> To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net
Hej,
För kännedom för er som har tjänster med användare från Ryssland kommer de
två ryska identitetsfederationerna uteslutas från eduGAIN nu på fredag.
Ryska användare som har loggat in via dessa ska inte heller kunna logga in
via SWAMID. Hänvisa inte dessa användare till eduID för att komma runt
sanktionskraven.
"Today the eduGAIN Secretariat informed RUNNET AAI and FEDURUS of a
decision made by the eduGAIN Executive Committee[1].
Due the requirements set out in Article 5l1 of COUNCIL REGULATION (EU)
2022/576 [2], the Committee has decided to remove RUNNET AAI and FEDURUS
memberships from eduGAIN as this is deemed to be direct support of
organisations within Russia to whom sanctions apply. The metadata of both
federations will be removed from the eduGAIN aggregation at 17:00
CET on Friday 20th January 2023.
The representatives of both federations have already been removed from the
edugain-sg mailing list.
[1] As eduGAIN is currently funded by the GÉANT project, the eduGAIN
Executive Committee is the GÉANT Board.
[2]
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32022R0576&fr…
"
Pål
SWAMID Hackaton 26 januari - Konfigurera de nya entitetskategorierna i ADFS
https://wiki.sunet.se/display/SWAMID/SWAMID+Hackaton+26+januari+-+Konfigure…
SWAMID Hackaton är en nygammal form av möte för att hjälpa varandra att
sätta upp och konfigurera användningen av SWAMID. När SWAMID startade 2007
genomfördes under flera år heldagars hackaton. Syftet med ett hackaton är
att man går från mötet med en klar implementation.
*Syfte*
SWAMID är en infrastruktur för att möjliggöra att användare kan använda
inloggningen i sin egen organisation för att logga in i webbaserade
tjänster i sin egen och i andra organisationer. För att detta ska fungera
måste organisationens identitetsutgivare skicka attribut, dvs. information
om användaren, till tjänsten.
Inom SWAMID har vi länge använt en metod som kallas entitetskategorier och
nu inför vi stöd för nya GDPR-vänligare kategorier. SWAMID inför stöd för
REFEDS nya entitetskategorier Personalized Access Entity Category,
Pseudonymous Access Entity Category, Anonymous Access Entity Category och
Data Protection Code of Conduct. Dessa ersätter SWAMIDs gamla
entitetskategorier SWAMID Research and Education och SFS 1993:1153 som inte
längre fungerar efter den 28 februari.
På detta hackaton konfigurerar vi tillsammans stöd i ADFS för
entitetskategorierna samt de nya identitetsattributen pairwise-id och
subject-id som i de nya entitetskategorierna ersätter attributen
eduPersonTargetedId resp. eduPersonPrincipalName. Senaste versionen av ADFS
Toolkit behövs för att de nya entitetskategorierna och attributen ska
fungera. Vid behov ingår också uppgraderingsstöd under hackatonet.
*Målgrupp*
Detta hackaton riktar sig till er som har en ADFS identitetutgivare (IdP)
registrerade i SWAMID.
*Datum & tid*
Torsdagen den 26 januari kl. 10:00-12:00
*Plats*
Zoom,
https://sunet.zoom.us/j/65070997766?pwd=WDhUOEdZL1A5YnJIKzFxZW5ZQ2xxUT09
*Handledare*
Johan Peterson och Tommy Larsson
*Material*
Eventuellt material publiceras efter mötet
Välkomna
Pål
SWAMID Hackaton 1 februari - Konfigurera de nya entitetskategorierna i
Shibboleth IdP
https://wiki.sunet.se/display/SWAMID/SWAMID+Hackaton+1+februari+-+Konfigure…
SWAMID Hackaton är en nygammal form av möte för att hjälpa varandra att
sätta upp och konfigurera användningen av SWAMID. När SWAMID startade 2007
genomfördes under flera år heldagars hackaton. Syftet med ett hackaton är
att man går från mötet med en klar implementation.
*Syfte*
SWAMID är en infrastruktur för att möjliggöra att användare kan använda
inloggningen i sin egen organisation för att logga in i webbaserade
tjänster i sin egen och i andra organisationer. För att detta ska fungera
måste organisationens identitetsutgivare skicka attribut, dvs. information
om användaren, till tjänsten.
Inom SWAMID har vi länge använt en metod som kallas entitetskategorier och
nu inför vi stöd för nya GDPR-vänligare kategorier. SWAMID inför stöd för
REFEDS nya entitetskategorier Personalized Access Entity Category,
Pseudonymous Access Entity Category, Anonymous Access Entity Category och
Data Protection Code of Conduct. Dessa ersätter SWAMIDs gamla
entitetskategorier SWAMID Research and Education och SFS 1993:1153 som inte
längre fungerar efter den 28 februari.
På detta hackaton konfigurerar vi tillsammans stöd i Shibboleth IdP för
entitetskategorierna samt de nya identitetsattributen pairwise-id och
subject-id som i de nya entitetskategorierna ersätter attributen
eduPersonTargetedId resp. eduPersonPrincipalName.
*Målgrupp*
Detta hackaton riktar sig till er som har en Shibboleth identitetutgivare
(IdP) registrerade i SWAMID.
*Datum & tid*
Onsdagen den 1 februari kl. 10:00-12:00
*Plats*
Zoom,
https://sunet.zoom.us/j/66959995672?pwd=SEhDVUtHNnBzTEhJYXlRNnBtU3JkUT09
*Handledare*
Paul Scott, Björn Mattsson och Johan Wassberg
*Material*
Eventuellt material publiceras efter mötet
Välkomna
Pål
