Thank you for your reply.
I have the OIDs delivered by the IDP which are the following:
urn:oid:1.3.6.1.4.1.5923.1.1.1.6
urn:oid:2.5.4.42
urn:oid:2.5.4.4
urn:oid:0.9.2342.19200300.100.1.3
urn:oid:2.16.840.1.113730.3.1.241
So this is what I put into attribute-map.xml:
<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="SHIB-NETID"/>
<Attribute name="urn:oid:2.5.4.42" id="SHIB-GIVENNAME"/>
<Attribute name="urn:oid:2.5.4.4" id="SHIB-SURNAME"/>
<Attribute name="urn:oid:0.9.2342.19200300.100.1.3" id="SHIB-MAIL"/>
<Attribute name="urn:oid:2.16.840.1.113730.3.1.241" id="displayName"/>
And this is on the other side in [dspace-backend]/config/modules/authentication-shibboleth.cfg:
authentication-shibboleth.netid-header = SHIB-NETID
authentication-shibboleth.email-header = SHIB-MAIL
(...)
authentication-shibboleth.firstname-header = SHIB-GIVENNAME
authentication-shibboleth.lastname-header = SHIB-SURNAME
If I have the attributePrefix="_AJP" in shibboleth2.xml, nothing at all arrives at DSpace from the login attempt. (403)
If I delete it, at least there is a 401 "authentication failed" and dspace.log throws the error mentioned above.
I added
'allowedRequestAttributesPattern='SHIB-.*'
to the AJP connector in tomcat9/conf/server.xml
The inherited result is still the same. To make matters worse, now this morning after these minimal changes in the Shib XML files and in server.xml, for some reason the following came up when I tried to reload the page:
Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.4.38 (Debian) Server at ... Port 443
After resetting to the state before these changes the service runs normally again (still without Shibboleth of course).Is it possible that it is somehow due to the module? I don't know exactly, because our DSpace was originally installed by an external company, but I guess that at the moment only mod_proxy is used for the communication between Apache and Tomcat.
Kind regards,
Matthias