using a special attribute for groups support

[Theo Chatzimichos]

Hello,

I am one of the infra guys of the Gentoo distribution. For groups support, we use a special multi-value attribute called gentooACL that has contents like $server.gentoo.org, ldapadmin.group, developer.group. The reason is that it covers a few cases that cannot be expressed with ou=groups, like:

- Two users, A, B.
- Two servers, X, Y.
- Two groups, G, H.

1. You want user A to be in group G on X, and group H on Y.
2. You want user B to be in group H on X, and group G on Y.

It's impossible with ou=groups. You have to end up subclassing the groups X.G, X.H, Y.G, Y.H, and granting membership to those.

Another case that cannot be expressed with ou=groups is:

nss_base_passwd ou=users,dc=gentoo,dc=org?sub?|(gentooACL=server1.gentoo.org)(gentooACL=server2.gentoo.org)

As far as I investigated, django-auth-ldap does not support such a case for groups (correct me if I'm wrong please).

I would like to extend the group support in django-auth-ldap, by implementing a new configuration option like AUTH_LDAP_GROUP_ATTRIBUTE="gentooACL", or a new LDAPGroupType AUTH_LDAP_GROUP_TYPE="Attribute(name_attr="gentooACL"), so that we can do the following:
AUTH_LDAP_USER_FLAGS_BY_GROUP = { "is_active": "active.group", ...  }
AUTH_LDAP_PROFILE_FLAGS_BY_GROUP = { "is_developer": "developer.group", ...  }

Would you be willing to accept such a functionality? If so, any requirements on the implementation details?

Thanks in advance,
Theo

[Peter Sagerson]

Hi Theo,

Thanks for checking in. I'm not certain I understand all of the details of your scenario, but I'm pretty sure there's a good answer for it. The first thing I would ask is how important it is to integrate your authorization scheme into Django's groups and permissions. For example, does it make more sense to write a custom authorization backend[1] that makes its decisions directly from the values in user.ldap_user.attrs? I find that I frequently write custom Django authorization backends, since the default one is primarily designed for authorizing access to models in the admin interface, and I often need something more domain-specific. As for populating fields on user and profile instances, the easiest way is to connect to a pair of signals that exist just for that purpose.[2]

If you do need to fully integrate your notion of groups with Django's, then know that defining new group types is absolutely encouraged. The base class is django_auth_ldap.config.LDAPGroupType and while the subclassing notes didn't make it into the documentation, the source is carefully documented (plus the built-in examples). At present, the primitive group method to implement is defined to return a set of LDAP search results, which isn't exactly consistent with your scenario. On the other hand, I don't believe we rely heavily on that assumption, so we may be able to broaden the definition of the API. There would be no particular need to incorporate a custom group type into the main project, as it can just be part of your code base. Although if you are able to design something with sufficient generality that it would be useful to others, I expect we can roll it in.

Let me know if that's helpful or if there's anything else I can do.

Thanks,
Peter


[1] https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#handling-authorization-in-custom-backends
[2] http://pythonhosted.org/django-auth-ldap/users.html#custom-field-population

> --
> You received this message because you are subscribed to the Google Groups "django-auth-ldap" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-auth-ld...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Theo Chatzimichos]

Hello Peter,

regarding the custom auth backend you mentioned, the truth is that I already
wrote one as part of GSoC two years ago, and another student is going to
expand it this year (if he gets accepted, the results will be published this
month). Looking at django-auth-ldap though I realized that it would be less
effort to contribute to that and expand it for our groups usecase, instead of
duplicating a lot of stuff (which I already did).

I understand that my patch has to be as general as possible, and I believe
that there are more people out there using the same design for LDAP groups, so
I hope it would be useful. I checked the code, it is sufficiently documented and
clean enough, I'll let you know if I stumble upon any issues. Thanks for your
feedback.

Theo

[Peter Sagerson]

Sounds good. Just to be clear, django.contrib.auth allows multiple auth backends, so I wasn't suggesting a completely new LDAP backend. I was suggesting using django-auth-ldap for authentication and installing a second, domain-specific backend that only makes authorization decisions (e.g. has_perm()), based on the authenticated user's attributes. This is what I commonly do. A backend that is only concerned with authorization is pretty trivial to write. For example, I have one project which primarily authorizes views rather than models; django-auth-ldap populates the User objects and the second backend rejects requests if the logged-in user does not meet the view's criteria.

Of course, if you're already invested in Django's default model-oriented permissions design, then a custom group type is probably the cleanest point of integration.

[Di majo]

MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
LOAN DEAL
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
IPIP/DTC
SLBC PROVIDER
CREDIT CARD TOP UP
DUMPS/ PINS
SEPA TRANSFER
WIRE TRANSFER
BITCOIN TOP UP
GLOBALPAY INC US
SKRILL USA
UNIONPAY RECEIVER

Thanks.


NOTE; ONLY SERIOUS / RELIABLE RECEIVERS CAN CONTACT.

DM ME ON WHATSAPP
+44 7529 555638