Page MenuHomePhabricator

Adding an authentication adapter for Shibboleth SSO.
AbandonedPublic

Authored by ttt on Nov 7 2013, 6:35 PM.
Tags
None
Referenced Files
F12834369: D7524.id17147.diff
Thu, Mar 28, 2:35 PM
F12834350: D7524.id16969.diff
Thu, Mar 28, 2:35 PM
F12834328: D7524.id.diff
Thu, Mar 28, 2:34 PM
Unknown Object (File)
Thu, Mar 14, 11:10 AM
Unknown Object (File)
Fri, Mar 8, 7:11 AM
Unknown Object (File)
Sun, Mar 3, 3:30 AM
Unknown Object (File)
Feb 11 2024, 6:51 AM
Unknown Object (File)
Feb 4 2024, 2:34 AM

Details

Reviewers
epriestley
Group Reviewers
Blessed Reviewers
Summary

Shibboleth SSO integration for Phabricator installations behind Shibboleth enabled reverse-proxy.

Test Plan

First activate and configure the adapter with the header names for the Shibboleth variables introduced by your, second go to the login page and click the Login button from Login with Shibboleth section. The application must be behind a reverse proxy introducing the relevant HTTP headers. If don't have a working Shibboleth installation, the headers can be faked in the web server configuration.

Diff Detail

Branch
shibboleth_auth
Lint
Lint Passed
Unit
No Test Coverage

Event Timeline

Thanks! I have a few things going on today but I'll look at this when I get a chance.

(I'm not quite sure what's going on with that lint stuff.)

Please consider this revision together with D7525.

Hmm, okay, I don't understand how this actually works. What prevents me from firing up cURL and just doing:

curl --header "X-Shibboleth-User-ID: alincoln" https://phabricator.yourcompany.com/

...and thus logging in as anyone I want to?

It looks like we're just blindly trusting the credentials, and never verifying the user really is who they claim to be. Am I misunderstanding? Do I just not understand how Shibboleth works?

You are right, this authentication adapter trusts the headers.

This will only work for people that protect theis Phabricator behind a Shibboleth enabled reverse-proxy, such as Apache with mod_shibb.

Is this case, any Shibboleth authentication headers sent by the client are ignored by the reverse-proxy, which in will validate the session, redirect the user to the SSO login page if needed, and insert the trustable Shibboleth autentication headers when forwarding the requests to Phabricator.

ttt updated this revision to Unknown Object (????).Nov 18 2013, 5:00 PM

Avoiding the need to pass the request to the lib.

I think this provider is too dangerous to put in the upstream. Particularly, on a normal install, it allows an administrator to compromise any account in a few seconds:

  1. Add Shibboleth SSO as a provider.
  2. Send a header saying you're whatever user you want to be.

Administrators can not normally do this: they do not have the power to impersonate users, take over accounts, etc. So this would represent a dramatic and undesirable increase in administrative power.

Even on an install with Shibboleth configured, an administrator can just edit the configuration and say the User ID header is now "X-Anything-I-Want" (instead of the real Shibboleth header), then send that header to take over any account. Even if the reverse proxy filters out every header, the attacker can use some well-known header like "Accept-Encoding" as the User ID header.

(Although you might trust your administrators, this design limits what an attacker can do if he compromises an administrator account: he still has very little actual power, can't bypass policies, can't impersonate users, generally can't permanently destroy data, etc. This provider would allow an attacker who manages to compromise an account to have far greater power than normal.)

We could work around this, but it would require adding a bunch of configuration and complexity (we can not safely allow this provider to be configured from the web UI), and all that complexity would be useful only for this provider. This might make sense in the future, but so far no one else has expressed interest in Shibboleth auth. Until there's more demand for it, I don't think it makes sense to put it in the upstream because of how many security questions it raises.

I understand your reasons and I have no way to improve security of this authentication adapter.
Therefore I abandon this release.

Maybe in the future I will propose this again, if a more secure form of configuration for the authentication adapter options is implemented.

I have just been reading the Shibboleth docs on Service-Provider configuration for Apache. It describes these options:

  • ShibUseEnvironment On|Off
    • Defaults to "On", this turns on the use of environment variables to publish attributes to applications. This is strongly preferred over the header option.
  • 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.

Maybe this revision can be reformulated using the environment variable approach? The only required change seems to be s/$header/$_ENV/.

Would that mitigate your concerns, @epriestley?

Hello,

I've made some modification over this proposition, as suggested it's now using environment variables instead of http headers. I've also ported it to the last version of phabricator and added username autogeneration from first/last names, as my Shibboleth provider give a username that is invalid in Phabricator (numeric_id@institution.tld).

Do you think I should open a Diff ?

https://c4science.ch/diffusion/PHSHIB/