6.2 Pro beta : Shibboleth Login fails (apache config)

Hi ,

Upgrade from pro 6.18 to pro 6.2 beta worked fine for me, except for Shibboleth login which brings to unlogged session.

If i log on with shibboleth, the IDP/SP process seems ok, but it ends to the default seahub login page (unlogged).

I restarted apache and shibd
The shibd log does not trace anything wrong

My previous Apache config in 6.1 (shibboleth) was :
(inspired from https://manual.seafile.com/deploy/shibboleth_config.html)

 #
  # seahub
  #

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

My new apache config in 6.2 (shibboleth) is :
(accordingly to https://manual.seafile.com/deploy/shibboleth_config.html)

 #
  # seahub
  #

  #new config 6.2

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

I suppose that the path from shibboleth to seahub is done by a Rewrite rule, but the previous one is deprecated by the use of wgsi instead of fscgi

RewriteRule ^(.*)$ /seahub.fcgi/$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Could you give me any help ?

Regards,

Gautier

Hi,

Does anybody have already tested 6.2 upgrade with Shibboleth logon ?
I’d like to know if the issue is also reported by others.
Regards,
Gautier

Hi @gauburtin, could u please restore old apache config and fastcgi way of starting seahub 6.2 pro?

If it works, we will need to look into the new wsgi apache config in the manual. Otherwise, there is something wrong with shibboleth in version 6.2.

Hi Xiez,

I did. Shibboleth login is still possible with fastcgi mode.
I’ve read that some data needs to be transferred into HTTP header when proxy mode is activated with sibboleth. But i tried many config with no success.

Regards,

Gautier

Hi @gauburtin, after switching apache config from fastcgi mode to proxy mode (wsgi mode), some environment variables (e.g. REMOTE_USER) are not readable in seafile. We have to make minor modifications both in apache config and seahub_settings.py.

Assume your config is same as https://github.com/haiwen/seafile-docs/blob/master/deploy/shibboleth_config.md

Apache Config

Add ShibUseHeaders On to shib-login block.

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

Replace fastcgi block,

        RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_URI} !^/Shibboleth.sso
        RewriteRule ^(.*)$ /seahub.fcgi$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

to proxy block,

        ProxyPass / http://127.0.0.1:8000/
        ProxyPassReverse / http://127.0.0.1:8000/

Seahub Settings

Open conf/seahub_settings.py, add SHIBBOLETH_USER_HEADER = 'HTTP_REMOTE_USER' to the end of file.

Your also need to update SHIBBOLETH_ATTRIBUTE_MAP, from

SHIBBOLETH_ATTRIBUTE_MAP  = {
    "eppn": (False, "username"),
    "givenname": (False, "givenname"),
    "sn": (False, "surname"),
    "mail": (False, "contact_email"),
    "organization": (False, "institution"),
}

to

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

since these attributes are come from http headers instead of environment variables.

Restart apache and seahub (./seahub.sh restart), and Shibboleth login should works now.

Hi @xiez
I presume that you forgot the first line here

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

But it now works fine : Thank you !

I’ve read that HTTP headers would be the solution for Shibboleth with ProxyPass, but i did not have the new vars in seahub settings.

I’ll make some more tests in the next days and i’ll be back if i notice some problems.

Regards,

Gautier.

Hi @xiez,

It looks that webdav does not works while already connected via shibboleth.
The path /davf leads to a blank page.

It seems thatr wedav cannot use shibbotleth auhtentification

To let you know, webdav works fine while fastcgi mode is set to false and the Apache vhost use Proxypass

Change

 # FASTCGI
  RewriteCond %{HTTP:Authorization} (.+)
  RewriteRule ^(/davf.*)$ /seafdav.fcgi$1 [QSA,L,e=HTTP_AUTHORIZATION:%1]
  RewriteRule ^(/davf.*)$ /seafdav.fcgi$1 [QSA,L]

to this

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

regards,

Gautier

Hi @xiez,

It looks that using headers in shibboleth is not recomended for security reasons
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig

ShibUseHeaders On|Off
    Defaults to "Off", this turns on the use of request headers to publish attributes to applications. Use of this option should be avoided. Be sure to review the topic on spoof checking if you enable it.

Also look here :
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking
Could you give us feedback about this ? I’m on Apache but i can’t find anything here
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking#NativeSPSpoofChecking-Apache

To let you know, i do not have any checkSpoofing property set, but it is enabled when omitted.

Regards,

Gautier

OK, I will look into the header spoofing issue.

Hi @xiez,

Did you look at header spoofing this issue ? Do you have any recommandations regarding security on Shib headers ?

Regards

Hi @gauburtin,

Sorry for the late reply.

Shibboleth has “spoof checking” feature and it’s pretty robust according to https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking

Starting with version 2.2 (and 1.3.2), this feature should be left enabled, and 
should be safe to use, as well as significantly more robust.

So I think we can count on this feature, and we will update https://manual.seafile.com/deploy/shibboleth_config.html soon.

If you still have any security concerns, please fall back to fastcgi mode which is the safest mechanism.

HI @xiez,

Ok, i trust you ! (Shibboleth doc is not very clear to me)

Regards
Gautier