Open 88Ocelot opened 2 years ago
Sorry didnt notice that it was removed intentionally... Why did you removed that feature? Any plans to get it back?
@88Ocelot We are open to ways for this to work both ways.
For us, we're trying to move away from assigning users "superuser" permissions within Django. Any user that has superuser permissions also has the ability to create users, and they can therefor create back-door accounts to bypass FreeIPA as our authentication provider.
For us, we want everyone to be assigned to a group in FreeIPA, and that group is then added as a Django group where their permissions are defined within Django. No one is assigned the superuser permission with what we're trying to do.
That may not be true for you and your org though, so if there's a way to make this work for both our use cases we could consider it.
Thank you for clarification! I understand your point, but mind you that config was some what flexible, you had control wether user have full access to admin panel or can just authenticate and see some stuff on frontend part of the app. Maybe returning config for is_stuff
is good middle point between security and flexibility?
If you okay with that, i can do the pull request for that feature.
@88Ocelot Are you saying for you use case, you would have FreeIPA manage permissions for both Django Admin users, and for users accessing the front end of the application? In that case, you'd want to be able to assign some FreeIPA groups to Django's is_staff
and some FreeIPA groups not assigned to Django's is_staff
?
@88Ocelot Are you saying for you use case, you would have FreeIPA manage permissions for both Django Admin users, and for users accessing the front end of the application? In that case, you'd want to be able to assign some FreeIPA groups to Django's
is_staff
and some FreeIPA groups not assigned to Django'sis_staff
?
Yep, somewhat like that
If you have thoughts on how to do this we're open to it.
For us, we want all users that authenticate with FreeIPA to be assigned is_staff
, and not to be given superuser
permissions. If we can make that configurable though, so that it can support other use cases like yours, I think that would be a good thing. Not everyone is going to use this package the same way we do right now.
@kris-anderson Created a pull request with this feature #9
Hi @kris-anderson! Are you planning on keeping the setting of is_staff
to True
? For us that removed some of our desired flexibility and we had to work around it. I also found the placement of the setting to is_staff
inside of the update_user_groups
function confusing, as it addresses a user attribute and the function doesn't do what the doc string says. So even if I set FREEIPA_AUTH_ALWAYS_UPDATE_USER
to False
this behavior is not affected. Thanks in advance!
When i log in with my credentials user profile created with flag
is_staff
, even if im a member of bothsuperuser
andipausers
WARNING:root:user_session.groups=['superuser', 'developers_prod', 'gitlab', 'developers', 'jenkins', 'ipausers']