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
