Re: [dspace-tech] dspace not picking up Shibboleth attributes to authenticate

[David Williams]

Hi, Julie -

I'm experiencing the exact same issue, using DSpace 6.3.

What specifically did you change in the httpd.conf to stop the redirection 
following the handoff back to Apache from the IdP?

Thanks in advance for your assistance,

- Dave

On Thursday, February 23, 2017 at 8:22:35 PM UTC-5 jbel...@gmail.com wrote:

>
> I have shibboleth now working.  Adding this line 
>  "log4j.logger.org.dspace.authenticate.ShibAuthentication=DEBUG” was the 
> biggest help.  Maybe should be more prominent in the documentation :)  
>
> Your testing suggestions found the problem in our httpd.conf which forced 
> a redirect to the /dspace directory after it came back from the IdP.  Still 
> have the double slashes  in the string.  That is actually created here 
> (probably another configuration issue further up the line)  - using the 
> Login function from the main page and not by any redirect or addition by 
> apache:
>
> 2017-02-23 15:48:48,738 DEBUG org.dspace.authenticate.ShibAuthentication @ 
> Redirecting user to Shibboleth initiator: 
> /Shibboleth.sso/Login?target=https%3A%2F%2Ftest-dspace.ksulib.net
> %2F%2Fdspace%2Fshibboleth-login
>
> Couple of notes here though…with things working:
>
> 1.  I was never able to get /shibboleth-login to the IdP with out tomcat 
> running.
> 2.  This change created errors in Apache preventing start:
>
> configtest = ShibRequireSession must be On or Off, so I went back to the 
> On | Off
>
>
>
>
>- Replace "ShibRequireSession On" by "ShibRequestSetting 
>requireSession 1"
>
>
>- Replace "ShibRequireSession Off" by "ShibRequestSetting 
>requireSession 0”
>
> I do have one other question.  Is there any way to set all users to a 
> specific group after login rather than Anonymous?  In LDAP we were able to 
> set the default group as such:
>
> login.specialgroup = ETDR_AUTO
>
> I was thinking worse case -  use the affiliation and set all the roles to 
> the group.  I was looking at the scripting functions and could go that way 
> later. 
>
> Thank you again!
>
> On Feb 22, 2017, at 2:57 PM, Tom Desair  wrote:
>
> Can you enable debug logging for Shibboleth in DSpace by adding this line 
> "log4j.logger.org.dspace.authenticate.ShibAuthentication=DEBUG" to 
> the config/log4j.properties file and retry with the following settings:
>
>- Use AJP
>   - Make sure to have attributePrefix="AJP_" in your 
>   ApplicationDefaults element
>   - Make sure to proxy to the AJP connector with a buffer that is 
>   large enough:
>  - We always use
> - ProxyPass / ajp://localhost:8009/ retry=0
> - ProxyPassReverse / ajp://localhost:8009/
> - ProxyIOBufferSize 65536
> - Make sure the connector is enabled in the Tomcat server.xml 
>  file and supports UTF-8 encoding and large packages:
> -  redirectPort="8443" URIEncoding="UTF-8" packetSize="65536"/>
> - Secure the correct location
>   - If you run DSpace under the root of your server, make sure this is
>  - 
>  - If you run DSpace under the the URL "/dspace", the location 
>   should be
>  - 
>  - Make sure there are no double slashes in the redirect URL your 
>   browser receives (which is the case in your first example).
>- Since you are using Apache 2.4 and Shibboleth 2.5, please replace 
>the following in your Apache configuration:
>   - Replace "ShibRequireSession On" by "ShibRequestSetting 
>   requireSession 1"
>   - Replace "ShibRequireSession Off" by "ShibRequestSetting 
>   requireSession 0"
>- You can leave the values for lazysession.secure and the DSpace netid 
>and email header settings as you configured them.
>
> Can you also test this:
>
>- Shutdown tomcat and visit /shibboleth-login after 
>closing all browser windows. This should take you to your IdP login page 
>even if DSpace is not running.
>- Have you tried without AJP and using "ShibUseHeaders On" (note that 
>this is less secure and not recommended, but it would still be interesting 
>to know if this works).
>
> I'm interested to see what the DSpace logs show when you execute these 
> tests. Please also provide some information on the redirect URLs you are 
> seeing.
>
>  
> [image: logo] Tom Desair
> 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
> Esperantolaan 4, Heverlee 3001, Belgium
> www.atmire.com 
> 
>
> 2017-02-22 16:24 GMT+01:00 Jbell KSU Gmail :
>
>>
>> Thank you for the reply - but that did not solve the problem.  I have the 
>> same response in all the logs as prior to the change.  
>>
>> I did try several variations on that theme but still have not hit the 
>> right combination yet.  Further information that I missed last night:
>>
>> Running dSpace 5.4
>>
>> # Whether to use lazy sessions or active sessions.
>> 

Re: [dspace-tech] dspace not picking up Shibboleth attributes to authenticate

[Jbell KSU Gmail]

I have shibboleth now working.  Adding this line  
"log4j.logger.org.dspace.authenticate.ShibAuthentication=DEBUG” was the biggest 
help.  Maybe should be more prominent in the documentation :)  

Your testing suggestions found the problem in our httpd.conf which forced a 
redirect to the /dspace directory after it came back from the IdP.  Still have 
the double slashes  in the string.  That is actually created here (probably 
another configuration issue further up the line)  - using the Login function 
from the main page and not by any redirect or addition by apache:

2017-02-23 15:48:48,738 DEBUG org.dspace.authenticate.ShibAuthentication @ 
Redirecting user to Shibboleth initiator: 
/Shibboleth.sso/Login?target=https%3A%2F%2Ftest-dspace.ksulib.net%2F%2Fdspace%2Fshibboleth-login

Couple of notes here though…with things working:

1.  I was never able to get /shibboleth-login to the IdP with out tomcat 
running.
2.  This change created errors in Apache preventing start:

configtest = ShibRequireSession must be On or Off, so I went back to the On | 
Off
> Replace "ShibRequireSession On" by "ShibRequestSetting requireSession 1"
> Replace "ShibRequireSession Off" by "ShibRequestSetting requireSession 0”
I do have one other question.  Is there any way to set all users to a specific 
group after login rather than Anonymous?  In LDAP we were able to set the 
default group as such:

login.specialgroup = ETDR_AUTO

I was thinking worse case -  use the affiliation and set all the roles to the 
group.  I was looking at the scripting functions and could go that way later. 

Thank you again!

> On Feb 22, 2017, at 2:57 PM, Tom Desair  wrote:
> 
> Can you enable debug logging for Shibboleth in DSpace by adding this line 
> "log4j.logger.org.dspace.authenticate.ShibAuthentication=DEBUG" to the 
> config/log4j.properties file and retry with the following settings:
> Use AJP
> Make sure to have attributePrefix="AJP_" in your ApplicationDefaults element
> Make sure to proxy to the AJP connector with a buffer that is large enough:
> We always use
> ProxyPass / ajp://localhost:8009/ retry=0
> ProxyPassReverse / ajp://localhost:8009/
> ProxyIOBufferSize 65536
> Make sure the connector is enabled in the Tomcat server.xml file and supports 
> UTF-8 encoding and large packages:
>  URIEncoding="UTF-8" packetSize="65536"/>
> Secure the correct location
> If you run DSpace under the root of your server, make sure this is
> 
> If you run DSpace under the the URL "/dspace", the location should be
> 
> Make sure there are no double slashes in the redirect URL your browser 
> receives (which is the case in your first example).
> Since you are using Apache 2.4 and Shibboleth 2.5, please replace the 
> following in your Apache configuration:
> Replace "ShibRequireSession On" by "ShibRequestSetting requireSession 1"
> Replace "ShibRequireSession Off" by "ShibRequestSetting requireSession 0"
> You can leave the values for lazysession.secure and the DSpace netid and 
> email header settings as you configured them.
> Can you also test this:
> Shutdown tomcat and visit /shibboleth-login after closing all 
> browser windows. This should take you to your IdP login page even if DSpace 
> is not running.
> Have you tried without AJP and using "ShibUseHeaders On" (note that this is 
> less secure and not recommended, but it would still be interesting to know if 
> this works).
> I'm interested to see what the DSpace logs show when you execute these tests. 
> Please also provide some information on the redirect URLs you are seeing.
> 
>  
>   Tom Desair
> 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
> Esperantolaan 4, Heverlee 3001, Belgium
> www.atmire.com 
> 
> 
> 2017-02-22 16:24 GMT+01:00 Jbell KSU Gmail  >:
> 
> Thank you for the reply - but that did not solve the problem.  I have the 
> same response in all the logs as prior to the change.  
> 
> I did try several variations on that theme but still have not hit the right 
> combination yet.  Further information that I missed last night:
> 
> Running dSpace 5.4
> 
> # Whether to use lazy sessions or active sessions.
> lazysession = true
> 
> Does this need to change?
> 
> # The url to start a shibboleth session (only for lazy sessions)
> lazysession.loginurl = /Shibboleth.sso/Login
> 
> # Force HTTPS when authenticating (only for lazy sessions)
> lazysession.secure = true
> 
> 
> and my question is this the correct netid-header for this configuration?  
> 
> #email-header = SHIB-MAIL
> netid-header = uid
> email-header = email
> email-use-tomcat-remote-user = false
> 
> 
> 
>> On Feb 22, 2017, at 2:16 AM, Tom Desair > > wrote:
>> 
>> Hi Julie,
>> 
>> The key here is the Apache configuration section
>>  
>>  AuthType shibboleth
>>  ShibRequireSession On
>>  Require valid-user
>> 
>> 
>> This 

Re: [dspace-tech] dspace not picking up Shibboleth attributes to authenticate

[Jbell KSU Gmail]

Great - some testing I have not done - I will let you know in the morning.  
Again, thank you!


> On Feb 22, 2017, at 2:57 PM, Tom Desair  wrote:
> 
> Can you enable debug logging for Shibboleth in DSpace by adding this line 
> "log4j.logger.org.dspace.authenticate.ShibAuthentication=DEBUG" to the 
> config/log4j.properties file and retry with the following settings:
> Use AJP
> Make sure to have attributePrefix="AJP_" in your ApplicationDefaults element
> Make sure to proxy to the AJP connector with a buffer that is large enough:
> We always use
> ProxyPass / ajp://localhost:8009/ retry=0
> ProxyPassReverse / ajp://localhost:8009/
> ProxyIOBufferSize 65536
> Make sure the connector is enabled in the Tomcat server.xml file and supports 
> UTF-8 encoding and large packages:
>  URIEncoding="UTF-8" packetSize="65536"/>
> Secure the correct location
> If you run DSpace under the root of your server, make sure this is
> 
> If you run DSpace under the the URL "/dspace", the location should be
> 
> Make sure there are no double slashes in the redirect URL your browser 
> receives (which is the case in your first example).
> Since you are using Apache 2.4 and Shibboleth 2.5, please replace the 
> following in your Apache configuration:
> Replace "ShibRequireSession On" by "ShibRequestSetting requireSession 1"
> Replace "ShibRequireSession Off" by "ShibRequestSetting requireSession 0"
> You can leave the values for lazysession.secure and the DSpace netid and 
> email header settings as you configured them.
> Can you also test this:
> Shutdown tomcat and visit /shibboleth-login after closing all 
> browser windows. This should take you to your IdP login page even if DSpace 
> is not running.
> Have you tried without AJP and using "ShibUseHeaders On" (note that this is 
> less secure and not recommended, but it would still be interesting to know if 
> this works).
> I'm interested to see what the DSpace logs show when you execute these tests. 
> Please also provide some information on the redirect URLs you are seeing.
> 
>  
>   Tom Desair
> 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
> Esperantolaan 4, Heverlee 3001, Belgium
> www.atmire.com 
> 
> 
> 2017-02-22 16:24 GMT+01:00 Jbell KSU Gmail  >:
> 
> Thank you for the reply - but that did not solve the problem.  I have the 
> same response in all the logs as prior to the change.  
> 
> I did try several variations on that theme but still have not hit the right 
> combination yet.  Further information that I missed last night:
> 
> Running dSpace 5.4
> 
> # Whether to use lazy sessions or active sessions.
> lazysession = true
> 
> Does this need to change?
> 
> # The url to start a shibboleth session (only for lazy sessions)
> lazysession.loginurl = /Shibboleth.sso/Login
> 
> # Force HTTPS when authenticating (only for lazy sessions)
> lazysession.secure = true
> 
> 
> and my question is this the correct netid-header for this configuration?  
> 
> #email-header = SHIB-MAIL
> netid-header = uid
> email-header = email
> email-use-tomcat-remote-user = false
> 
> 
> 
>> On Feb 22, 2017, at 2:16 AM, Tom Desair > > wrote:
>> 
>> Hi Julie,
>> 
>> The key here is the Apache configuration section
>>  
>>  AuthType shibboleth
>>  ShibRequireSession On
>>  Require valid-user
>> 
>> 
>> This tells the Apache Shibboleth daemon to require a Shibboleth session when 
>> visiting "/shibboleth-login" and to provide all mapped attributes to the 
>> Tomcat application server. For all other URL endpoints, Shibboleth will not 
>> forward the attributes.
>> 
>> However, your DSpace instance is not running under root but under "/dspace". 
>> I conclude this from the fact that you receive a redirect to 
>> "https://test-dspace.xxx.net//dspace/shibboleth-login 
>> ". This means you have 
>> to adjust the Apache configuration to secure that location instead. 
>> 
>> So your problem should be solved when you change "> "/shibboleth-login">" to "". Can you 
>> please try that and let me know if that works?
>> 
>> Best regards,
>> Tom
>>  
>>  Tom Desair
>> 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
>> Esperantolaan 4, Heverlee 3001, Belgium
>> www.atmire.com 
>> 
>> 
>> 2017-02-21 23:51 GMT+01:00 J Bell > >:
>> 
>> We are moving to Shibboleth and I am having a problem figuring out where my 
>> configuration is not set correctly to allow the actual authentication to 
>> occur.  This is working in other instances we have running - only dSpace  is 
>> not yet configured properly.   Would anyone have some input as to where I 
>> have wandered into the weeds?
>> 
>> Notes about our configuratio

Re: [dspace-tech] dspace not picking up Shibboleth attributes to authenticate

[Tom Desair]

Can you enable debug logging for Shibboleth in DSpace by adding this line
"log4j.logger.org.dspace.authenticate.ShibAuthentication=DEBUG" to
the config/log4j.properties file and retry with the following settings:

   - Use AJP
  - Make sure to have attributePrefix="AJP_" in your
  ApplicationDefaults element
  - Make sure to proxy to the AJP connector with a buffer that is large
  enough:
 - We always use
- ProxyPass / ajp://localhost:8009/ retry=0
- ProxyPassReverse / ajp://localhost:8009/
- ProxyIOBufferSize 65536
- Make sure the connector is enabled in the Tomcat server.xml
 file and supports UTF-8 encoding and large packages:
- 
- Secure the correct location
  - If you run DSpace under the root of your server, make sure this is
 - 
 - If you run DSpace under the the URL "/dspace", the location
  should be
 - 
 - Make sure there are no double slashes in the redirect URL your
  browser receives (which is the case in your first example).
   - Since you are using Apache 2.4 and Shibboleth 2.5, please replace the
   following in your Apache configuration:
  - Replace "ShibRequireSession On" by "ShibRequestSetting
  requireSession 1"
  - Replace "ShibRequireSession Off" by "ShibRequestSetting
  requireSession 0"
   - You can leave the values for lazysession.secure and the DSpace netid
   and email header settings as you configured them.

Can you also test this:

   - Shutdown tomcat and visit /shibboleth-login after closing
   all browser windows. This should take you to your IdP login page even if
   DSpace is not running.
   - Have you tried without AJP and using "ShibUseHeaders On" (note that
   this is less secure and not recommended, but it would still be interesting
   to know if this works).

I'm interested to see what the DSpace logs show when you execute these
tests. Please also provide some information on the redirect URLs you are
seeing.


[image: logo] Tom Desair
250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
Esperantolaan 4, Heverlee 3001, Belgium
www.atmire.com


2017-02-22 16:24 GMT+01:00 Jbell KSU Gmail :

>
> Thank you for the reply - but that did not solve the problem.  I have the
> same response in all the logs as prior to the change.
>
> I did try several variations on that theme but still have not hit the
> right combination yet.  Further information that I missed last night:
>
> Running dSpace 5.4
>
> # Whether to use lazy sessions or active sessions.
> lazysession = true
>
> *Does this need to change?*
>
> # The url to start a shibboleth session (only for lazy sessions)
> lazysession.loginurl = /Shibboleth.sso/Login
>
> # Force HTTPS when authenticating (only for lazy sessions)
> lazysession.secure = true
>
>
> and my question is this the correct netid-header for this configuration?
>
> #email-header = SHIB-MAIL
> netid-header = uid
> email-header = email
> email-use-tomcat-remote-user = false
>
>
>
> On Feb 22, 2017, at 2:16 AM, Tom Desair  wrote:
>
> Hi Julie,
>
> The key here is the Apache configuration section
>
>> 
>>  AuthType shibboleth
>>  ShibRequireSession On
>>  Require valid-user
>> 
>
>
> This tells the Apache Shibboleth daemon to require a Shibboleth session
> when visiting "/shibboleth-login" and to provide all mapped attributes to
> the Tomcat application server. For all other URL endpoints, Shibboleth will
> not forward the attributes.
>
> However, your DSpace instance is not running under root but under
> "/dspace". I conclude this from the fact that you receive a redirect to "
> https://test-dspace.xxx.net//dspace/shibboleth-login";. This means you
> have to adjust the Apache configuration to secure that location instead.
>
> So your problem should be solved when you change " "/shibboleth-login">" to "". Can
> you please try that and let me know if that works?
>
> Best regards,
> Tom
>
> [image: logo] Tom Desair
> 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
> Esperantolaan 4, Heverlee 3001, Belgium
> www.atmire.com
> 
>
> 2017-02-21 23:51 GMT+01:00 J Bell :
>
>>
>> We are moving to Shibboleth and I am having a problem figuring out where
>> my configuration is not set correctly to allow the actual authentication to
>> occur.  This is working in other instances we have running - only dSpace
>>  is not yet configured properly.   Would anyone have some input as to where
>> I have wandered into the weeds?
>>
>> Notes about our configuration:
>>
>> I have the IDP and my local *SP  (shibboleth 2.5.2)  * configured and
>> talking as I would expect.
>>
>> We are using *mod_ajp*  for the proxy  (this did not work under regular
>> proxy either - I have tried bo

Re: [dspace-tech] dspace not picking up Shibboleth attributes to authenticate

[Jbell KSU Gmail]

Thank you for the reply - but that did not solve the problem.  I have the same 
response in all the logs as prior to the change.  

I did try several variations on that theme but still have not hit the right 
combination yet.  Further information that I missed last night:

Running dSpace 5.4

# Whether to use lazy sessions or active sessions.
lazysession = true

Does this need to change?

# The url to start a shibboleth session (only for lazy sessions)
lazysession.loginurl = /Shibboleth.sso/Login

# Force HTTPS when authenticating (only for lazy sessions)
lazysession.secure = true


and my question is this the correct netid-header for this configuration?  

#email-header = SHIB-MAIL
netid-header = uid
email-header = email
email-use-tomcat-remote-user = false



> On Feb 22, 2017, at 2:16 AM, Tom Desair  wrote:
> 
> Hi Julie,
> 
> The key here is the Apache configuration section
>  
>  AuthType shibboleth
>  ShibRequireSession On
>  Require valid-user
> 
> 
> This tells the Apache Shibboleth daemon to require a Shibboleth session when 
> visiting "/shibboleth-login" and to provide all mapped attributes to the 
> Tomcat application server. For all other URL endpoints, Shibboleth will not 
> forward the attributes.
> 
> However, your DSpace instance is not running under root but under "/dspace". 
> I conclude this from the fact that you receive a redirect to 
> "https://test-dspace.xxx.net//dspace/shibboleth-login 
> ". This means you have 
> to adjust the Apache configuration to secure that location instead. 
> 
> So your problem should be solved when you change " "/shibboleth-login">" to "". Can you 
> please try that and let me know if that works?
> 
> Best regards,
> Tom
>  
>   Tom Desair
> 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
> Esperantolaan 4, Heverlee 3001, Belgium
> www.atmire.com 
> 
> 
> 2017-02-21 23:51 GMT+01:00 J Bell  >:
> 
> We are moving to Shibboleth and I am having a problem figuring out where my 
> configuration is not set correctly to allow the actual authentication to 
> occur.  This is working in other instances we have running - only dSpace  is 
> not yet configured properly.   Would anyone have some input as to where I 
> have wandered into the weeds?
> 
> Notes about our configuration:
> 
> I have the IDP and my local SP  (shibboleth 2.5.2)   configured and talking 
> as I would expect.  
> 
> We are using mod_ajp  for the proxy  (this did not work under regular proxy 
> either - I have tried both ways).  My shibboleth2.xml configuration looks 
> like this:
> 
> https://xxx.xxx.net/shibboleth 
> "
>  id="default" policyId="default"
>  REMOTE_USER="eppn persistent-id targeted-id"
>  signing="false" encryption="false"
>  attributePrefix="AJP_">
> 
>checkAddress="false" handlerSSL="false" cookieProps="https">
> 
> https://alpha.signin.xxx.edu/idp/shibboleth 
> " Location="/Login"
>  discoveryProtocol="SAMLDS" 
> discoveryURL="https://ds.example.org/DS/WAYF 
> ">
>   SAML2 SAML1
> 
> 
> 
> 
> My attribute-map.xml  has the following attributes mapped - which come back 
> as expected:
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> /Shibboleth.sso/Session returns this:
> 
> 
> Miscellaneous
> Session Expiration (barring inactivity): 476 minute(s)
> Client Address: xxx.xxx.xxx.xxx
> SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
> Identity Provider: https://alpha.signin.xxx.edu/idp/shibboleth 
> 
> Authentication Time: 2017-02-20T17:31:43.925Z
> Authentication Context Class: 
> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
> Authentication Context Decl: (none)
> 
> Attributes
> cn: jbell
> displayName: Julie Bell
> email: jb...@xxx.edu 
> givenName: Julie
> ksuPersonWildcatId: 
> sn: Bell
> telephoneNumber: x
> uid: jbell
> 
> 
> After proper authentication the service is returned to:
> 
> https://test-dspace.xxx.net//dspace/shibboleth-login 
> 
> 
> and:  
> Authentication Failed
> 
> 
> The dspace log responds with this:
> 
> 2017-02-21 19:42:04,972 INFO  
> org.dspace.app.xmlui.aspect.artifactbrowser.CommunityBrowser @ 
> anonymous:session_id=DDFBE06E3003021B702DF0A1310B4816:ip_addr=xxx.xxx.xxx.xxx:view_community_list:
> 2017-02-21 19:42:04,973 INFO  
> org.dspace.app.xmlui.aspect.discovery.SidebarFacetsTransformer @ facets for 
> scope, null: 3
> 2017-02-21 19:42:05,677 INFO  
> org.dspace.app.xmlui.aspect.arti

Re: [dspace-tech] dspace not picking up Shibboleth attributes to authenticate

[Tom Desair]

Hi Julie,

The key here is the Apache configuration section

> 
>  AuthType shibboleth
>  ShibRequireSession On
>  Require valid-user
> 


This tells the Apache Shibboleth daemon to require a Shibboleth session
when visiting "/shibboleth-login" and to provide all mapped attributes to
the Tomcat application server. For all other URL endpoints, Shibboleth will
not forward the attributes.

However, your DSpace instance is not running under root but under
"/dspace". I conclude this from the fact that you receive a redirect to "
https://test-dspace.xxx.net//dspace/shibboleth-login";. This means you have
to adjust the Apache configuration to secure that location instead.

So your problem should be solved when you change "" to "". Can you
please try that and let me know if that works?

Best regards,
Tom

[image: logo] Tom Desair
250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586
Esperantolaan 4, Heverlee 3001, Belgium
www.atmire.com


2017-02-21 23:51 GMT+01:00 J Bell :

>
> We are moving to Shibboleth and I am having a problem figuring out where
> my configuration is not set correctly to allow the actual authentication to
> occur.  This is working in other instances we have running - only dSpace
>  is not yet configured properly.   Would anyone have some input as to where
> I have wandered into the weeds?
>
> Notes about our configuration:
>
> I have the IDP and my local *SP  (shibboleth 2.5.2)  * configured and
> talking as I would expect.
>
> We are using *mod_ajp*  for the proxy  (this did not work under regular
> proxy either - I have tried both ways).  My *shibboleth2.xml* configuration
> looks like this:
>
> https://xxx.xxx.net/shibboleth";
>  id="default" policyId="default"
>  REMOTE_USER="eppn persistent-id targeted-id"
>  signing="false" encryption="false"
>  attributePrefix="AJP_">
>
>checkAddress="false" handlerSSL="false"
> cookieProps="https">
>
> https://alpha.signin.xxx.edu/idp/shibboleth";
> Location="/Login"
>  discoveryProtocol="SAMLDS" discoveryURL="https://ds.
> example.org/DS/WAYF">
>   SAML2 SAML1
> 
>
>
>
> My *attribute-map.xml*  has the following attributes mapped - which come
> back as expected:
>
>  
> 
> 
> 
> 
> 
>
>
>
> */Shibboleth.sso/Session *returns this:
>
>
> Miscellaneous
> Session Expiration (barring inactivity): 476 minute(s)
> Client Address: xxx.xxx.xxx.xxx
> SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
> Identity Provider: https://alpha.signin.xxx.edu/idp/shibboleth
> Authentication Time: 2017-02-20T17:31:43.925Z
> Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:
> PasswordProtectedTransport
> Authentication Context Decl: (none)
>
> Attributes
> cn: jbell
> displayName: Julie Bell
> email: jb...@xxx.edu
> givenName: Julie
> ksuPersonWildcatId: 
> sn: Bell
> telephoneNumber: x
> uid: jbell
>
>
> After proper authentication the service is returned to:
>
> https://test-dspace.xxx.net//dspace/shibboleth-login
>
> and:
> Authentication Failed
>
> The* dspace log *responds with this:
>
> 2017-02-21 19:42:04,972 INFO  
> org.dspace.app.xmlui.aspect.artifactbrowser.CommunityBrowser
> @ anonymous:session_id=DDFBE06E3003021B702DF0A1310B48
> 16:ip_addr=xxx.xxx.xxx.xxx:view_community_list:
> 2017-02-21 19:42:04,973 INFO  
> org.dspace.app.xmlui.aspect.discovery.SidebarFacetsTransformer
> @ facets for scope, null: 3
> 2017-02-21 19:42:05,677 INFO  
> org.dspace.app.xmlui.aspect.artifactbrowser.CommunityBrowser
> @ anonymous:session_id=DDFBE06E3003021B702DF0A1310B48
> 16:ip_addr=xxx.xxx.xxx.xxx:view_community_list:
> 2017-02-21 19:42:05,678 INFO  
> org.dspace.app.xmlui.aspect.discovery.SidebarFacetsTransformer
> @ facets for scope, null: 3
> 2017-02-21 19:42:27,872 ERROR org.dspace.authenticate.ShibAuthentication
> @ Shibboleth authentication was not able to find a NetId, Email, or Tomcat
> Remote user for which to indentify a user from.
> 2017-02-21 19:42:27,872 ERROR org.dspace.authenticate.ShibAuthentication
> @ Unable to register new eperson because we are unable to find an email
> address along with first and last name for the user.
>   NetId Header: 'null'='null' (Optional)
>   Email Header: 'email'='null'
>   First Name Header: 'givenName'='null'
>   Last Name Header: 'sn'='null'
> 2017-02-21 19:42:27,872 INFO  org.dspace.app.xmlui.utils.AuthenticationUtil
> @ anonymous:session_id=01CF256229E776009AE83845CF4341
> A2:ip_addr=xxx.xxx.xxx.xxx:failed_login:email=null, realm=null, result=4
> 2017-02-21 19:42:28,444 INFO  
> org.dspace.app.xmlui.aspect.artifactbrowser.CommunityBrowser
> @ anonymous:session_id=01CF256229E776009AE83845CF4341
> A2:ip_addr=xxx.xxx.xxx.xxx:view_community_list:
> 2017-02-21 19:42:28,444

[dspace-tech] dspace not picking up Shibboleth attributes to authenticate

[J Bell]

We are moving to Shibboleth and I am having a problem figuring out where my 
configuration is not set correctly to allow the actual authentication to 
occur.  This is working in other instances we have running - only dSpace 
 is not yet configured properly.   Would anyone have some input as to where 
I have wandered into the weeds?

Notes about our configuration:

I have the IDP and my local *SP  (shibboleth 2.5.2)  * configured and 
talking as I would expect.  

We are using *mod_ajp*  for the proxy  (this did not work under regular 
proxy either - I have tried both ways).  My *shibboleth2.xml* configuration 
looks like this:

https://xxx.xxx.net/shibboleth";
 id="default" policyId="default"
 REMOTE_USER="eppn persistent-id targeted-id"
 signing="false" encryption="false"
 attributePrefix="AJP_">



https://alpha.signin.xxx.edu/idp/shibboleth"; 
Location="/Login"
 discoveryProtocol="SAMLDS" 
discoveryURL="https://ds.example.org/DS/WAYF";>
  SAML2 SAML1




My *attribute-map.xml*  has the following attributes mapped - which come 
back as expected:

 








*/Shibboleth.sso/Session *returns this:


Miscellaneous
Session Expiration (barring inactivity): 476 minute(s)
Client Address: xxx.xxx.xxx.xxx
SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Identity Provider: https://alpha.signin.xxx.edu/idp/shibboleth
Authentication Time: 2017-02-20T17:31:43.925Z
Authentication Context Class: 
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Authentication Context Decl: (none)

Attributes
cn: jbell
displayName: Julie Bell
email: jb...@xxx.edu
givenName: Julie
ksuPersonWildcatId: 
sn: Bell
telephoneNumber: x
uid: jbell


After proper authentication the service is returned to:

https://test-dspace.xxx.net//dspace/shibboleth-login

and:  
Authentication Failed

The* dspace log *responds with this:

2017-02-21 19:42:04,972 INFO 
 org.dspace.app.xmlui.aspect.artifactbrowser.CommunityBrowser @ 
anonymous:session_id=DDFBE06E3003021B702DF0A1310B4816:ip_addr=xxx.xxx.xxx.xxx:view_community_list:
2017-02-21 19:42:04,973 INFO 
 org.dspace.app.xmlui.aspect.discovery.SidebarFacetsTransformer @ facets 
for scope, null: 3
2017-02-21 19:42:05,677 INFO 
 org.dspace.app.xmlui.aspect.artifactbrowser.CommunityBrowser @ 
anonymous:session_id=DDFBE06E3003021B702DF0A1310B4816:ip_addr=xxx.xxx.xxx.xxx:view_community_list:
2017-02-21 19:42:05,678 INFO 
 org.dspace.app.xmlui.aspect.discovery.SidebarFacetsTransformer @ facets 
for scope, null: 3
2017-02-21 19:42:27,872 ERROR org.dspace.authenticate.ShibAuthentication @ 
Shibboleth authentication was not able to find a NetId, Email, or Tomcat 
Remote user for which to indentify a user from.
2017-02-21 19:42:27,872 ERROR org.dspace.authenticate.ShibAuthentication @ 
Unable to register new eperson because we are unable to find an email 
address along with first and last name for the user.
  NetId Header: 'null'='null' (Optional)
  Email Header: 'email'='null'
  First Name Header: 'givenName'='null'
  Last Name Header: 'sn'='null'
2017-02-21 19:42:27,872 INFO  org.dspace.app.xmlui.utils.AuthenticationUtil 
@ 
anonymous:session_id=01CF256229E776009AE83845CF4341A2:ip_addr=xxx.xxx.xxx.xxx:failed_login:email=null,
 
realm=null, result=4
2017-02-21 19:42:28,444 INFO 
 org.dspace.app.xmlui.aspect.artifactbrowser.CommunityBrowser @ 
anonymous:session_id=01CF256229E776009AE83845CF4341A2:ip_addr=xxx.xxx.xxx.xxx:view_community_list:
2017-02-21 19:42:28,444 INFO 
 org.dspace.app.xmlui.aspect.discovery.SidebarFacetsTransformer @ facets 
for scope, null: 3

The *shibboleth* log responds with:

2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]: New session (ID: 
_7aa0bd831d4bbfd9e852e1d24414b924) with (applicationId: default) for 
principal from (IdP: https://alpha.signin.xxx.edu/idp/shibboleth) at 
(ClientAddress: xxx.xxx.xxx.xxx) with (NameIdentifier: 
_19a0b33cc94439c79fc401cf9cc63200) using (Protocol: 
urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID: 
_147bb17c58c8c230f513f12d154c3489)
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]: Cached the following 
attributes with session (ID: _7aa0bd831d4bbfd9e852e1d24414b924) for 
(applicationId: default) {
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]:uid (1 values)
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]:displayName (1 
values)
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]:sn (1 values)
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]:givenName (1 values)
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]:cn (1 values)
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]:email (1 values)
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]:telephoneNumber (1 
values)
2017-02-21 22:37:17 INFO Shibboleth-TRANSACTION [2]: }



*Apache 2.4.25 configuration* looks like:


   UseCanonicalName On