BTW, I reread you're last note. The references to AbstractBaseUser were meant for inheritance, meaning that your custom user would inherit all of the same properties and not need to redefine the wheel. You can't inherit from AbstractUser though because you are modifying the username field.
-James On Jan 19, 2015 11:32 PM, "James Schneider" <jrschneide...@gmail.com> wrote: > "A pallet of authentication systems..." > > Yep, you work for an educational entity, as do I. :-D > > You can pursue the LegacyUser model as your custom user model. That would > make your LegacyUser objects the 'local' Django users that have been > referenced. Not sure about the name though, might indicate that there are > CurrentUsers floating about the system. > > Another option is to rename LegacyUser to something like AppUser, and then > add an extra user_type field to the model for filtering/identification. > > Or if you only have one type of user, you probably don't need to worry > about it. > > Keep us in the loop, I'd be interested in a high-level solution. > > -James > On Jan 19, 2015 10:54 PM, "Erik Cederstrand" <erik+li...@cederstrand.dk> > wrote: > >> Hi guys, >> >> Thanks for a lot of useful answers! My schools use a palette of >> authentication systems; regular hashed password check with a hash I have >> access to, LDAP auth and WAYF (a Danish educational SSO solution using >> Shibboleth). Those are the least of my worries right now, though. >> >> I'll have a look at the AbstractBaseUser and friends. Ideally, I'd like >> to expand on my existing LegacyUser model and avoid creating separate >> Django users that shadow the LegacyUser, as I do a lot of synchronization >> of LegacyUsers with the legacy system. I'll see how it goes and post a >> solution if I get that far. >> >> Erik >> >> > Den 19/01/2015 kl. 23.24 skrev James Schneider <jrschneide...@gmail.com >> >: >> > >> > 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. >> >> -- >> 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/81081481-BDD7-4247-BDA9-FBD9DDDF7BA7%40cederstrand.dk >> . >> 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%2BciWWSWk1M_9ZtyzsRKbfSv2goUPtcYF_dPPcdQ99_5YpOw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
