search

snok / django-auth-adfs

A Django authentication backend for Microsoft ADFS and AzureAD
http://django-auth-adfs.readthedocs.io/
BSD 2-Clause "Simplified" License
270 stars 98 forks source link

[Question] Multiple applications sharing one auth server with django-auth-adfs #269

Closed newbro closed 1 year ago

newbro commented 1 year ago

First of all, thank you for the great work on this package.

Currently, we have many Django applications deployed, each with django-auth-adfs configured. They all use the same application group in the AD server, so a single client ID is shared with a different callback URL assigned for each application.

We are not sure if this is the best approach but it has served us well. However, launching a new app would require adding a new callback URL in the application group which seems counter-intuitive. So we are exploring whether we can create a central app responsible for handling auth requests made by other applications. We have limited knowledge on this matter, but would this be similar to creating our OAuth2/OpenID server? Although how that would tie in with django-auth-adfs remains to be seen.

If anyone can offer any insights or advice that would be great.

JonasKs commented 1 year ago

Hello!

Disclaimer: I have not implemented traefik forward auth personally, so I am not sure whether this works with MVC using sessions, or only with APIs using tokens etc.

So we are exploring whether we can create a central app responsible for handling auth requests made by other applications

I would probably use nginx or traefik's forward-auth-plugin for this. It's a pretty simple idea where you have a gateway, and only the gateway can do requests to your backend applications (so you'd have to lock down the network traffic to your django backends very securely). In order to do a request to the Django backend, you have to send traffic through traefik. If you are not authenticated, traefik sends the request to an authentication backend (which can be a Django application), and if the auth-backend responds with a 200 OK, the request is forwarded to the app-backend. If the auth-backend responds with anything else (e.g. 403), the request is never sent to the app-backend.

An alternative, if you want an enterprise product is Kong, implement Azure AD authentication in Kong (without django-auth-adfs at all), and if auth is OK, the request is passed on to the app-backend.

JonasKs commented 1 year ago

On a side note: I think these setups becomes more complicated than just having multiple callbacks. Could be argued that each application should've had its own client ID too, but I understand why that's not always feasible.