Impersonate CSRF errors

[Eric O'Callaghan]

Hi,

I am part of a team looking into setting up NEMO at the University of Pennsylvania, but am struggling to get the "Impersonate" feature to work.

We have NEMO running well with Apache terminating SSL as a reverse-proxy in front, ProxyPass'ing locally to gunicorn on port 8000. We can authenticate fine, but when attempting to use the "Impersonate" feature, the name in the top right corner does not change, and we receive a CSRF token error message whenever trying to perform an action while "impersonating" (such as starting to use a tool). I have attached screenshots below showing the CSRF error as well as a majority of the log output.

I have adjusted numerous CSRF and security settings within settings.py and re-deployed  and restarted NEMO repeatedly, but I have not had any improvements with my changes.

We are simply using HTTP basic authentication within Apache currently, which is working fine to allow us to log in directly as "captain", "ned", "professor", etc for testing with the launch pad data.

We would really appreciate any feedback or thoughts on why we cannot get "impersonate" to work as expected and as shown on https://nemo.nist.gov/demo

Thank you in advance!

Cheers,

Eric O'Callaghan

Application Development Operations Engineer

Penn Engineering @ University of Pennsylvania

[Eric O'Callaghan]

It looks like my screenshots may have gotten eaten so I am re-attaching them - sorry about that!

Thank you again!

[Nicholas Bentley]

Hello Eric,

We're testing out NEMO to deploy at UMD as well but have never tried to use that feature. I just tried to start using a tool when impersonating a user and encountered the same error. Maybe you have discovered a bug? I will experiment a bit and let you know if I figure out how to fix it.

Our environment is very similar to yours (reverse proxy in front of NEMO).

All the best,

Nick

Nicholas Bentley (he/him)
Sr. Systems Engineer
A. James Clark School of Engineering
University of Maryland, College Park

nben...@umd.edu · (301) 405-0582 · Schedule a meeting
 

THE WORLD GOES TO MARYLAND

--
You received this message because you are subscribed to the Google Groups "nemo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nemo+uns...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/nemo/6e57c3b0-4d13-4931-a68f-c3d26e3d1ab4n%40list.nist.gov.

[Chris Price]

Similar error experience here at UC Irvine, reverse proxy setup, investigated things like csrfmiddlewaretoken https://github.com/usnistgov/NEMO/blob/master/NEMO/templates/calendar/calendar.html#L237

Seemed like a middleware issue or something,

-Chris Price

Office of Research IT

UC Irvine

[mathieu...@gmail.com]

Hi guys,

It's interesting that you all seem to be experiencing the same issue.

I am not very familiar with Apache, however I was able to get this feature to work with Nginx consistently.

A few questions for you:

1. do you have HTTPS setup? self-signed or legit certificate
2. in your settings.py MIDDLEWARE, do you have 'NEMO.middleware.ImpersonateMiddleware' installed?
3. in your settings.py, what are the values for CSRF_COOKIE_SECURE, CSRF_COOKIE_AGE and CSRF_USE_SESSIONS

[Chris Price]

Thanks for looking at it, I'll provide our config:

1. Legit signed by InCommon

2. Yes

MIDDLEWARE = [
"django.middleware.security.SecurityMiddleware",
"django.middleware.common.CommonMiddleware",
"django.contrib.sessions.middleware.SessionMiddleware",
"django.middleware.csrf.CsrfViewMiddleware",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.contrib.messages.middleware.MessageMiddleware",
"django.middleware.clickjacking.XFrameOptionsMiddleware",
"django.middleware.common.BrokenLinkEmailsMiddleware",
"NEMO.middleware.DeviceDetectionMiddleware",
"NEMO.middleware.ImpersonateMiddleware",
"shibboleth.middleware.ShibbolethRemoteUserMiddleware",
"NEMO.middleware.RemoteUserAuthenticationMiddleware", ]

3. See below

CSRF_COOKIE_SECURE = True
CSRF_COOKIE_AGE = None
CSRF_USE_SESSIONS = False

-Chris

[Mathieu Rampant]

try putting the Impersonate Middleware as the last Middleware

[Mathieu Rampant]

it needs to be inserted after any kind of authentication Middleware so it can override the request.user

[Chris Price]

For us the only combination that works is shibboleth needs to be after impersonate but before remoteuser, otherwise the application has other issues.

Maybe I'll let the others respond with their configs,

-Chris

[Eric O'Callaghan]

Hi,

Moving "NEMO.middleware.ImpersonateMiddleware" below "NEMO.middleware.HTTPHeaderAuthenticationMiddleware" within the "MIDDLEWARE" list inside of "settings.py" seems to have resolved the problem!

I am waiting for our users to confirm! It looks good to me though, and I am no longer getting CSRF errors. Thank you so much!!!

@Chris - we are actually using Shibboleth within Apache as well. However, we are relying on "HTTPHeaderAuthenticationMiddleware" and passing Shibboleth's "REMOTE_USER" via "AuthBasicFake" within Apache:

https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html#authbasicfake

https://gist.github.com/ericoc/8a5148df01622c05b4fcb39f4913522e

So far, we have only been manually adding user accounts, but I am very interested and curious what your method is for Shibboleth authentication.

We have only just started setting up NEMO, and we are not yet using it in production, so have not actually gotten into trying to read attributes (such as first name, last name, e-mail address, etc.) from our SSO provider.

Thank you again!

Cheers,
Eric O'Callaghan

[Nicholas Bentley]

Hi all,

Moving the impersonate middleware seems to have resolved the CSRF issues for us as well.

Coincidentally, we’re also using Shibboleth within Apache / the REMOTE_USER header and are experimenting with ways to automate user creation 😁. The django-cas-ng library seems like it’s pretty robust; we were going to look at integrating that but would be curious to know if anyone else has already solved this question.

Best,

Nick

Nicholas Bentley (he/him)
Sr. Systems Engineer
A. James Clark School of Engineering
University of Maryland, College Park

nben...@umd.edu · (301) 405-0582 · Schedule a meeting
 

THE WORLD GOES TO MARYLAND

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/nemo/c024b425-554d-4f29-b326-f37a1ff0ce3en%40list.nist.gov.

[Mathieu Rampant]

Hi everyone,

I am glad to hear this seems to have fixed your issues (at least for most of you).

I added some notes on the wiki about the order of some of those middlewares, so hopefully this won't happen again

If you are using the auditlog feature and the auditlog middleware, that one needs to be added after the impersonate middleware.

It works this way: Impersonate overrides the authenticated user so it needs to be added after the authentication stuff, and Audit log uses the authenticated user as the one making changes, so it needs to be added after Impersonate so it will think it's the impersonated user who is making the changes. If you add the audit log middleware before the impersonate, it will record changes as yourself, not as the user you are authenticated (which is also a legitimate use of it)

Mat

[Chris Price]

Hi, only if you have time, but we can't seem to move ImpersonateMiddleware after ShibbolethRemoteUserMiddleware. It breaks the shibboleth login.

We use a version of https://github.com/Brown-University-Library/django-shibboleth-remoteuser

If you have any time, I would be open to trying any ideas and sharing findings. Thank you!

-Chris

On Friday, February 3, 2023 at 6:29:05 PM UTC-8 mathieu...@gmail.com wrote:

[Mathieu Rampant]

Hi Chris,

I took a very quick look at the library and I am not seeing anything obvious that would interfere.

I was reading your previous message and something caught my eye, you have both ShibbolethRemoteUserMiddleware AND RemoteUserMiddleware. The shibboleth one already extends django's remoteuser middleware, so you should not need that second one.

Can you try removing the NEMO.middleware.RemoteUserAuthenticationMiddleware and seeing if that changes anything?

Next I would suggest trying in the correct order (Shibboleth then Impersonate) and reporting on exactly what kind of error you are getting.

On another note, do you need anything from that library outside of straight up authentication?

If not, you can simply configure Apache to set the remote user variable (which it seems it is set up currently) and use NEMO.middleware.RemoteUserAuthenticationMiddleware in combination with NEMO.views.authentication.RemoteUserAuthenticationBackend as authentication backend and that should be enough.

Another option would be to have Apache rewrite the remote user in a http header and use NEMO.middleware.HTTPHeaderAuthenticationMiddleware with NEMO.views.authentication.RemoteUserAuthenticationBackend.

In both cases, you wouldn't need any third party library or anything else.

Mathieu

[Christopher Robert Price]

Mathieu, amazing, removing NEMO.middleware.RemoteUserAuthenticationMiddleware allowed me to have impersonation after shibboleth. And now our users can create reservations on behalf of other users!

Apologies for the month+ late reply. I really appreciate your time!

-Chris

[Mathieu Rampant]

Hi Chris, 

No problem, glad it's finally working!