Core: SAML token not accepted in OCS routes

[davivel]

Steps to reproduce

1. Setup Shibboleth app with "Autoprovision Users", "Shib-Session-ID" as Shibboleth session, and "eppn" as uid, email, and display name.
2. Get a valid Shibb token (I'm working with Android app, see owncloud/android#1710 or owncloud/ios#700)
3. GET /ocs/v2.php/apps/files_sharing/api/v1/shares with fresh token
   

   Expected behaviour

Response is OK with list of shares

Actual behaviour

Response is 302 with SAML request

Server configuration

Operating system:
Ubuntu

Web server:
Apache/2.4.7

Database:
MySQL

ownCloud version: (see ownCloud admin page)
ownCloud Enterprise Edition 9.1.0 beta 1 (testing)

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results here.

File not found
The specified document has not been found on the server.
You can click here to return to ownCloud.

List of activated apps:
Activity 2.3.2
Collaborative tags 0.3.0
Comments 0.3.0
Deleted files 0.9.0
Enterprise license key
External storage support 0.6.0
Federation 0.1.0
File firewall 2.4.0
First run wizard 1.1
Gallery 15.0.0
Log user and file sharing actions
Mail Template Editor 0.1
Notifications 0.3.0
PDF Viewer 0.8.1
Provisioning API 0.5.0
Share Files 0.10.0
Shibboleth user backend
Text Editor 2.1
Update notification 0.2.1
Versions 1.3.0
Video player 0.9.8
Windows Network Drive for Files external 0.2.33
Workflow 0.2.3

Are you using external storage, if yes which one: local/smb/sftp/...
No; app enabled, but nothing configured

Are you using encryption: yes/no
No

Logs

ownCloud log (data/owncloud.log)

These appear when a correct PROPFIND to WebDAV is done, info level enabled:

Info    admin_audit User [email protected] logged out of ownCloud [CLIENT_IP: 256.256.256.256] [USER_AGENT: Mozilla/5.0 (Android) ownCloud-android/2.0.1] 2016-06-10T11:45:31+00:00
Info    admin_audit User [email protected] logged into ownCloud from IP address: 256.256.256.256 [CLIENT_IP: 256.256.256.256] [USER_AGENT: Mozilla/5.0 (Android) ownCloud-android/2.0.1]  2016-06-10T11:45:30+00:00
Info    admin_audit User [email protected] attempted to log into ownCloud from IP address: 256.256.256.256 [CLIENT_IP: 256.256.256.256] [USER_AGENT: Mozilla/5.0 (Android) ownCloud-android/2.0.1]    2016-06-10T11:45:30+00:00

Not sure that log in - log out for every operation is right.

No different log message with rejected GET to OCS.

[davivel]

Calling @PVince81 , @rullzer

[rullzer]

@ChristophWurst I suspect one of your changes...

[ChristophWurst]

I don't get it. If a 302 occurs even though the IdP session was created, that is not an issue of the server, is it?

[DeepDiver1975]

the 302 is returned to the client by the mod_shib module within apache - the ownCloud codebase is not executed.
This looks more like an issue with the session being properly maintained in the clients.

@davivel

Get a valid Shibb token (

What is that supposed to mean? We use sessions to auth against the shibboleth server

[davivel]

Just means log in the app, in our case.

We are using the same cookie for accessing WebDAV entry points and OCS entry points. Should that be a problem?

@jesmrec , do you know if desktop client is having problems also?

[jesmrec]

Opening the "Share with ownCloud" in desktop client does not expire the session.

[davivel]

And sharing works fine?

[jesmrec]

checking it

[jesmrec]

The desktop client does not seem to work properly. The first check i performed, the share view was correctly displayed and connection keeps on but no sharees were shown when are searched, but a spinner. Finally, the session expires and it is not possible to reconnect again. So, the problem is also happening in desktop client. The difference with mobile clients is that the session does not expire at the moment.

[davivel]

The difference with mobile clients is that the session does not expire at the moment.

Probably the server is not accepting the token equally, but desktop client is not deciding to report an error.

So, if clients are handling sessions incorrectly, we need to consider why the three clients do so with different implementations. And why they all work fine with server 9.0.2.

Any relevant change in session handling in the server side we need to consider between 9.0 and 9.1?

[DeepDiver1975]

Any relevant change in session handling in the server side we need to consider between 9.0 and 9.1?

all the plugable auth stuff touches the session handling

@ChristophWurst this might also be caused by a session which we now close to early compared to previous versions

[ChristophWurst]

@DeepDiver1975 I think I don't get the picture. How would session handling in ownCloud influence the session handling of the IdP or mod_shib?

[DeepDiver1975]

there are two(at least) session cookies which need to come along from the client to the server.
one for the idp/mod_shib-fu and the other one for owncloud (further cookies might be related to the load balancer and so one)
if - due to whatever reason - the session in owncloud is closed the whole connection is broken.
I have seen this behavior which gave me some debugging nightmare some time back.

How this all fits together : :question:

[ChristophWurst]

Hm, but if we - for whatever reason - close/kill the owncloud cookie/session, the client should still connect to ownCloud instead of being redirected right? To me it sounds impossible for ownCloud to kill the idp session.

[ChristophWurst]

the whole connection is broken

what does that mean? What happens then? Is the client redirected?

[DeepDiver1975]

Hm, but if we - for whatever reason - close/kill the owncloud cookie/session, the client should still connect to ownCloud instead of being redirected right? To me it sounds impossible for ownCloud to kill the idp session.

I know - this is some strange brain kung-fu - we need to debug this

[rperezb]

@ChristophWurst do you have an enviroment for you to reproduce this? ping us if you need it

[DeepDiver1975]

Let me see what I can do ....

[DeepDiver1975]

No need to debug with any mobile or desktop client - error is visible in the browser already

[DeepDiver1975]

As far as I can tell the ocs code is trying to getToken($sessionId) - but there was never any call to generate the token. - As of 9.1beta1 ...

[DeepDiver1975]

With master generateToken is called within loginWithApache and therfore works.

@davivel @jesmrec please retest on core master or 9.1beta2 which should hold the fix already as well

[ChristophWurst]

Thanks @DeepDiver1975. Then https://github.com/owncloud/core/pull/24912 was probably the fix

[davivel]

Thanks, guys, going for it.

[jesmrec]

@DeepDiver1975 @ChristophWurst

Checked on core master. It works on all clients (android, iOS, desktop) and in web browser.

👍

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.