> John Rouillard added the comment:
>
>
> This goes back to my comment about needing a configurable stack a la
> PAM. The config for PAMish support would be reasonable to add to the
> global config. It probably would need something like:
>
>   www_authn_stack =  recaptcha HIBP otp OIDC ldap local
>   rest_authn_stack = jwt ldap local
>   xmlrpc_authn_stack = jwt ldap local
>
> with a registration function like:
>
>   register_authn('otp', OtpLoginAction)
>   register_authn('ldap', LdapLoginAction)
>   register_authn('HIBP', HIBPLoginAction)
>
> to be called from the extension's init() function.

That sounds pretty reasonable. But I'm not entirely sure I can properly evaluate
the design or give any advice in this case.

> >and check the roles associated with LDAP groups.
>
> Do you mean there would be a group in ldap called "roundup_provisional
> user" and membership in that group would add the "Provisional User"
> role to the user to start? I assume on every login the Roles would be
> recreated so that removal from the "roundup_provisional user" group
> would be reflected in Roundup?

Almost like that. I think a mapping section or perhaps a mapping file is
needed. Some kind of dictionary. This dictionary can contain all the Roundup
roles, some of them, or none at all. If it does not contain roles, authorization
is not performed, only authentication. Users get roles from
NEW_WEB_USER_ROLES. If the dictionary contains roles mapped to LDAP groups,
membership will be checked and roles would be applied to the user. If User role
does not mapped to LDAP group, any new user get roles from NEW_WEB_USER_ROLES
without checking membership. If LDAP authorization is used, group membership
must of course be checked on every login.

> Also how would this work for multiple trackers working from the same
> LDAP server where a user might have different roles on different
> trackers? They could add groups "roundup1_admin", "roundup2_admin"
> etc. I guess.

Something like that. I think in real world it would something like
"cn=admins,ou=games,ou=groups,o=acme" and "cn=admins,ou=webapp,ou=groups,o=acme".
The same principle applies to developers, managers, customers and so on.

> >This is preferable,
>
> But is more complex and I am not sure what the answer should look
> like.

In theory, DIT can be very complex and use custom schemes. When I selected the
attributes that would be supported in my extension, I selected only the
attributes contained in the "orgPerson", "inetOrgPerson", "nsOrgPerson" and
"nsPerson" classes. These classes are most likely used for user entries in most
LDAP installations. I think we should follow the same principle regarding
roles. I believe that it is necessary to provide minimum reasonable support for
LDAP authorization.

> The only thing that comes to mind is:
>
>   [ldap-role-mapping]
>   admin = roundup1_admin
>   provisional user = roundup1_provisional_user
>   ....
>
> so we have a section specifically set as a dictionary. But I'm not
> happy about it. INI files are notoriously bad for this sort of stuff.

Perhaps it's better to use a mapping file rather than a mapping section?

> Then again I have been getting Roundup running with Kubernetes recently
> and YAML is a PITA as well.

TOML is probably the best choice. But native support for TOML parsing in Python
is available only from version 3.11.

> As you note, this LDAP setup doesn't handle complex LDAP trees, but
> support for a fallback to local db (enabled via a config.ini
> parameter) should be there.

Yes, I now agree that it should be possible to go back to using a database. I
was thinking about an internal tracker rather than mixed use with an external
users. This is my mistake.

> Thoughts?

I'm not sure I can help with the design of global authentication. This is very
interesting, but my skills are not enough here. I can only say that if the need
to make a new design is obvious, then it should be done =)