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
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
God fortsättning!
För kännedom, se nedan.
--
jocar
> A patch release of the Service Provider, V3.4.1, is now available [1][2]. This release fixes a couple of small bugs and adds a warning requested by one of our member organizations in the absence of the redirectLimit setting, which leads to SPs being abused as open redirectors.
>
> Notably, this release includes an update to the xmltooling library that hardens the code base against the sorts of attacks reported against the IdP in the recent advisory. The SP is, as far as can be determined, not impacted directly by that vulnerability, but this is a precautionary change.
>
> The Windows update also includes a change to restrict the ACLs on the /opt/shibboleth-sp directory when the default installation path is used, to limit some privilege escalation attacks due to overly permissive ACLs.
>
> The documentation has been updated to reflect this change [3], but we continue to observe that ultimately the responsibility for securing the file system lies with the deployer. We also urge caution and testing for those using IIS since the changes to the ACLs could prevent unusual IIS configurations from functioning without adjusting those ACLs.
>
> Packages have been pushed to at least a couple of the mirrors, but as has been typical, I'm not able to update all of them due to firewall changes, which I will follow up on.
>
> -- Scott
>
> [1] http://shibboleth.net/downloads/service-provider/latest/
> [2] https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065335693
> [3] https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065335545
Hej,
Kan lägga till svar från KTH här: även vi får in ärenden från slutanvändare som har problem med inloggning med ORCID via institutional-login. Vi har också själva kontaktat ORCID, men de verkar inte ta tag i problemet. Vore bra om SUNET kan kontakta dem igen och stöta på lite så att de förstår att det orsakar problematik för många användare.
/Rosa
Hej,
2022 har varit ett mycket arbetsintensivt år för oss som jobbar med policy
och infrastruktur runt SWAMID men även för er alla som har
identitetsutfärdare och tjänster registrerade i SWAMID. Med detta brev vill
jag tacka er alla för året som gått och allt det arbete ni har lagt ner
under både 2022 och de 15 år som SWAMID funnits.
Under perioden 2019 till 2021 genomförde SWAMID en omfattande uppdatering
och förtydligande av SWAMIDs policyramverk vilket gör att vi står på en
stabil bas inför framtiden. Den sista delen av policyn som uppdaterades
under 2021 var SWAMID SAMLS WebSSO Technology Profile och under 2022 har
den nya versionen införts. Införandet har inneburit mycket jobb för oss
alla men nu är metadata i SWAMID mycket mer korrekt och komplett. För att
allt detta arbete skulle vara möjligt tog SWAMID Operations fram ett helt
nytt metadataverktyg (https://metadata.swamid.se) som driftsattes i januari
och har förbättrats under året. Detta verktyg kommer att fortsättas att
utvecklas och vi är alltid intresserad av både buggrapporter och förslag på
förbättringar. I mitten av januari 2023 avslutas metadataöversynen och de
registrerade tjänster som då ännu inte har åtgärdat kvarvarande brister
kommer då att avregistreras.
För inloggning i tjänster ska fungera måste identitetsutfärdarna skicka
person- och organisationsuppgifter till tjänsterna i samband med
inloggning. Inom SWAMID kallar vi detta attributöverföring och för att
underlätta denna på ett GDPR-vänligare sätt används något som kallas
entitetskategorier. Entitetskategorier är en markering i metadata med
kringliggande regelverk som dels definierar vilka tjänster som har rätt
under vissa villkor att använda den specifika entitetskategorin och dels
vilka attribut som ska överföras. Under 2022 avvecklades SWAMID:s tio år
gamla entitetskategorier till fördel för en uppsättning internationellt
överenskomna entitetskategorier. Jag vill särskilt tacka alla
administratörer av identitetsutfärdare som har jobbat med att under de
senast tre månaderna införa stöd för fyra nya entitetskategorier som har
som mål att inte leverera mer person- och organisationsuppgifter till
tjänsten än vad den behöver för att användaren ska kunna använda den, dvs.
dataminimaliserande och integritetsbevarande attributöverföring. Samtidigt
har vi höjt tilltron till federativ inloggning eftersom Ladok men även
forskartjänster har börjat kräva att tillitsnivå, dvs. hur väl man vet att
det är rätt användare, signaleras till tjänsten vid inloggning. Alla
identitetsutfärdare har ännu inte genomfört dessa förändringar runt
attributöverföring men vi hoppas att så många som möjligt gör det så snart
som möjligt så att alla anställda och studenter kan logga in i de tjänster
de behöver för att genomföra sitt arbete resp. studier. För att testa och
verifiera attributöverföringen med hjälp av entitetskategorier har SWAMID
verktyget SWAMID Best Practice Attribute Release check (
https://release-check.swamid.se/)
Detta om 2022, vad kommer att hända under 2023? Under 2023 kommer SWAMID
inte att införa några nya krav eller regler utan att fortsätta stödja
införandet av de nya entitetskategorierna och jobba med inte tvingande
förändringar för att förbättra användningen av SWAMID. Vi vet att vissa
tjänster forskartjänster kommer under året införa krav på
multifaktorinloggning och därför kommer vi under våren att anordna
traditionella fysiska workshops eller hackatons runt installation och
konfiguration av multifaktorinloggning i identitetsutfärdare. Avsikten med
dessa workshops är att hjälpa alla organisationer som vill kunna erbjuda
multifaktorinloggning med hur man konfigurerar sin identitetsutfärdare.
Vidare kommer vi att fortsätta att modernisera SWAMIDs infrastruktur genom
att bland annat erbjuda nya förbättrade modeller för att hämta metadata.
Nuvarande modell för att hämta metadata kommer att finnas kvar så att denna
förändring inte är tvingande utan bara förbättrande.
Den tekniska miljön runt federativ inloggning håller på att förändras och
SWAMID Operations bevakar detta aktivt. Dels har det kommit nya federativa
tekniker såsom OpenID Connect Federation och digitala identitetsplånböcker,
dels håller leverantörerna av webbläsare på att göra dem mer
integritetsbevarande. Bägge dessa förändringar kommer att ge effekter på
sikt och vi jobbar aktivt med att se var vi är på väg och vad vi behöver
göra för att federativ inloggning kommer att fortsätta att fungera. Vi
återkommer med mer information under årets gång.
Med vänliga hälsningar
SWAMID Operations genom
Pål Axelsson
Hej,
2022 har varit ett mycket arbetsintensivt år för oss som jobbar med policy
och infrastruktur runt SWAMID men även för er alla som har
identitetsutfärdare och tjänster registrerade i SWAMID. Med detta brev vill
jag tacka er alla för året som gått och allt det arbete ni har lagt ner
under både 2022 och de 15 år som SWAMID funnits.
Under perioden 2019 till 2021 genomförde SWAMID en omfattande uppdatering
och förtydligande av SWAMIDs policyramverk vilket gör att vi står på en
stabil bas inför framtiden. Den sista delen av policyn som uppdaterades
under 2021 var SWAMID SAMLS WebSSO Technology Profile och under 2022 har
den nya versionen införts. Införandet har inneburit mycket jobb för oss
alla men nu är metadata i SWAMID mycket mer korrekt och komplett. För att
allt detta arbete skulle vara möjligt tog SWAMID Operations fram ett helt
nytt metadataverktyg (https://metadata.swamid.se) som driftsattes i januari
och har förbättrats under året. Detta verktyg kommer att fortsättas att
utvecklas och vi är alltid intresserad av både buggrapporter och förslag på
förbättringar. I mitten av januari 2023 avslutas metadataöversynen och de
registrerade tjänster som då ännu inte har åtgärdat kvarvarande brister
kommer då att avregistreras.
För inloggning i tjänster ska fungera måste identitetsutfärdarna skicka
person- och organisationsuppgifter till tjänsterna i samband med
inloggning. Inom SWAMID kallar vi detta attributöverföring och för att
underlätta denna på ett GDPR-vänligare sätt används något som kallas
entitetskategorier. Entitetskategorier är en markering i metadata med
kringliggande regelverk som dels definierar vilka tjänster som har rätt
under vissa villkor att använda den specifika entitetskategorin och dels
vilka attribut som ska överföras. Under 2022 avvecklades SWAMID:s tio år
gamla entitetskategorier till fördel för en uppsättning internationellt
överenskomna entitetskategorier. Jag vill särskilt tacka alla
administratörer av identitetsutfärdare som har jobbat med att under de
senast tre månaderna införa stöd för fyra nya entitetskategorier som har
som mål att inte leverera mer person- och organisationsuppgifter till
tjänsten än vad den behöver för att användaren ska kunna använda den, dvs.
dataminimaliserande och integritetsbevarande attributöverföring. Samtidigt
har vi höjt tilltron till federativ inloggning eftersom Ladok men även
forskartjänster har börjat kräva att tillitsnivå, dvs. hur väl man vet att
det är rätt användare, signaleras till tjänsten vid inloggning. Alla
identitetsutfärdare har ännu inte genomfört dessa förändringar runt
attributöverföring men vi hoppas att så många som möjligt gör det så snart
som möjligt så att alla anställda och studenter kan logga in i de tjänster
de behöver för att genomföra sitt arbete resp. studier. För att testa och
verifiera attributöverföringen med hjälp av entitetskategorier har SWAMID
verktyget SWAMID Best Practice Attribute Release check (
https://release-check.swamid.se/)
Detta om 2022, vad kommer att hända under 2023? Under 2023 kommer SWAMID
inte att införa några nya krav eller regler utan att fortsätta stödja
införandet av de nya entitetskategorierna och jobba med inte tvingande
förändringar för att förbättra användningen av SWAMID. Vi vet att vissa
tjänster forskartjänster kommer under året införa krav på
multifaktorinloggning och därför kommer vi under våren att anordna
traditionella fysiska workshops eller hackatons runt installation och
konfiguration av multifaktorinloggning i identitetsutfärdare. Avsikten med
dessa workshops är att hjälpa alla organisationer som vill kunna erbjuda
multifaktorinloggning med hur man konfigurerar sin identitetsutfärdare.
Vidare kommer vi att fortsätta att modernisera SWAMIDs infrastruktur genom
att bland annat erbjuda nya förbättrade modeller för att hämta metadata.
Nuvarande modell för att hämta metadata kommer att finnas kvar så att denna
förändring inte är tvingande utan bara förbättrande.
Den tekniska miljön runt federativ inloggning håller på att förändras och
SWAMID Operations bevakar detta aktivt. Dels har det kommit nya federativa
tekniker såsom OpenID Connect Federation och digitala identitetsplånböcker,
dels håller leverantörerna av webbläsare på att göra dem mer
integritetsbevarande. Bägge dessa förändringar kommer att ge effekter på
sikt och vi jobbar aktivt med att se var vi är på väg och vad vi behöver
göra för att federativ inloggning kommer att fortsätta att fungera. Vi
återkommer med mer information under årets gång.
Med vänliga hälsningar
SWAMID Operations genom
Pål Axelsson
Hej,
SWAMID Operations har under året påmint och tjatat om att under 2022
behöver alla gå igenom och fixa metadata för de identitetsutfärdare och
tjänster som man har registrerade i SWAMID efter att den uppdaterade
tillitsprofilen för SAML beslutades för ett år sedan. Ni har alla jobbat på
bra och mängden fel i metadata har krympt stadigt under hösten och jag vill
tack för allt arbete ni lagt ner.
Just nu har vi en IdP och 127 SP med fel i metadata och för att ni inte ska
oavsiktligt råka få tjänster avregistrerade ur SWAMID i mitten av januari
så bör ni gå in och kontrollera om ni har kvarvarande tjänster att åtgärda.
Detta gör ni enklast genom att gå till
https://metadata.swamid.se/admin/?action=ErrorStatus och välja fliken SP. I
sökrutan längst upp till höger i tabellen skriver ni därefter in er
organisations olika huvuddomännamn ett och ett för att se om ni det dyker
upp någon tjänst som behöver åtgärdas. Ni kan också skriva in namnet på
organisationen i olika stavningar och språk för att hitta tjänster som är
era men som inte ligger under ert domännamn. För Vetenskapsrådet skull jag
söka efter vr.se, vetenskapsrådet, research council, sunet och swamid.
Dessa sökningar kan ge en del ”false positive” men det är ju bättre än att
man missar tjänster som behöver åtgärdas.
Tack på förhand
Pål
Hej,
Här kommer en uppdatering från Shibboleth-konsortiet.
Pål
> -----Original Message-----
> From: announce <announce-bounces(a)shibboleth.net> On Behalf Of Cantor,
> Scott via announce
> Sent: Friday, December 16, 2022 11:29 PM
> To: announce(a)shibboleth.net
> Cc: Cantor, Scott
> Subject: Re: Shibboleth Identity Provider + OpenSAML Security Advisory
[16
> December 2022]
>
> I have updated this morning's advisory [1] to reflect the fact that
testing
> indicates the suggested workaround of updating the xmlsec jar on older
4.x
> installs seems to work fine, and made the instructions for that a bit
clearer.
>
> Nothing's changed, just clarifying that the possible workaround is in
fact
> sound. Thanks to CINECA for verifying that.
>
> -- Scott
>
> [1] https://shibboleth.net/community/advisories/secadv_20221216.txt
Hej,
Här kommer den security advisory för Shibboleth IdP som vi informerade om
tidigare i veckan. Det är nog bra om ni tog i detta innan jul.
Pål
> -----Original Message-----
> From: announce <announce-bounces(a)shibboleth.net> On Behalf Of Cantor,
> Scott via announce
> Sent: Friday, December 16, 2022 2:44 PM
> To: announce(a)shibboleth.net
> Cc: Cantor, Scott <cantor.2(a)osu.edu>
> Subject: Shibboleth Identity Provider + OpenSAML Security Advisory [16
> December 2022]
>
> Signed advisory follows.
>
> Upshot:
> This is for the IdP and also anyone using OpenSAML directly.
> Patch Java, patch Java, patch Java.
> The 4.2.x releases are basically safe because of xmlsec-2.3.0.jar
> Backporting
> xmlsec-2.3.0.jar in place of xmlsec-<earlier> probably works for any 4.x
> install but we haven't officially verified that.
>
> -- Scott
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Shibboleth Identity Provider Security Advisory [12 December 2022]
> OpenSAML-Java Security Advisory [12 December 2022]
>
> Older releases of the Shibboleth Identity Provider and OpenSAML-Java
> library are potentially vulnerable to attacks ranging from denial of
> service to
> remote code execution when given specially-crafted encrypted XML to
> decrypt. Some decryption use cases include unauthenticated message
> processing, so are widely accessible.
>
> While the current releases of both software products (V4.2.0+) are
> believed
> to be protected from the worst implications of this issue, many people
> operate older releases of both the Identity Provider and OpenSAML, so we
> are publishing this advisory in part as a courtesy.
>
> It is believed that the worst outcomes on older versions also depend on
> the
> use of non-current releases of the Java JDK, even as recent as those prior
> to
> August of 2022.
>
> At this time, it is believed that the risk of similar attacks in the
> Shibboleth SP
> are not significant. We will update this, and publish a second advisory in
> the
> event this determination changes.
>
> OpenSAML and IdP mis-handle malicious encrypted XML content
> ================================================================
> ======
> The XML Encryption specification, much as the original XML Signature
> specification, contains an over-abundance of generality in various areas,
> including the potential use of XSLT and XPath "transforms"
> as processing instructions while calculating the encrypted content to
> decrypt.
>
> SAML provides very specific guidelines for how signed XML needs to look,
> allowing pre-validation to prevent many problems. It provides much less
> guidance on this matter for encrypted XML.
>
> The OpenSAML Java library, up to and including V4.2.0, does not perform
> sufficient validation on the content to outright prevent execution of some
> malicious transforms. (OpenSAML V4.2.0 is present in the V4.2.x releases
> of
> the Shibboleth Identity Provider.) However, the Santuario XML
> Signature/Encryption library release (2.3.0) used by these versions of our
> software contains a default-on secure processing mode that precludes the
> worst of these attacks out of the box, and so we know of no immediately
> practical attacks against these versions of our software.
>
> Unfortunately, older versions of our software rely on older Santuario
> versions that do not default to this secure processing mode. They are
> therefore potentially vulnerable, and these attacks are able to exploit
> critical
> security vulnerabilities in versions of Java whose XSLT implementation has
> not been patched.
>
> There have been at least two remote code execution vulnerabilities
> reported
> against Xalan-J, and in turn against Java, in the past 8 years, one as
> recent as
> this past summer. As a result. versions of Java with patch levels older
> than
> August 2022 are believed to be vulnerable to at least one such issue.
>
> Note that the actual Java LTS release (Java 8, Java 11, Java 17) is not
> the
> relevant issue, but the underlying patch level of a given Java version.
> All of
> the sources of OpenJDK provide routine patch updates on a quarterly basis
> and these updates are critical. It is also crucial to use these LTS
> releases
> rather than "feature releases" such as Java 12-16, etc. due to the risk of
> missing out on such fixes.
>
> Recommendations
> ===============
> Review the versions of Java and the Identity Provider and OpenSAML
> software in your deployment. Make sure that Java is fully patched and
> current for whichever LTS release you are using, and take steps to ensure
> this
> remains true.
>
> Note that the Shibboleth Project does not distribute Java in any of our
> packaging, most particularly on Windows, where there is no built-in source
> of Java and maintaining currency requires additional effort. Some
> third-party
> packaging sources do include Java and you should ensure you are staying up
> to date via those sources.
>
> This Red Hat bug report [1] on one of the vulnerabilities mentions the
> specific
> patch levels released this summer that address the latest issue. Those
> Oracle
> patch levels refer to Java "in general"
> and may not apply in specific instances where vendors have distributed
> Java
> themselves (e.g., Debian and so on). When in doubt, always use "the
> latest"
> Java for your LTS version and platform.
>
> Obviously you should be taking steps to upgrade to a current IdP version,
> but
> the advice above is critical if you cannot do so quickly.
>
> While we do believe the older versions of our software are likely safe
> from
> the worst of the vulnerabilities provided Java is current, we do not
> believe
> that the risk of future attacks is insignificant, and so this is not a
> recommended long term answer.
>
> In the event that upgrading promptly is impossible (which would imply you
> should be considering alternatives), you MAY want to test a workaround of
> replacing the xmlsec-XXX.jar in dist/webapp/WEB-INF/lib with xmlsec-
> 2.3.0.jar [2] and then rebuild the IdP warfile to deploy the updated
> version.
>
> While we believe this is a compatible change for all V4.x IdP releases, we
> have not yet tested this workaround, but will update this advisory if and
> when we have. We do not know whether this is likely to help on releases
> prior to V4.0.0 and have no plans to investigate this.
>
> We will include an enhancement in all future releases of OpenSAML to
> harden the library against this class of attacks to the greatest extent
> possible.
>
> Credits
> =======
> Khoadha of Viettel Cyber Security
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2108554
> [2] https://repo1.maven.org/maven2/org/apache/santuario/xmlsec/2.3.0/
>
> URL for this Security Advisory:
> https://shibboleth.net/community/advisories/secadv_20221216.txt
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEE3KoVAHvtneaQzZUjN4uEVAIneWIFAmOcdOAACgkQN4uEV
> AIn
> eWIswxAAx3Y+XnffdX09uewIFxNQSr/MVeN+RjOCYGW4lwgaH5874ecIDTHW
> EQFz
> V4r/LE0pRgYQAILqSobPTRGEPUAwOPxX+7Tn7jPrTgWjcm/Xo3RzXx0m0NWXC
> joq
> /SIefIQ0O4EmF/KQ6y8EjixPcUn5dAf4YI+TutkBBlxozVXa9+GJS+4jvsi5Dgi1
> w+Dpbbw+WTI8iyAULPCa3tnuhPJ1PJJS9m09T2YRsVUxZKQ9E1ZL/OeaoREvPtr
> O
> TYzJSZs2B6bgSw10kHlXcKSH7vPZbokChGng7KPlLkkPP38p3yg3LdQLo5T1Fr6w
> 7Uwh43lVWlRMWXrQqyGY9o/cZjljVbR7nli+gjEOh8kpMXgyqHkVbb7IKLtes3vf
> tBlRS0Efo0oLj2Y5QyxfDT0Qr1U/Mh5BC6/YN4l/zr3pYTvNBOFgAWtgCyJkwbj3
> ruSA3hJxjiAHRMekUi1whMIVIM1xg1BRsTZxO9+UZ5SXXKM8rnGFNCM9pl447+
> tA
> k8bVshY19o9laHvPqPL8EjMNSaxl0GGR+kmmobABFnNc/XcCt/kJ3uL744wKzi7y
> XlfRivbz60IyPfiwsiN4Xv3iNWIRl7q+0XgRvSGr/buROChU7Kx/FjdnqChxB71B
> QgXGvdVN5UEy712EF5Jjsj0lNhblyomgHAjg1cZub53GO/75zfA=
> =ugFq
> -----END PGP SIGNATURE-----
>
>
> --
> To unsubscribe from this list send an email to announce-
> unsubscribe(a)shibboleth.net
FYI
--
jocar
SWAMID Operations
> Begin forwarded message:
>
> From: "Cantor, Scott via users" <users(a)shibboleth.net>
> Subject: IdP advisory forthcoming
> Date: 14 December 2022 at 02:13:07 CET
> To: "users(a)shibboleth.net" <users(a)shibboleth.net>
> Cc: "Cantor, Scott" <cantor.2(a)osu.edu>
> Reply-To: Shib Users <users(a)shibboleth.net>
>
> An IdP advisory will be coming soon, possibly by the end of this week. It's a bit unusual and isn't accompanying a patch. It involves risks to non-current IdP versions (i.e. not 4.2) primarily when Java isn't patched.
>
> The immediate risk is (extremely) critical, but is much lower if Java isn't out of date.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to users-unsubscribe(a)shibboleth.net
Hej
Jag har problem efter uppdatering till ADFS toolkit 2.2.1. Den kan ju släppa det nya attributet ”pairwise-id” men det nyttjar ett AD attribut norEduPersonLIN som vi inte har enligt nedan
<attribute type="urn:oasis:names:tc:SAML:attribute:pairwise-id" name="norEduPersonLIN" store="Active Directory"><file:///C:/ADFSToolkit/config/institution/config.SWAMID.xml><transformvalue adfstkstorefunction="pairwiseid"/></attribute>
Vi borde kunna använda något annat unikt som tex objectGUID eller?
Jag har också problem på en av två servrar att den klagar på att ADFSTkStore inte är registrerad. Jag får tre event i ADFS eventlog enligt följande:
EventID 111
-------------
The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.microsoft.com/idfx/requesttype/issue
Additional Data
Exception details:
Microsoft.IdentityServer.ClaimsPolicy.Language.PolicyEvaluationException: POLICY0017: Attribute store 'ADFSTkStore' is not configured.
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
EventID 303
The Federation Service encountered an error while processing the SAML authentication request.
Additional Data
Exception details:
Microsoft.IdentityServer.ClaimsPolicy.Language.PolicyEvaluationException: POLICY0017: Attribute store 'ADFSTkStore' is not configured.
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
EventID 365
-------------
Encountered error during federation passive request.
Additional Data
Protocol Name:
Saml
Relying Party:
https://service.projectplace.com/saml/metadata.xml
Exception details:
Microsoft.IdentityServer.ClaimsPolicy.Language.PolicyEvaluationException: POLICY0017: Attribute store 'ADFSTkStore' is not configured.
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.RequestBearerToken(WrappedHttpListenerContext context, HttpSamlRequestMessage httpSamlRequest, SecurityTokenElement onBehalfOf, String relyingPartyIdentifier, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, String& samlpSessionState, String& samlpAuthenticationProvider)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSerializedToken(HttpSamlRequestMessage httpSamlRequest, WrappedHttpListenerContext context, String relyingPartyIdentifier, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Ovan har jag enbart set på den sekundära server. Allt verkar ok, dll finns i c:\windows\adfs och
PS C:\Windows\system32> Get-ADFSTkStore
ADFSTkStore IS installed!
Installed Dll version is: 1.0.0.0
Dll version included in ADFSToolkit is: 1.0.0.0
PS C:\Windows\system32>
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,
För er som är inblandade i Ladok (som IdP för ett lärosäte som använder Ladok eller i annan form), här kommer status för införande av krav på SWAMID AL2 vid inloggning och arbete i Ladok. Denna information har också skickats ut till alla lokala objektägare, lokala kontaktpersoner och lokala tekniska kontaktpersoner för Ladok vid lärosätena.
Sedan SWAMID Board of Trustees<https://wiki.sunet.se/display/SWAMID/SWAMID+Board+of+Trustees> möte den 30/11 2022 så är 39 av 40 lärosäten i Ladok godkända för minst tillitsprofilen SWAMID AL2<https://wiki.sunet.se/display/SWAMID/Identity+Assurance+Level+2+Profile>. Bra jobbat, en eloge till er på IT-avdelningarna för respektive lärosäte!
I och med att lärosätet är godkänt för tillitsprofilen SWAMID AL2, så finns möjlighet att aktivera krav för denna nivå vid inloggning i Ladok för personal. Följande lärosäten har redan aktiverat detta krav, detta utskick är inte avsett för er:
* Chalmers tekniska högskola
* Enskilda Högskolan Stockholm
* Försvarshögskolan
* Göteborgs universitet
* Högskolan Dalarna
* Högskolan i Jönköping
* Högskolan i Skövde
* Johannelunds teologiska högskola
* Lunds universitet
* Newmaninstitutet
* Örebro teologiska högskola
För övriga lärosäten kommer krav på SWAMID AL2-nivå vid inloggning i Ladok för personal att gälla från och med 2023-07-01, se bifogad SWAMID AL2 i Ladok.pdf. Observera att för de användare som har tillgång till funktionen Nationell översikt kommer krav på SWAMID AL2-nivå att gälla för den funktionen redan från och med 2023-01-01.
Att SWAMID Board of Trustees godkänt er som lärosäte för tillitsprofilen SWAMID AL2 innebär att de granskat era processer för utdelning och hantering av användarkonton samt kringliggande infrastruktur och konstaterat att ni uppfyller kraven i SWAMID AL2-profilen. Förutom detta så behöver tre åtgärder genomföras innan Ladok får signalering om att en användare är bekräftad på SWAMID AL2-nivå i samband med inloggning:
* Det som lärosätet har blivit godkänd för måste också implementeras, både organisatoriskt och i systemen för identitetshantering
* Användaren behöver ha bekräftat sitt användarkonto, exempelvis genom en legitimationskontoll i er servicedesk
* Er inloggningstjänst (IdP) behöver signalera SWAMID AL2-nivå för användaren i samband med inloggning
Det är lämpligt att samtliga användare som har tillgång till funktionen Nationell översikt kontrollerar sin tillitsnivå och i förekommande fall bekräftar sitt användarkonto innan 2023-01-01. Kontroll kan göras längst ner på sidan i Ladok för personal vid "Autentiseringstyp":
* Om det står SWAMID AL2 har användaren rätt tillitsnivå för Nationell översikt
* Om det står SWAMID AL1 så behöver användaren bekräfta sitt konto
* Om det står SWAMID AL-nivå saknas så innebär detta att ingen tillitsnivå följer med i samband med inloggning och därmed behöver IT kontaktas så att de kan säkerställa att tillitsnivå signaleras vid inloggning
Kontroll kan också göras på https://ladok3.its.umu.se/kontrollera-al2/ där informationen är tydlig och användaren länkas vidare till lärosätets egna SWAMID AL2-hjälpsidor om SWAMID AL2-nivå saknas.
Säkerställ att ert eget konto uppfyller SWAMID AL2-nivå innan ni uppmanar era användare att testa ovanstående.
MVH
Fredrik Domeij, Ladok Operations
Fredrik Domeij
----------------------------------
Ladok Operations
IT-stöd och systemutveckling (ITS)
Umeå universitet
901 87 Umeå
----------------------------------
Telefon: +46 (0)90 786 65 43
Mobil: +46 (0)70 303 78 36
----------------------------------
fredrik.domeij(a)umu.se
www.umu.se/it-stod-och-systemutveckling
Hej,
Är det någon som har nån bra idé om varför idp-proxy-social.sunet.se säger
<ns0:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
<ns0:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" /></ns0:StatusCode>
<ns0:StatusMessage>Authentication failed. Error id [urn:uuid:13d25555-2ba8-48df-86e1-9c55c9142f8b]</ns0:StatusMessage>
</ns0:Status>
när jag försöker logga in på social.sunets.se? Jag är rätt säker på att vi skickar rätt grejer, https://personalized.release-check.swamid.se/ är i alla fall nöjd :)
/Björn
Hej,
Igår var det dags för årets sista SWAMID Board of Trustees. Förutom ett
antal godkännanden av SWAMID AL2 för lärosäten tackade vi av Valter som
ordförande för BoT. Protokollet finns publicerat på
https://wiki.sunet.se/display/SWAMID/SWAMID+BoT+2022-11-30.
Pål
Hallå!
Idag mellan ca 12.00 - 13.30 har vi haft problem metadatan för SPs i SWAMID som var registrerade för export till eduGAIN. Dessa SPs försvann från SWAMID (men fanns kvar i eduGAIN).
Problemet är åtgärdad i metadatan sedan runt 13.30 finns alla SPs tillbaka i SWAMIDs metadata.
--
jocar
SWAMID Operations
Hallå!
SWAMID Operations har av ett lärosäte informerats om att TimeEdit har kontakt med dem för att informera om att de måste göra en beställning på förändring av metadata för att uppfylla SWAMIDs nya teknikprofil. Arbetet efter denna beställning kommer att faktureras utanför det som ingår som standard i avtalet med lärosätet. Beräknad tid sannolik tid för förändringen är två timmar.
För de lärosäten som har fel i metadata för sina TimeEdit-instanser och som inte innefattar certifikatsbyte kan eventuellt göra denna uppdatering själva. Den svårast informationen som behöver uppdateras är vanligtvis en länk till information om tjänsten till slutanvändarna samt information om behandling av personuppgifter. Sidan till informationslänken borde ni redan idag ha för att informera era användare om tjänsten. Ni borde även kunna använda lärosätets generella information om hur lärosätet hanterar personuppgifter men läs igenom och verifiera.
--
jocar
SWAMID Operations
Hallihallå!
SWAMID Operations har fått till sig att både Egencia och Projectplace kommer snarast möjligt försöka gå över på REFEDS Personalized för attribut-release.
Vi uppmanar därför alla IdP-administratörer på lärosäten som är kund av någon av dessa företag snarast möjligt se till att er IdP stödjer de nya kategorierna.
Är du inte rätt mottagare på lärosätet för denna information så sprid den gärna vidare till någon som sysslar med IdPn eller är ansvarig för tjänsterna ovan.
För mer information om kategorierna se vår wiki:
https://wiki.sunet.se/display/SWAMID/Entity+Category+attribute+release+in+S…
--
jocar
SWAMID Operations
Hej,
För knappt en månad sedan den 20 oktober presenterade SWAMID på
Sunetdagarna att vi inför fyra nya GDPR-vänliga entitetskategorier. En av
dessa nya entitetskategorier ersätter SWAMIDs gamla entitetskategori SWAMID
Research and Education för alla tjänster som idag har den. Eftersom de
gamla entitetskategorin kommer att fullständigt avvecklas vid årsskiftet
rekommenderar vi alla identitetsutfärdare att införa stöd så fort som
möjligt för de nya entitetskategorierna.
*Följande är de nya entitetskategorierna:*
- *REFEDS Anonymous Access Entity Category* - Kategorin avser tjänster
som erbjuder en servicenivå baserad endast på bevis på framgångsrik
autentisering samt vissa organisationsattribut, möjliggör ingen
personifiering baserat på en användaridentifierare.
- *REFEDS Pseudonymous Access Entity Category* - Kategorin avser
tjänster som erbjuder en servicenivå baserad på bevis på framgångsrik
autentisering samt möjliggör personifiering baserat på en pseudonym
användaridentifierare.
- *REFEDS Personalized Access Entity Category* - Kategorin avser
tjänster som erbjuder en servicenivå baserad på bevis på framgångsrik
autentisering samt möjliggör personifiering baserat på en organisationsunik
användaridentifierare, namn och e-postadress, ersätter SWAMID Research and
Education.
- *REFEDS Data Protection Code of Conduct Entity Category (CoCov2)* -
Kategorin avser tjänster som antingen inte uppfyller kraven för övriga
kategorier eller har behov andra attribut, t.ex. personnummer, än de som
erbjuds i övriga kategorier, ersätter på lång sikt CoCov1 men bägge behöver
stödjas parallellt.
*Följande är de gamla entitetskategorierna som behålls:*
- *REFEDS Research and Scholarship Entity Category (R&S)* - Kategorin
avser tjänster som direkt stödjer forskning och utbildning baserad på bevis
på framgångsrik autentisering samt möjliggör personifiering baserat på en
organisationsunik användaridentifierare, namn och e-postadress.
- *Géant Data Protection Code of Conduct Entity Category (CoCov1)* -
Kategorin avser tjänster som antingen inte uppfyller kraven för övriga
kategorier eller har behov andra attribut, t.ex. personnummer, än de som
erbjuds i övriga kategorier, ersätts på lång sikt CoCov2 så bägge behöver
stödjas parallellt.
- *European Student Identifier Entity Category (ESI)* – Kategorin avser
tjänster som har behov av European Student Identifier, t.ex. tjänster runt
Erasmus+.
*Följande är de gamla entitetskategorierna som slutligen avvecklas:*
- *SWAMID Research and Education* - Ersätts av både Personalized Access
och R&S beroende på vilken typ av tjänst det är. Även CoCov2 och CoCov1
används som ersättare i vissa fall.
- *SWAMID SFS 1993:1153* - Ersätts av CoCov2 och CoCov1.
Som ni ser så hör REFEDS tre nya entitetskategorier Anonymous Access,
Pseudonymous Access och Personalized Access ihop i en hierarki. De tjänster
som endast behöver veta att en användare tillhör en viss organisation
använder Anonymous Access, de tjänster som vill kunna ge användaren en mer
personifierad åtkomst men utan behov av namn och e-postuppgifter använder
Pseudonymous Access och till sist de tjänster som behöver full
personalisering använder Personalized Access. Denna hierarki gör att
tjänster inte behöver begära mer information än de behöver för att leverera
tjänsten till användarna, s.k. dataminimalisering runt personuppgifter.
SWAMIDs standardmallar för både Shibboleth och ADFS tar hänsyn till
minimeringen på så sätt att om en tjänst begär mer än en av dessa tre får
tjänsten attribut baserat på den som är mest dataminimerande, dvs. begärs
både Anonymous Access och Pseudonymous Access används den förstnämnda.
För er som använder ADFS Toolkit finns nu en ny version 2.2.0 som har stöd
för både de nya entitetskategorierna samt de nya identitetsattributen som
krävs. Ni hämtar senaste versionen på adressen
https://www.powershellgallery.com/packages/ADFSToolkit/. Praktisk
information finns i sunetdagarpresentationen 11-11.45 den 20 oktober.
För er som använder Shibboleth IdP finns detaljer om hur ni kommer i gång
med de nya entitetskategorierna även de i sunetdagarpresentationen 11-11.45
den 20 oktober. Självklart innehåller även standardmallarna för Shibboleth
på SWAMIDs wikisidor denna konfiguration.
*Att signalera tillit*
Som alla lärosäten vet börjar Ladok kräva att de personer som har tillgång
till modulen nationell översikt uppfyller kraven för SWAMID AL2 från och
med kommande årsskifte. Förutom att alla aktuella användarnas måste
valideras för SWAMDI AL2 enligt de metoder som ni är godkända för måste
identitetsutfärdaren även signalera godkända tillitsnivåer till Ladok och
andra tjänster. Ladok kommer att från och med sommaren kräva SWAMID AL2 för
alla anställda som loggar in i Ladok från och med halvårsskiftet 2023. Om
ni inte är godkända för SWAMID AL2 eller om ni inte signalerar SWAMID AL2
för de användare som uppfyller kraven kommer de inte kunna logga in i
Ladok. Aktuell status för vilka som är godkända för SWAMID AL2 finns i
medlemslistan på SWAMIDs wiki,
https://wiki.sunet.se/display/SWAMID/SWAMID+Members. De lärosäten som ännu
inte är godkända för SWAMID AL2 arbetar för fullt med att bli det.
Från och med i januari kommer även EuroHPC-datorn Lumi via
identitetsinfrastrukturerna MyAccessId och Puhuri börja kräva
tillitssignalering via REFEDS Assurance Framework (RAF). SWAMID
tillitsramverk uppfyller kraven i RAF och det är enkelt att signalera RAF
baserat användarens tillitsprofiler. Även detta finns stöd för i
standardmallarna för både Shibboleth och ADFS. Tänk på att de flesta
lärosätena och andra forskningsorganisationer i Sverige har minst en
användare eller forskningsgrupp som är beroende av att kunna använda Lumi
inom ramen för sin forskning.
För att få veta mer om förändringarna runt entitetskategorier och att
signalera tillitsnivåer kan ni ta del av presentationerna från den 20
oktober på Sunetdagarnas wikisida https://wiki.sunet.se/x/yJyvBg. Om ni som
identitetsutfärdare behöver mer information eller lite hjälp hör av till
SWAMID Operations, operations(a)swamid.se.
*Så i korthet behöver ni göra följande före julledigheterna:*
- *Aktivera stöd för de nya entitetskategorierna i era
identitetsutfärdare*
- *Konfigurera så att ni kan släppa både SWAMIDs tillitsprofiler och
REFEDS Assurance Framework till de tjänster som behöver det*
- *Testa attributreleasen i SWAMIDs testverktyg
https://release-check.swamid.se <https://release-check.swamid.se>*
- *När ni får grönt på attributreleasen gå in på
https://metadata.swamid.se/admin <https://metadata.swamid.se/admin> och
uppdatera vilka entitetskategorierna ni stödjer i er identitetsutfärdare*
Pål Axelsson
Hej!
Jag försöker hämta min EPPN men får fel :
https://release-check.swamid.se/
Se felet nedan:
[cid:ce19605c-440c-43b5-a2ca-cfa6cf5d7f9c]
Med vänlig hälsning
Ingimar Erlingsson
[Beskrivning: Description: Description: Description: Description: nrm_logo]
Ingimar Erlingsson
System Developer
Department of Bioinformatics and genetics
+46 (0)8 519 540 68
+46 (0)70 658 24 14
Naturhistoriska riksmuseet
Box 50007
104 05 Stockholm
Besöksadress: Frescativägen 40
www.nrm.se
<http://www.nrm.se/>
P please consider the environment before printing this e-mail
För Node.js finns det ett SAML-bibliotek kallat node-saml.
De har nu funnit ett säkerhetshål i detta bibliotek som gör att man kan bypass inloggningen i vissa fall.
Om ni kör med detta bibliotek kan det vara dags att uppdatera.
Mer info på https://github.com/node-saml/passport-saml/security/advisories/GHSA-m974-64…
Björn Mattsson
bjorn(a)sunet.se
Hej,
Alla entitetskategorier som rekommenderas inom SWAMID har något som heter
”entity support category”. Detta innebär att ni som har identitetsutgivare
registrerade i SWAMDI kan och bör i ert metadata registrera vilka
entitetskategorier ni har stöd för. Detta stöd har funnits länge men vi har
lagt till möjligheten för att lägga till det för de nya GDPR-vänliga
entitetskategorierna som presenterades på Sunetdagarna. Vi har också saknat
möjligheten att markera att IdP:n stödjer entitetskategorin för European
Student Identifier (ESI), detta är nu fixat.
VI skulle uppskatta om ni kunde gå in och verifiera att era IdP:er har
markering för stödda entitetskategorier.
Till sist så har vi även skapat en statistiksida under fliken ”ECS
statistics” när man är inloggad på https://metadata.swamid.se/admin.
Tack på förhand
Pål
Hej,
Ni som har identitetsutgivare (IdP) registrerad i SWAMID är hjärtligt
välkommen på nedanstående webinarium. Om ni inte är klara med ESI-arbetet
så är det viktigt att ni kommer. Informationen kommer i princip vara samma
som i våras men ni kan ställa frågor.
Pål
*From:* Eplushögre <eplushogre(a)uhr.se>
*Sent:* Monday, October 10, 2022 11:05 AM
*To:* DL_Erasmus_ansvariga <Erasmus_ansvariga(a)uhr.se>
*Subject:* Webbinarium - implementering av ESI, 7 november
*Till Erasmusansvariga*
*Vänligen skicka vidare denna inbjudan till berörd personal vid ert
lärosäte, tillsammans med det PM som bifogas. *
Hej,
UHR erbjuder tillsammans med SUNET ett webbinarium för teknisk personal för
att informera om implementeringen av ESI. ESI ska implementeras under
2022, alltså snarast möjligt*. *
*Användandet av ESI är en nödvändighet för fortsatt deltagande i Erasmus+
efter 2022.*
Som del av *European Student Card Initiative* är den europeiska
studentidentifieraren (ESI) en förutsättning för deltagande i Erasmus+ och
det är lärosätet som ansvarar för att utfärda ESI. Mer information om ESI
finns i bifogat PM som ni kan använda som underlag i intern kommunikation.
*Webbinarium – ESI *
*Måndag 7 november*
*Kl. 14.00-15.00*
*Zoom:*
https://uhr-se.zoom.us/j/69795594385?pwd=WEtUaVBzR3QvNFJsYUYrVzB3bVdNdz09
Meeting ID: 697 9559 4385
Passcode: 565349
Med vänliga hälsningar,
_____________________
*Frida Garvill*
Handläggare, Erasmus+ högre utbildning
Avdelningen för internationellt samarbete
frida.garvill(a)uhr.se
Telefon: 010-470 04 94
Växel: 010-470 03 00
Universitets- och högskolerådet
Box 4030
171 04 Solna
www.uhr.sewww.utbyten.se
När du skickar e-post till Universitets- och högskolerådet behandlar vi
dina uppgifter i enlighet med gällande lagstiftning.
Så behandlar Universitets- och högskolerådet personuppgifter (uhr.se)
<https://www.uhr.se/om-uhr/sa-har-behandlar-uhr-personuppgifter/>
Hej,
För kännedom...
Trevlig helg
Pål
> -----Original Message-----
> From: announce <announce-bounces(a)shibboleth.net> On Behalf Of Cantor,
> Scott via announce
> Sent: Thursday, November 3, 2022 2:01 PM
> To: announce(a)shibboleth.net
> Subject: Shibboleth Service Provider V3.4.0 now available
>
> The Shibboleth Project has released a small update to the Service Provider
> software. This is essentially a small patch but contains a new
> configuration
> setting so is a minor update to V3.4.0.
>
> Various libraries have been updated for this release, and the Windows
> package
> contains the latest security updates for OpenSSL and libcurl. At this
> time, it is not
> believed that any of those vulnerabilities impacts the SP but the OpenSSL
> patch is
> advisable out of caution.
>
> Source and windows packages are available [1] and the RPM packages will be
> pushed to the mirrors this morning.
>
> Release notes are at [2].
>
> -- Scott
>
> [1] http://shibboleth.net/downloads/service-provider/3.4.0/
> [2] https://wiki.shibboleth.net/confluence/display/SP3/ReleaseNotes
Hej,
Nu är det dags för höstens Sunetdagar. De kommer även i höst pågå virtuellt
under tre veckor (11-27 oktober) och det fullständiga programmet finns på
adressen https://wiki.sunet.se/x/yJyvBg.
För SWAMID så finns följande programpunkter:
-
*Torsdag 13 oktober 09.00-09.45: Metadata i SWAMID *Ett trekvarts år med
SWAMIDs nya metadataverktyg, vilka är erfarenheterna och vad har förändrats.
Vid årsskiftet måste alla identitetsutgivare och tjänster som är
registrerade i SWAMID uppfylla SWAMIDs beslutade teknologiprofil för SAML
WebSSO. Hur kan metadataverktyget hjälpa till med detta?
-
*Torsdag 20 oktober 10.00-10.45: Rekommenderad attributrelease i SWAMID -
Vad är på gång och varför? *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 kommer det nya GDPR-vänliga kategorier.
-
*Torsdag 20 oktober 11.00-11.45: Rekommenderad attributrelease i SWAMID -
Hur gör vi? *Del 2 om attributrelease beskriver hur vi tekniskt
implementerar och testar de nya entitetskategorierna för både Shibboleth
och ADFS.
-
*Torsdag 27 oktober 10.00-10.45: Vad är på gång i SWAMID? *Under de senaste
åren har mycket fokus lagts på att uppdatera SWAMID policyramverk men nu
skiftar fokus till tekniska förbättringar i SWAMIDs tekniska infrastruktur.
Vi kommer bland annat att presentera vårt arbete med nytt och
kompletterande sätt att hämta metadata samt planerna på en helt ny QA-miljö
som ersätter SWAMIDs testmiljö.
Välkomna
Pål
Hej,
Det går framåt med uppdateringen för alla entiteter när det gäller de
uppdaterade metadatakraven. Just nu är det 2 identitetsutfärdare som inte
är ok, en var men sedan gick giltighetstiden för certen ut. När det gäller
tjänsterna så är siffrorna lite annorlunda, just nu är det 285 som inte är
ok. Komihåg att alla måste vara ok för årsskiftet för att inte
avregistreras från SWAMID.
Så här ser status för tjänsterna ut just nu:
Vi har också försökt analysera vem som använder de olika tjänsterna och då
kommit fram till nedanstående graf och tabell.
*Organisationer med två eller färre fel*
- Blekinge Tekniska Högskola
- Enskilda Högskolan Stockholm
- Gymnastik- och idrottshögskolan
- Högskolan Dalarna
- Högskolan Kristianstad
- Högskolan Väst
- Högskolan i Gävle
- Högskolan i Halmstad
- Institutet för rymdfysik
- Jönköping University
- Kungliga Musikhögskolan
- Kungliga biblioteket
- Mittuniversitetet
- Röda Korsets Högskola
- Sophiahemmet Högskola
För de flesta som har 1-3 tjänster som inte är klara handlar oftast
tjänster som ni köper, t.ex. Egencia, Primula och TimeEdit. Det är bra om
ni ser till så att de leverantörerna fixar sina metadata, SWAMID Operations
har tjatat på dem men det behövs även från er.
Pål
Tjo!
Vårt bibliotek har börjat arbete med att använda verktyget Dynamica
från https://scifree.se för OpenAccess-publicering.
Jag ser att det är många av oss (Paul, Tommy m.fl.) som använder sig av
deras Journal Search Tool[1].
Är det någon som har någon kontakt med dom angående SSO eller liknande?
Jag inser att vi verkar vara i ett pilotprojekt för Dynamica-tjänsten
och ingen annan verkar använda den ännu. Men mitt mål är ju att den ska
bli en tjänsteleverantör i SWAMID och det verkar rimligt att dom hamnar
i <http://refeds.org/category/research-and-scholarship>.
MVH
- Simon
1,
<https://scifree.se/scifree-jst#page-section-5fa9103544651c5602044401>
Hallå,
Nej, ni behöver inte göra några förändringar. Om det är så att ni skickar
data men era data inte syns ta kontakt med operations(a)swamid.se.
Pål
*From:* Eric Johansson <eric.johansson(a)ki.se>
*Sent:* Tuesday, September 13, 2022 12:49 PM
*To:* Pål Axelsson <pax(a)SUNET.SE>
*Cc:* saml-admins(a)swamid.se
*Subject:* Re: [Saml-admins] Flytt av statistik för SWAMID
Hej,
Behöver vi som skickar F-TICKS auditing till syslog.swamid.se göra några
ändringar?
/Eric
On 13 Sep 2022, at 13:15, Pål Axelsson <pax(a)SUNET.SE> wrote:
Hej,
SWAMID har ersatt flog.swamid.se
<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fflog.swami…>
med tjänsten F-ticks statistics i eduGAIN (https://f-ticks.edugain.org
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ff-ticks.e…>)
för F-ticks i SAML. Orsaken till detta är att den teknik vi använde när vi
byggde den för en massa år sedan inte riktigt har klarat av mängden data
som har ackumulerat över tiden.
Den nya tjänsten i eduGAIN är byggd för att klara mycket större datamängd
men också har modernare verktyg för analysera datat. SWAMID har i drygt ett
år skickat de avpersonaliserade f-ticksmeddelandena vidare till den nya
tjänsten så det finns begränsat historiskt data tillgängligt redan nu.
Om ni idag inte skickar användningsstatistik till SWAMID och vill göra det
hör av er till operations(a)swamid.se för mer information. Att använda
statistik via f-ticks ger er som IdP bättre möjlighet att visa på
användningen av tekniken men även SWAMID och eduGAIN samma möjlighet i
större skala.
Pål
_______________________________________________
Saml-admins mailing list -- saml-admins(a)lists.sunet.se
To unsubscribe send an email to saml-admins-leave(a)lists.sunet.se
*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>.
Hej,
SWAMID har ersatt flog.swamid.se med tjänsten F-ticks statistics i eduGAIN (
https://f-ticks.edugain.org) för F-ticks i SAML. Orsaken till detta är att
den teknik vi använde när vi byggde den för en massa år sedan inte riktigt
har klarat av mängden data som har ackumulerat över tiden.
Den nya tjänsten i eduGAIN är byggd för att klara mycket större datamängd
men också har modernare verktyg för analysera datat. SWAMID har i drygt ett
år skickat de avpersonaliserade f-ticksmeddelandena vidare till den nya
tjänsten så det finns begränsat historiskt data tillgängligt redan nu.
Om ni idag inte skickar användningsstatistik till SWAMID och vill göra det
hör av er till operations(a)swamid.se för mer information. Att använda
statistik via f-ticks ger er som IdP bättre möjlighet att visa på
användningen av tekniken men även SWAMID och eduGAIN samma möjlighet i
större skala.
Pål
Hej,
Som ni alla vet så beslutade SWAMID Board of Trustees om uppdaterad
teknologiprofil för SAML WebSSO i december förra året. Denna uppdatering
innebär att i princip alla identitetsutgivare och tjänster som är
registrerade i SWAMID måste uppdatera sina metadata och SWAMID Board of
Trustees gav en tidsfrist fram till årsskiftet detta år. Arbetet fortgår
men nu börjar det bli lite bråttom för de som ännu inte uppdaterat sina
metadata eftersom om man inte gjort det innan årsskiftet kommer
identitetsutfärdaren eller tjänsten att avregistrerad från SWAMID. Sunets
kontaktpersoner vid anslutna organisationer påmindes om detta i månadens
månadsbrev,
https://wiki.sunet.se/display/info/Info-utskick+2022-09-07#Infoutskick20220…
.
För närvarande har fortfarande 6 identitetutgivare (10%) och 390 tjänster
(62%) ännu inte åtgärdat sina fel i metadata. För att det ska vara enklare
för er att se vilka entiteter ni behöver uppdatera har SWAMID Operations
skapat listor som uppdateras automatiskt vilka identitetsutgivare
respektive tjänster som behöver uppdateras på
https://metadata.swamid.se/admin/?action=ErrorStatus. Det finns underflikar
för IdP och SP samt för vissa specifika fel. Det är möjligt att söka i
respektive tabell genom att använda sökrutan längst upp till höger i
tabellen samt sortera med genom att klicka på aktuell kolumn i
tabellhuvudet.
Aktuell sammanfattande status inkl. grafer finns på
https://metadata.swamid.se/admin/?action=ErrorStatistics.
Om din organisation inte har en IdP registrerad i SWAMID och vill
kontrollera aktuell status för era tjänster kan du skapa ett eduID-konto på
eduID.se för att logga in på metadata.swamid.se.
SWAMID Operations
Pål Axelsson
Hej,
Våra (lokala) förvaltare av Sunet Survey tittar på att börja använda organisationstillhörighet i Sunet Survey. Enligt kommunikationen de har haft med supporten så skall vi meddela vilka attribut vi släpper för detta så att de sedan (mot konsultarvode) kan mappa in det i deras system.
Skulle någon kunna peka mig på någon dokumentation, best practice etc gällande detta? Alternativt ge mig ett kort exempel på hur detta kan släppas i attributform? Som jag förstår det kan man ha flera organisationstillhörigheter samtidigt – kan vi då släppa ett multivärde? Och på tal om värde – vad skall detta värde vara? Org.namn i klartext så som det har lagts in i Survey – eller finns det ID:n någonstans?
Med vänlig hälsning,
/dempa
--
Dennis Sjögren
Systemutvecklare / Arkitekt
Avdelningen för IT och Digital Infrastruktur
Högskolan Dalarna
dempa(a)du.se<mailto:dempa@du.se> | www.du.se<http://www.du.se> | +46 23 778000
Hej!
I morse strax innan klockan 08.00 rullades det ut lite trasig metadata i SWAMID som orsakade problem för ADFSToolkit. Metadatan är fixad och kommer propageras ut strax.
--
jocar
SWAMID Operations
Hej och välkomna tillbaka efter sommaren!
Innehållet i detta brev gäller endast universitet och högskolor.
Nu är det dags att påminna alla lärosäten om ESI igen. Ungefär hälften av
alla identitetsutfärdare som har användare som försökt logga in till
MyAcademicID för Erasmus+ har ESI med sig från sin IdP. Kontrollera hur det
ser ut för just er IdP i bifogad fil och tänk på att har ni bytt IdP under
det senaste året finns både er nya och er gamla troligtvis med på listan.
Om den gamla finns med ignorera den och koncentrera er på den nya.
Det är nu bråttom att fixa ESI för era studenters räkning! På wikisidan How-To
- European Student Identifier (ESI) för European Digital Student Service
Infrastructure (EDSSI) - Sunet Wiki
<https://wiki.sunet.se/pages/viewpage.action?pageId=103514131> finns
information om hur man gör det inkl. tre olika förslag på varifrån man får
grunddata för att bygga ESI-värdet. De allra flesta lärosäten som är klara
har använt information från Ladok för att lösa det. På
https://release-check.swamid.se/#esi kan ni testa er IdP, tänk på att om ni
loggar in som anställd så kanske ni inte har något ESI-värde om ni bygger
det från Ladok.
Vi återkommer snart med en inbjudan till ett webinar favorit i repris där
vi går igenom ESI och hur man bygger det. Om ni inte redan har påbörjat
arbetet ska ni inte vänta på webinaret utan börja planera…
Pål
*From:* Pål Axelsson <pax(a)sunet.se>
*Sent:* Tuesday, March 1, 2022 11:55 AM
*To:* saml-admins(a)swamid.se
*Subject:* Påminnelse ESI
Hej,
I går fick jag statistik från Géant angående hur väl svenska lärosäten
stödjer European Student Identifier (ESI) oberoende om inloggning sker via
lärosätets IdP eller om lärosätet använder en utbytesstjänst från extern
leverantör.
För närvarande släpper endast 35% av svenska lärosäten ESI för sina
studenter till Erasmus+. Studenter på de övriga lärosätena kommer framöver
få problem när ESI blir obligatoriskt för alla.
Sunet och UHR kommer tillsammans genomföra ytterligare ett webinar där vi
repeterar ESI och entitetskategori för ESI nu under våren. Information
kommer senare!
Pål
Hej,
SWAMID Operations har utökats med en ny medarbetare som bland annat kommer
att ta hand om metadataärenden. Johan Wassberg har tidigare jobbat på
Stockholms universitet men är nu anställd på Sunet.
SWAMID Operations består nu av följande personer:
· Pål Axelsson, Sunet
· Björn Mattsson, Sunet
· Eskil Swahn, Lunds universitet
· Fredrik Domeij, Umeå universitet
· Johan Peterson, Linköpings universitet
· Johan Wassberg, Sunet
· Paul Scott, Karlstads universitet
· Tommy Larsson, Umeå universitet
Välkommen Johan!
Pål
För er som kör Shibboleth på Windows kan det vara värt att uppgradera.
Har rapporterats en del om att CPU:n går i taket med nya 4.2.1på Windows och de hittade en bug i Jetty som de nu åtgärdat i MSI paketet.
"This is a service release of the Windows installation package which addresses a Jetty logging issue and updates Jetty to 10.0.11 to address a memory leak.”
Dvs ni som kör på Linux kan sitta lugnt i båten.
Björn Mattsson
bjorn(a)sunet.se <mailto:bjorn@sunet.se>
> Begin forwarded message:
>
> From: "Cantor, Scott via announce" <announce(a)shibboleth.net <mailto:announce@shibboleth.net>>
> Subject: Shibboleth Identity Provider 4.2.1.1 Windows service update
> Date: 6 July 2022 at 15:00:15 CEST
> To: "announce(a)shibboleth.net <mailto:announce@shibboleth.net>" <announce(a)shibboleth.net <mailto:announce@shibboleth.net>>
> Cc: "Cantor, Scott" <cantor.2(a)osu.edu <mailto:cantor.2@osu.edu>>
> Reply-To: users(a)shibboleth.net <mailto:users@shibboleth.net>
>
> The Windows installer for IdP V4.2.1 has been updated to fix a logging bug and update Jetty to address a memory leak.
>
> Available from the usual location [1]
>
> -- Scott
>
> [1] http://shibboleth.net/downloads/identity-provider/latest/ <http://shibboleth.net/downloads/identity-provider/latest/>
>
> --
> To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net <mailto:announce-unsubscribe@shibboleth.net>
Hej och välkomna tillbaka från semestern.
Jag vill bara påminna om vikten att ni ser till så att ni kan släppa ESI
för era studenter under hösten. ESI är en väldigt viktig
infrastrukturdel för Erasmus+. Inom några få veckor kommer jag med mer
information om hur ni ska släppa ESI från era identitetsutfärdare.
Mer information om hur man skapar ESI finns på wikisidan How-To -
European Student Identifier (ESI) för European Digital Student Service
Infrastructure (EDSSI)
(https://wiki.sunet.se/pages/viewpage.action?pageId=103514131)
<https://wiki.sunet.se/pages/viewpage.action?pageId=103514131>
Pål
------ Originalmeddelande ------
Från: "Pål Axelsson" <pax(a)sunet.se>
Till: "Swamid saml-admins" <saml-admins(a)swamid.se>
Kopia: "Fresia Pérez Arriagada" <fresia(a)sunet.se>; "Leif Johansson"
<leifj(a)sunet.se>; "Mauritz Danielsson" <mauritz.danielsson(a)ladok.se>;
"Marilyn Klarin Cars" <Marilyn.Klarin.Cars(a)uhr.se>
Skickat: 2021-06-23 15:21:10
Ämne: Re: Angående ESI och vilka värden man skickar
>Hej,
>
>Efter en fråga idag från ett lärosäte så vill jag förtydliga
>informationen i detta brev.
>
>Informationen nedan gäller endast när man släpper ESI från lärosätets
>IdP, inte när ESI skickas via nätverket för Erasmus Without Papers
>(EWP).
>
>Pål
>
>------ Originalmeddelande ------
>Från: "Pål Axelsson" <pax(a)sunet.se>
>Till: "Swamid saml-admins" <saml-admins(a)swamid.se>
>Kopia: "Fresia Pérez Arriagada" <fresia(a)sunet.se>; "Leif Johansson"
><leifj(a)sunet.se>; "Mauritz Danielsson" <mauritz.danielsson(a)ladok.se>;
>"Marilyn Klarin Cars" <Marilyn.Klarin.Cars(a)uhr.se>
>Skickat: 2021-06-07 12:12:19
>Ämne: Angående ESI och vilka värden man skickar
>
>>Hej,
>>
>>På webinaret i fredags kom det upp frågor runt vilka ESI en IdP ska
>>skicka när de ska skicka ESI. Jag har nu under förmiddagen idag
>>diskuterat det med de som ansvarar för ESI samt representanter för
>>andra länder som jobbar med integrationerna.
>>
>>Först några extremt viktiga observationer under diskussionen innan
>>svaret på frågan.
>>
>>Ett ESI måste alltid vara
>>unikt och aldrig tilldelas någon annan individ
>>långsiktigt tillgängligt i studiedokumentationssystemet (eller
>>kringsystem till detta beroende på studieuppgifter knutna till det)
>>tillgängligt både för identitetshanteringsystemet och
>>studiedokumentationssystemet (eller kringsystem till detta beroende på
>>studieuppgifter knutna till det)
>>Nu till själva frågan: Ett lärosäte får aldrig skicka vidare ett ESI
>>de fått från hemmalärosätet för inresande student. Orsaken till detta
>>är att ni som lärosäte kan inte garantera fortsatt användning på
>>hemmalärosätet efter att nuvarande utbyte har slutförts.
>>
>>Till sist, kan man skicka multipla ESI för en person? Svaret är nej!
>>Även fast själva attributet schacPersonalUniqueCode är multivärt är
>>inte ESI-värdet det.
>>
>>Så sammanfattningsvis: ESI som skickas av IdP måste vara av den modell
>>som du skickar för alla dina studenter och du ska inte skicka flera
>>olika värden för samma student.
>>
>>Pål
>>
---------------------------------------------------------------
saml-admins-at-swamid.se mailing list
Medlemskap/Arkiv etc finns p�:
http://segate.sunet.se/cgi-bin/wa?A0=saml-admins
---------------------------------------------------------------
Hej,
Jag anser att du uppfattat det korrekt. Vi har uppmärksammat det till
och från.
Pål
------ Originalmeddelande ------
Från: "Klas Mattsson" <klas.mattsson(a)su.se>
Till: saml-admins(a)swamid.se
Skickat: 2021-08-18 09:25:15
Ämne: [SAML-ADMINS] Lustigheter med Géant CoCo
>Hej!
>
>Med ett par tjänster i SWAMID (senast inspera) har jag sett att man med
>Géant CoCo lite grann missförstår hur SWAMID använder :
>
>RequestedAttribute Name
>
>Och mer specifikt:
>
>isRequired="(true|false)"
>
>På ett lite felaktigt sätt.
>
>Om jag inte missuppfattar siutationen så är isRequired="false"
>egentligen aldrig användbar för entitetskategorisyfte och borde således
>inte användas om automatiken ska fungera som det är tänkt.
>
>Missar jag någon aspekt med detta?
>
>
>Om isRequired=false är helt oanvändbart, är det då möjligt att lite
>noggrannare okulär besiktning sker?
>
>/mvh
>
>
>
>
>--
>________________________________
>Klas Mattsson
>
>Teknikspecialist Linfra, Infrastruktursektionen
>
>IT-avdelningen
>Stockholms universitet
>106 91 Stockholm
>Tel: 08-16 39 00
>www.su.se/ithttps://www.su.se/om-webbplats-cookies/personuppgifter
---------------------------------------------------------------
saml-admins-at-swamid.se mailing list
Medlemskap/Arkiv etc finns p�:
http://segate.sunet.se/cgi-bin/wa?A0=saml-admins
---------------------------------------------------------------
---------------------------------------------------------------
saml-admins-at-swamid.se mailing list
Medlemskap/Arkiv etc finns p�:
http://segate.sunet.se/cgi-bin/wa?A0=saml-admins
---------------------------------------------------------------
Hej!
Med ett par tjänster i SWAMID (senast inspera) har jag sett att man med
Géant CoCo lite grann missförstår hur SWAMID använder :
RequestedAttribute Name
Och mer specifikt:
isRequired="(true|false)"
På ett lite felaktigt sätt.
Om jag inte missuppfattar siutationen så är isRequired="false"
egentligen aldrig användbar för entitetskategorisyfte och borde således
inte användas om automatiken ska fungera som det är tänkt.
Missar jag någon aspekt med detta?
Om isRequired=false är helt oanvändbart, är det då möjligt att lite
noggrannare okulär besiktning sker?
/mvh
--
________________________________
Klas Mattsson
Teknikspecialist Linfra, Infrastruktursektionen
IT-avdelningen
Stockholms universitet
106 91 Stockholm
Tel: 08-16 39 00
www.su.se/ithttps://www.su.se/om-webbplats-cookies/personuppgifter
---------------------------------------------------------------
saml-admins-at-swamid.se mailing list
Medlemskap/Arkiv etc finns p�:
http://segate.sunet.se/cgi-bin/wa?A0=saml-admins
---------------------------------------------------------------
Jag har väntat ditt svar när det gäller mitt tidigare mejl till dig.
---------------------------------------------------------------
saml-admins-at-swamid.se mailing list
Medlemskap/Arkiv etc finns på:
http://segate.sunet.se/cgi-bin/wa?A0=saml-admins
---------------------------------------------------------------
