enervee / django-freeipa-auth

Django FreeIPA Auth is a backend authentication app with a simple server failover solution which can be included in a project’s authentication backends. This app communicates with a specified FreeIPA host server and authenticates a user to the django app upon successful freeIPA login.
BSD 3-Clause "New" or "Revised" License
6 stars 1 forks source link

User permissions #5

Open 88Ocelot opened 2 years ago

88Ocelot commented 2 years ago

When i log in with my credentials user profile created with flag is_staff, even if im a member of both superuser and ipausers

SUPER_USER_GROUP = os.environ.get("SUPER_USER_GROUP", "superuser")
STAFF_USER_GROUP = os.environ.get("STAFF_USER_GROUP", "ipausers")
FREEIPA_AUTH_USER_FLAGS_BY_GROUP = {"is_staff": [STAFF_USER_GROUP], "is_superuser": [SUPER_USER_GROUP]}

WARNING:root:user_session.groups=['superuser', 'developers_prod', 'gitlab', 'developers', 'jenkins', 'ipausers']

88Ocelot commented 2 years ago

Sorry didnt notice that it was removed intentionally... Why did you removed that feature? Any plans to get it back?

kris-anderson commented 2 years ago

@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.

88Ocelot commented 2 years ago

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.

kris-anderson commented 2 years ago

@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 commented 2 years ago

@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?

Yep, somewhat like that

kris-anderson commented 2 years ago

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.

88Ocelot commented 2 years ago

@kris-anderson Created a pull request with this feature #9

nikigalvan commented 2 months ago

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!