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
