Hej!
Vi fick idag ett abuse-ärende från Elsevier (EntityID https://sdauth.sciencedirect.com/ ) där de skriver
"To address future compromises the EduPersonTargetedID or it’s replacement pairwise-id id should be made available to Elsevier; so we can provide this value for identifying the compromised End User Account."
I SWAMIDs metadata verkar de inte ha någon kategori som gör att vi släpper något till dem.
Om jag lägger en egen release till deras entityID är jag lite orolig att de senare får en kategori som släpper subject-id till dem, vilket då innebär att de får bägge, vilket inte är ok.
Har någon annan gjort någon manuell release till dem och i så fall hur?
Mvh Tobias Galéus
Göteborgs universitet
Hej,
ger nu upp, är det någon annan som fått detta felet när dom uppgraderat till java17 (corretto jdk), jetty11 och idp5?
Den klagar på alla filer i idp.war filen. Har bara en installerad version av java och jag förstår inte hur jetty kan klaga på att den är kompilerad under javac 17 och sen inte kan köra den under java 17.
Suppressed: java.lang.RuntimeException: Error scanning entry org/springframework/web/util/pattern/package-info.class from jar file:///opt/jetty-base/tmp/jetty-0_0_0_0-8080-idp_war-_idp-any-11138712393958766714/webinf/WEB-INF/lib/spring-web-6.1.6.jar
at org.eclipse.jetty.annotations.AnnotationParser.lambda$parseJar$2(AnnotationParser.java:844)
at java.base/java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:3215)
at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
at org.eclipse.jetty.annotations.AnnotationParser.parseJar(AnnotationParser.java:836)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:737)
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:172)
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:553)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:894)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1038)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 61
---------- Forwarded message ---------
Från: desislava.georgieva(a)agilent.com <desislava.georgieva(a)agilent.com>
Date: mån 17 juni 2024 13:18
Subject: Resolved: Login issues for Federated EU institutions
To:
Hello!
Happy to announce that the issue with iLab logins should now be resolved
for all affected institutions in Europe.
If you have questions or continue to face issues, please do not hesitate to
email iLab-support(a)agilent.com for help.
Thank you again for your patience and support!
Best,
Des
*Desislava Georgieva*
Customer Success Manager, EMEAI
Agilent CrossLab Group | Agilent Technologies, Inc.
www.agilent.com/crosslab
*Planned Out of Office: Friday, June 28th *
<https://www.agilent.com/cs/promotions/images/20181206-crosslab-insight-emai…>
För kännedom!
Pål
------ Vidarebefordrat meddelande ------
Från "desislava.georgieva(a)agilent.com" <desislava.georgieva(a)agilent.com>
Till
Datum 2024-06-17 10:33:58
Ämne iLab Urgent Communication: Login issues for Federated EU
institutions
Hello!
As you may be aware, there are currently issues with the iLab
SWAMID/HAKA logins for our users.
This issue is being investigated with high priority and we will keep you
updated on progress.
In the meantime, internal users can login intermittently using iLab
credentials, so their urgent work is not halted. Please feel free to
email iLab Support at iLab-support(a)agilent.com with a list of users
that need urgent access, and our team will assist with sending welcome
emails to them. You may also want to communicate this to individual
users internally as well.
Thank you for your patience as we work through this issue!
Best,
Des
Desislava Georgieva
Customer Success Manager, EMEAI
Agilent CrossLab Group | Agilent Technologies, Inc.
www.agilent.com/crosslab
<https://www.agilent.com/cs/promotions/images/20181206-crosslab-insight-emai…>
Hej
Vi har fått en fråga om inloggning till https://ieeexplore.ieee.org/Xplore Vi har någon variant av anonym inloggning idag, de vet att jag kommer från RISE men inte på individ nivå. Jag gissar via vår publika IP adress eller likande.
De har "Institutional Sign In" knapp längst upp om jag surfar från dator ej ansluten till RISE nät. Om jag klickar på "Institutional signs in" får man välja att söka efter institut men där finns vi inte. Dvs det verkar inte fungera med SWAMID. De hänvisar till https://SeamlessAccess.org<https://seamlessaccess.org/> där jag kan läsa "hosted by SUNET". Tänker att det borde vara "lätt"
Är det någon som vet hur det går till att få inloggning till IEEE??
Anders Persson
Systemarkitekt
Digital utveckling och IT
IT
Utvecklingsstöd
D: +46 10 516 5448 | V: +46 10 516 50 00
anders.persson(a)ri.se<mailto:anders.persson@ri.se>
RISE Research Institutes of Sweden | ri.se<http://www.ri.se/>
Brinellgatan 4 | Box 857, SE-501 15 Borås
För info om hur vi hanterar dina personuppgifter
besök ri.se/personuppgifter
Nedan följer information som gått ut till Lokala kontaktpersoner för Ladok vid lärosätena. Detta kan vara bra för er andra att veta också!
Sammanfattning
Ladokkonsortiet planerar för att byta användaridentifierare i Ladok. Detta innebär att vissa lärosäten behöver göra anpassningar i sin inloggningstjänst (IdP) i SWAMID. För att tidsplanen för bytet ska vara genomförbar behöver anpassningarna vara slutförda senast 2024-11-30.
Bakgrund
Ladokkonsortiet arbetar med att införa kontokoppling i Ladok för studenter. Kontokoppling innebär att studenter ska ges möjlighet att koppla andra inloggningar än inloggningen från sitt svenska lärosäte till Ladok. Detta behov finns särskilt för internationella studenter som efter sina studier inte har kvar sin lärosätesinloggning i Ladok och inte heller är svenska medborgare. Därmed kan de inte logga in via svensk e-legitimation eller skapa ett eduID-konto bekräftat med ett svenskt personnummer. Planerade inloggningsmetoder för kontokoppling är:
* eIDAS, europeisk e-legitimation
* European Student Identifier (ESI), som är tillgänglig från lärosäten inom Europa som stödjer Erasmus Without Papers (EWP)
* subject-id, vilket är en användaridentifierare hos många andra lärosäten i Europa och i övriga världen
* eduID-konton utan svenskt personnummer men bekräftade via pass/nationellt id-kort
För att möjliggöra kontokoppling behöver den användaridentifierare som används i Ladok idag, ePPN (eduPersonPrincipalName), bytas ut. ePPN har använts inom identitetsfederationen SWAMID i många år och i SWAMID finns krav på att den identifieraren aldrig någonsin får återanvändas för en annan person. Detta krav gäller dock inte internationellt för ePPN, vilket innebär att användaridentifieraren för person A tillåts återanvändas för person B vid lärosätet. Därmed får person B tillgång till person A:s uppgifter och behörigheter i system som inte är medvetna om återanvändandet. För att lösa det detta har en ny användaridentifierare skapats, subject-id<https://wiki.sunet.se/display/SWAMID/subject-id+-+SAML2+General+Purpose+Sub…>, som redan från början har detta krav. Utöver det finns en ny "entitetskategori" för att standardisera överföring av subject-id inom SWAMID och eduGAIN, REFEDS Personalized Access Entity Category<https://wiki.sunet.se/display/SWAMID/4.1+Entity+Categories+for+Service+Prov…>.
Byte till subject-id som identifierare i Ladok minimerar också risken att personal som loggar in i Ladok för personal från ett lärosäte utanför Sverige har fått en användaridentifierare som är återanvänd.
Påverkade lärosäten
Dessa lärosäten uppfyller idag inte Ladoks krav på subject-id som användaridentifierare och har ett arbete att göra för att uppfylla dessa:
*
Enskilda Högskolan Stockholm
*
Försvarshögskolan
*
Gymnastik- och idrottshögskolan
*
Kungl. Konsthögskolan
*
Kungl. Musikhögskolan i Stockholm
*
Marie Cederschiöld högskola
*
Röda Korsets högskola
*
Sophiahemmet Högskola
*
Stockholms konstnärliga högskola
*
Sveriges lantbruksuniversitet
Dessa lärosäten uppfyller idag Ladoks krav men kan behöva anpassa eventuella integrationer mot Ladok inför byte av användaridentifierare:
* Karlstads universitet
* Lunds universitet
* Malmö Universitet
Tidsplan
Förhoppningen är att kunna leverera funktionalitet för kontokoppling under december 2024, vilket skulle möjliggöra för internationella studenter som lämnar sitt svenska lärosäte efter årsskiftet att utföra kontokoppling innan de lämnar. För att kunna införa kontokopplingen i Ladok för studenter måste samtliga lärosäten ha implementerat entitetskategorin Personalized senast 2024-11-30.
För mer information om status kring Personalized för respektive lärosäte, se Byte till subject-id<https://confluence.its.umu.se/confluence/display/ITL/Byte+till+subject-id> (kräver inloggning till Ladoks dokumentation, prata med er lokala kontaktperson för Ladok).
MVH
Fredrik Domeij, Ladoksupporten
----------------------------------
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!
Idag har vi haft vårt sista möte (för tillfället) där vi diskuterade
uppgraderingsarbetet till Shibboleth IdP v5. Vi har haft många
intressanta diskussioner under de senaste veckorna!
Under semesterperioden kan ni använda denna lista för att ställa frågor
eller dela information som ni tror att andra kan dra nytta av.
Vi kommer att återuppta mötena i augusti. Mer information om detta
kommer närmare tiden.
Vänliga hälsningar,
Paul.
SWAMID operations.
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>.
Hej,
Som flera av er tidigare hört är nu tjänsten e-legitimation som tjänst
tillgänglig för alla som är anslutna till Sunet. På Sunets wiki finns
information om tjänsten,
https://wiki.sunet.se/display/eLegitimationSomTjanst.
I månadsbrevet som i slutet på maj gick ut till de officiella
kontaktpersonerna för lärosätena och andra anslutna organisationer stod
följande.
"E-legitimation som tjänst
Nu kan Sunets anslutna organisationer använda Svensk e-legitimation mot
sina tjänster genom Sunets nya tjänst E-legitimation som tjänst.
Organisationer som är anslutna till Sunet kan beställa E-legitimation
som tjänst. Man behöver också ha ett avtal med en utfärdare av
e-legitimation. För frågor om avtal och uppstart kontakta
tjänsteförvaltare zacharias(a)sunet.se. Läs mer om tjänsten under
Tjänster/Identifiering på sunet.se. Mer detaljerad information om
tjänsten finns på wiki.sunet.se.
Vi välkomnar två lärosäten som nu börjat använda BankID som IdP genom
Sunet.
Har ni frågor, kontakta Zacharias Törnblom, zacharias(a)sunet.se."
Pål
Som uppföljning på min fråga idag på Zoom där jag fick följande fel i loggen
2024-05-23 20:21:16,133 - WARN [org.ldaptive.auth.Authenticator:509] - Entry resolution failed for resolver=[org.ldaptive.auth.SearchEntryResolver@464538039::factory=null, baseDn=, userFilter=null, userFilterParameters=null, allowMultipleEntries=false, subtreeSearch=false, derefAliases=NEVER, binaryAttributes=null, entryHandlers=null]|10.244.175.89|
org.ldaptive.LdapException: Error resolving entry for xgalto(a)gu.gu.se. Unsuccessful search response: org.ldaptive.SearchResponse@-924623128::messageID=2, controls=[], resultCode=INVALID_DN_SYNTAX, matchedDN=, diagnosticMessage=0000208F: NameErr: DSID-03100231, problem 2006 (BAD_NAME), data 8350, best match of:
'xgalto(a)gu.gu.se'
^@, referralURLs=[], entries=[], references=[]
at org.ldaptive.auth.AbstractSearchEntryResolver.resolve(AbstractSearchEntryResolver.java:297)
Vi har haft följande inställning
idp.authn.LDAP.authenticator= adAuthenticator
Och om man läser på https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505688/LDAPAuth…
"Configuration that leverages the AD specific @domain.com format. No DN search is performed since AD supports binding directly with that user name."
Vilket jag tycker borde funkat då vår domän är @gu.gu.se. Men jag ändrade inställningen till
idp.authn.LDAP.authenticator= bindSearchAuthenticator
Och hade idp.authn.LDAP.bindDN och idp.authn.LDAP.bindDNCredential konfigurerade sedan tidigare med ett servicekonto och nu är varningen borta!
Tack för hjälp med felsökningen!
Mvh Tobias
