Unable to authenticate with Shibboleth

Hi,

I am currently trying to set up a new instance of Seafile server, community edition 6.2.3 and it seems everything is working as expected except authentication.
The server is placed behind an apache server that terminates the SSL and acts as an reverse proxy.
I’ve tried to configure the apache server according to the instructions from manual.seafile.com, but are not able to reach the goal.

Apache HTTPS:
https://manual.seafile.com/deploy/https_with_apache.html

and Shibboleth:
https://manual.seafile.com/deploy/shibboleth_config.html

When trying to authenticate, I am redirected to my IDP and after successful authentication I am redirected back to Seahub. The problem is that it seems like I am not authenticated so I will end up at the login page.

These are the configured settings in seahub_settings.py
EXTRA_AUTHENTICATION_BACKENDS = (
‘shibboleth.backends.ShibbolethRemoteUserBackend’,
)
EXTRA_MIDDLEWARE_CLASSES = (
‘shibboleth.middleware.ShibbolethRemoteUserMiddleware’,
)

ENABLE_SHIB_LOGIN = True

SHIBBOLETH_ATTRIBUTE_MAP  = {
"HTTP_MAIL": (False, "username"),
"HTTP_GIVENNAME": (False, "givenname"),
"HTTP_SN": (False, "surname"),
"HTTP_MAIL": (False, "contact_email"),
"HTTP_ORGANIZATION": (False, "institution"),
}

Configuration snip from apache:
<Location /Shibboleth.sso>
SetHandler shib
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting applicationId default
require shib-session

<Location /shib-login>
AuthType shibboleth
ShibUseHeaders On
ShibRequestSetting requireSession true
Require valid-user

SetEnvIf Authorization “(.*)” HTTP_AUTHORIZATION=$1
ProxyPass / http://127.0.0.1:8000/
ProxyPassReverse / http://127.0.0.1:8000/

Is there a way to troubleshoot the authentication process on the Seahub side?

Thanks in advance,
Robert

hi,

I suppose that you have read this post about the pro version :

If not, it may provide some tips to troubleshoot.

I also give you my Apache config, if it can help.

   Alias /seafmedia  /seafile/seafile-server-latest/seahub/media
   RewriteEngine On

   # debug error 127.0.0.1
   ProxyPreserveHost On

   #
   # seafile fileserver
   #
   ProxyPass /seafhttp http://127.0.0.1:8082
   ProxyPassReverse /seafhttp http://127.0.0.1:8082
   RewriteRule ^/seafhttp - [QSA,L]

  <Location /seafmedia>
  ProxyPass !
  Require all granted
  </Location>


  <Directory /seafile/seafile-server-latest/seahub/media>
  Order allow,deny
  Allow from all
  #New directive needed in Apache 2.4.3:
  Require all granted
  </Directory>


  #
  # seafile webdav
  #

  # WCGI mode

  SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
  ProxyPass /davf http://127.0.0.1:8080/
  ProxyPassReverse /davf http://127.0.0.1:8080/



  #
  # seahub
  #


  # WCGI mode

  SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
  ProxyPass / http://127.0.0.1:8000/
  ProxyPassReverse / http://127.0.0.1:8000/


  #Shibboleth
  <Location /Shibboleth.sso>
        SetHandler shib
        AuthType shibboleth
        ShibRequestSetting requireSession 1
        ShibRequestSetting applicationId default
        require shib-session
  </Location>

  <Location /api2>
        AuthType None
        Require all granted
        Allow from all
        satisfy any
  </Location>

  <Location /shib-login>
        AuthType shibboleth
        ShibRequestSetting requireSession true
        Require valid-user
        # WCGI mode
        ShibUseHeaders On
  </Location>

Thanks for the hints.
The problem is however not solved.
When looking at the shibboleth log, it looks like the authentication is consumed ok.

2018-01-03 10:05:36 INFO Shibboleth-TRANSACTION [3]: New session (ID: _bf43c2c60cc0fedc91ec3af839a2fce5) with (applicationId: default) for principal from (IdP: https://idp.company.se/idp) at (ClientAddress: 152.177.115.26) with (NameIdentifier: robert@company.org) using (Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID: _0be554a54adf12450a5c4f4c452ff4ae)
2018-01-03 10:05:36 INFO Shibboleth-TRANSACTION [3]: Cached the following attributes with session (ID: _bf43c2c60cc0fedc91ec3af839a2fce5) for (applicationId: default) {
2018-01-03 10:05:36 INFO Shibboleth-TRANSACTION [3]: 	mail (1 values)
2018-01-03 10:05:36 INFO Shibboleth-TRANSACTION [3]: }

I do however not see anything in the seahub / seafile logs. I am also returned to the login page.

3 cookies seems to be created:
_shibsession_64656661756c7468747470733a2f2f66696c65732e7068656e697869642e7365
csrftoken
sessionid

Is there a way to troubleshoot the seahub part of the setup, in order to verify that correct data is passed to the application?

Kind regards,
Robert

Hi, did you configure the shibboleth2.xml file as follows for the REMOTE USER vars ?

<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
<ApplicationDefaults entityID="https://xxx.yyy.fr"
                     REMOTE_USER="mail eppn persistent-id targeted-id">

Yes,
My shibboleth2.xml file looks just like that.

Regards,
Robert

Any other ideas?
As previously mentioned, it seems like the SAML authentication is working alright.
The problem seems to be that Seahub don’t consume the SAML authentication.

Kind Regards,
Robert

Hi,

What are your seahub_settings ?

Considering that only the mail attribute is passed, you should have

SHIBBOLETH_ATTRIBUTE_MAP  = {
   # "HTTP_EPPN": (True, "username"),
   # "HTTP_GIVENNAME": (True, "givenname"),
   # "HTTP_SN": (True, "surname"),
    "HTTP_MAIL": (True, "username"),
    "HTTP_MAIL": (True, "contact_email"),
    #"HTTP_ORGANIZATION": (False, "institution"),
    }

Hi,

I’m having the same problem (except I’m trying to switch from fastcgi to wsgi before upgrading to 6.2.x version of server)… Authentication seems to go through, but redirections don’t seem to work (I end up in login page over and over again).

I read the post for pro version, and if I add setting “SHIBBOLETH_REMOTE_USER = ‘HTTP_REMOTE_USER’” I end up with server error (in django log “Can’t connect to daemon”) - is this setting supposed to help this login issue?

Otherwise, I have (almost) the same settings as Robert (except we use eppn), and shibboleth_attribute_map in seahub_settings does look like gauburtin wrote (well, i have only eppn uncommented as it’s the only value passed).

It really seems like there is something wrong with redirections when using Shibboleth and apache2 with wsgi.

Has anybody any idea how to fix this?

Hi,
Unfortunately I decided to go with another product than Seafile as I never succeeded with the configuration.

//Robert

@daniel.pan, @xiez,
You may consider having a look at this thread about Shibboleth login.
regards

Hi @sniexx, adding setting “SHIBBOLETH_REMOTE_USER = ‘HTTP_REMOTE_USER’” will help fix the redirection issue.

in django log “Can’t connect to daemon”

means seafile daemon is dead, try restart seafile service and test shibboleth login again.

You can also send me your apache config and seahub_settings.py if the authentication still not working.

Hi @Robert, please send me your apache config and seahub_settings.py if possible.

I tried restarting service (seafile, apache2 and shibboleth in all possible combinations), rebooting server and nothing helped. Currently I’m back to fastcgi because there’s quite a few people using seafile. However, I’ve kept configurations:

apache2:

RewriteEngine On
ProxyPreserveHost On

<Location /media>
    ProxyPass !
    Require all granted
</Location>

# seafile
ProxyPass /seafhttp http://127.0.0.1:8082
ProxyPassReverse /seafhttp http://127.0.0.1:8082
RewriteRule ^/seafhttp - [QSA,L]

# seahub
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
ProxyPass / http://127.0.0.1:8000/
ProxyPassReverse / http://127.0.0.1:8000/

<Location /Shibboleth.sso>
    SetHandler shib
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    ShibRequestSetting applicationId default
    require shib-session
</Location>

<Location /api2>
    AuthType None
    Require all granted
    Allow from all
    satisfy any
</Location>

<Location /shib-login>
    AuthType shibboleth
    ShibRequestSetting requireSession true
    ShibUseHeaders On
    Require valid-user
    ShibUseHeaders On
</Location>

seahub_settings.py:

EXTRA_AUTHENTICATION_BACKENDS = (
    'shibboleth.backends.ShibbolethRemoteUserBackend',
)

EXTRA_MIDDLEWARE_CLASSES = (
    'shibboleth.middleware.ShibbolethRemoteUserMiddleware',
)

SHIBBOLETH_ATTRIBUTE_MAP = {
    "HTTP_EPPN": (True, "username"),
}
#SHIBBOLETH_USER_HEADER = 'HTTP_REMOTE_USER'

ENABLE_SHIB_LOGIN = True
SITE_ROOT = '/'
SITE_TITLE = 'Seafile'
ENABLE_SIGNUP =  True

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
    }
}

SESSION_COOKIE_AGE = 60 * 60 * 8
SESSION_EXPIRE_AT_BROWSER_CLOSE = True
ENABLE_REPO_HISTORY_SETTING = True

USE_PDFJS = True
FILE_PREVIEW_MAX_SIZE = 50 * 1024 * 1024

CLOUD_MODE = False
ENABLE_GLOBAL_ADDRESSBOOK = True

SHIBBOLETH_USER_HEADER = 'HTTP_REMOTE_USER' is required if switch from fastcgi to wsgi.
please uncomment this line, and restart seafile service.

I did that, but it didn’t work… I kept getting errors (in apache [proxy:error] [pid 1349:tid 139689260349184] AH00940: HTTP: disabled connection for (127.0.0.1), in seahub.init (at service restart): Error:Seahub failed to start., in seahub_django_request: django.request:170 get_response Not Found: /Shibboleth.sso/SAML2/POST and NetworkError: Can’t connect to daemon; I’m not sure under which conditions certain error appeared, as I tried multiple combinations). I will try again on Saturday (unfortunately I cannot play with this before weekend) and let you know about the results. If this time works - even better :slight_smile:

this error indicates that seafile daemon service is down, which may caused by some hidden bugs in seafile server. You can check by ps -ef | grep ccnet-server and ps -ef | grep seaf-server, these two daemon services should be alive if seafile service is in operational.

I just tried again and now it works :smiley: I don’t really know what went wrong last few times, probably I did it in wrong order or forgot to comment out something. The only problem I have now is redirection. With FastCGI I had redirection to Shibboleth login, so users didn’t have to click on “Shibboleth” for login. This part doesn’t work anymore. I guess I’ll just have to figure out new rewrite rules again :slight_smile:

Also… it would be nice, if you updated Shibboleth configuration part in the Server manual, as it still contains FastCGI.

Thanks :slight_smile:

Don’t use redirect anymore with wcgi, only use proxy

#
# seahub
#
# old config 6.1 keep for fastcgi
# RewriteRule ^/(seafmedia.*)$ /$1 [QSA,L,PT]
# RewriteCond %{REQUEST_FILENAME} !-f
# RewriteRule ^(.*)$ /seahub.fcgi/$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# new config 6.2 only for wsgi

ProxyPreserveHost On

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
ProxyPass / http://127.0.0.1:8000/
ProxyPassReverse / http://127.0.0.1:8000/

Yes, this part is done with proxy. That’s not the problem. I have login for admins and users separated by url (eg. shibboleth users go to site.domain and are automatically logged in, for admin purposes we use adminsite.domain which needs login form) and I’m not sure if I can do this without redirects…

All right, quite complicated …
Are you sure you need this feature ?