For a pure authentication scenario where permission checks never go beyond user.is_authenticated(), that's probably true. If all the OP is doing is displaying data, they may be able to get away with manually associating the campus and user within the session after, and displaying data based on those session keys. Basically you would end up with a boolean layer of protection for each resource, because all you know is the validated username and campus pair. That may work just fine.
However, if you need any sort of authorization (permission checking) within the app using Django's permission system, you'll probably need a local copy of the user using a custom user model in the database to perform checks against. It sounds like the OP may need that. Otherwise you are also looking at rolling a custom authorization backend as well. If they are LDAP services, you can look at django-ldap, which works quite nicely, including group membership restrictions. It also does the overriding of the authentication backend for you. Not sure how it would work with multiple LDAP servers for various campuses though. That would need some research. TL;DR; There are a lot of ways to slice this problem, and a primary strategy driver will be the available authentication backends at each campus. Hopefully they are all the same. -James On Mon, Jan 19, 2015 at 2:06 PM, Stephen J. Butler <stephen.but...@gmail.com > wrote: > Shibboleth 2.0 lets you setup a discovery service (or portal would > perhaps be a better term) letting the user select which ID Provider > (IdP) they will authenticate to. All you have to do on the Service > Provider (SP) side is specify the discovery URL and what IdPs you > allow. Nothing needs to be done in your Django app except support > Shibboleth. > > Of course, this is all predicated on there being a competent > Shibboleth setup at your institutions. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAD4ANxVp4C2QcxAcY6Xui1bc6Z-hcV--sfOSEy%3DmcaW_w%2BpGHw%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXW3NoDaTTpaiL2qtD69vkjmSEFfGSeM9-Dk00YMAG6NQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
