Offer more than basic auth for authentication.

[smidt]

For the authentication of clients (especially for owncloud/client#2111) in a domain it would be nice to have NTLM or Kerberos authentication.

[elpollodiablo]

I would like to second this request, but add that we'd really only need support for using httpd supplied REMOTE_USER - then kerberos (and other authentication, authorization and accounting opportunies) will be available via the right httpd auth modules.

Currently, Kerberos is doable with GSSAPI and LDAP - which negates the raison d'etre for kerberos, as I need to provide my cleartext password to an untrusted service.

edit: I'd like to make it clear that the lack of Kerberos integration (REMOTE_USER on the server side, kerberos on the client side) is a HUGE obstacle for us to integrate owncloud into our day-to-day workflow.

[kforner]

+1 for REMOTE_USER

[zorgzerg]

+1 for REMOTE_USER

[fpytloun]

+1 for REMOTE_USER

[MTRichards]

As an user, I would like to log into the ownCloud desktop client using Kerberos tickets so that users don't have to enter usernames and passwords, the domain login on the desktop servers to log users in to ownCloud.

Flow:
User logs into the desktop
ownCloud gets a certificate from the desktop
Presents certificate to ownCloud server
Server checks certificate
User is authenticated

User also needs to be able to log in using Basic Auth from Mobile and Mac. Possibly Linux can be covered with Kerberos, but for now focus on Windows.

[RobinMcCorkell]

@MTRichards (I've configured a few PHP services with Kerberos authentication, like Moodle, and this is what I've found)

The best way to implement this is through the web server, which is configured to attempt Kerberos authentication for a particular path that currently isn't used in ownCloud. The login page would try to load this 'resource' in the background, triggering the authentication with Kerberos if the client has a ticket, silently failing if it does not. Then the login page detects the success/failure of loading that resource and can redirect to the main ownCloud page. This 'resource' would perform the steps for creating a session and all other login procedures.

Other approaches involve a separate login page (poor UX IMHO), or a redirect on first load of the login page from an internal client (this is how Moodle does it, also poor UX). I think Moodle only chose to redirect to the SSO login attempt page since it doesn't make heavy use of JavaScript and wanted to keep everything simple. We use a lot of JavaScript anyway, so doing this step in the background (as described above) gives far better UX.

This will work with Windows, Linux and Mac, without issue, as long as the browsers are configured to allow SSO authentication to the domain (they are in an AD domain).

[MTRichards]

@Xenopathic thanks! This is really helpful information. Also adding @cmonteroluque @dragotin @DeepDiver1975 @LukasReschke

[ghost]

moving to 9.2 to get out of backlog

[Zombie-Ryushu]

Under Linux, Kerberos Authentication has more to do with Apache and FireFox than PHP.

[kforner]

kerberos support is already implemented in apache. All you have to do is support the use of the REMOTE_USER evn var in owncloud,.

[ghost]

REMOTE_USER -> Maybe just a matter to make https://apps.owncloud.com/content/show.php/user_servervars?content=167947 compatible as it seems this won't happen in core

[ghost]

Also another possibility: https://apps.owncloud.com/content/show.php/User+server+environment+authentication?content=174682

[michi-roth]

REMOTE_USER would not be sufficient if you want to access external storage with the supplied kerberos credentials.
A possible login procedure should look like that:

1 ) Windows need to generate "forwardabel" tickets (can be set up via the "Kerberos Policy")

2. The browser must be configured to forward tickets (https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM)

3. The webserver must request the kerberos credentials: This can be done via libapache2-mod-kerberos or php-krb5 (https://pecl.php.net/package/krb5). The php extension is IMHO the better way

3a) If no valid credentials are supplied, the webserver sends the login page which must be configure as 401 error page (Example for webauth: https://www.eyrie.org/~eagle/software/webauth/install-spnego.html)

4. ownCloud stores the kerberos ticket (to allow clustering) and uses it to access the external storage by impersonating the user

[jmceleney]

I have just finished implementing spnego support for Owncloud 9.1.3. This is my patch:
owncloud-9.1.3-spnego.patch.txt

This is how you use it:

1. Apply the patch
2. Install and enable the pecl krb5 module
3. Place your keytab file somewhere that the web user can access it, and change ownership to match.
4. Edit your config.php and add 'kerberos_spnego' => true,
5. Unless your keytab file is located at /etc/krb5.keytab, set the config option:
   'kerberos_keytab' => '/path/to/your.keytab'

That's it.

I've also manually applied the patch to the master in git. I'll put that up shortly.

This is not thoroughly tested, but it works for me during my brief testing. I have no idea how webdav or other clients might respond to the altered "401" status and WWW-Authenticate header on the login page.

[jmceleney]

I've forked owncloud core, and applied the patch here:
https://github.com/jmceleney/core
This branch is completely untested.

[jmceleney]

This is a slightly cleaner and more concise version of the patch:
owncloud-9.1.3-spnego.patch.txt

[guruz]

@jmceleney Great! Why don't you send a normal pull request here so it can get reviewed and integrated?

[gh-andi]

What is the newest status on this ?
I would be really interested to use this in our companies environment

[guruz]

@gh-andi I'm hoping @jmceleney can contribute his patch via the pull request mechanism. We have to go this way because of the contribution model

[JKawohl]

@jmceleney any news? would you mind providing a pull request?

[stale]

This issue has been automatically closed.

[jmuf]

deliberately closed ,or just auto-stale? There even was a patch provided 5 years ago, just not via the "normal pull request"...