Roundup Tracker - Issues

Message7927

Author rouilj
Recipients asavchuk, rouilj
Date 2023-12-27.20:01:05
Message-id <1703707265.38.0.315574902751.issue2551307@roundup.psfhosted.org>
In-reply-to
Hi Anton:

> you are proposing to use an authentication plugin system as
> something like the current Roundup extensions? That is, in the
> tracker home there will be a certain directory (e.g. 'auth') in
> which the auth plugins will be located?

I was going to put the auth extension in the extensions directory.
The difference would be that the init() function at the end of the
extension calls:

   instance.registerAuth('name', function, flow=None priority=100)

I haven't decided if the second arg is a 'function' or a class similar
to how registerAction works. If it's a class it should inherit from a
new authNbase (or some other name) class. I'm leaning toward the class
so it can have methods to return "passed", "failed", "not authorized"
....

Also I realized my earlier example shouldn't be Actions. Actions are
web interface thingies.

The 'flow' parameter would be used to define the stack where the auth
method should be applied. Maybe we can reuse the tokens from db.tx_Source.
For example to add LDAP to all WEB auths:

   instance.registerAuth('name', LdapLookup,
                         flow=( "web", "rest", "xmlrpc" ), priority=50)

the priority 50 would cause it to be run before the native stack of:

  WEB cookie priority - if enabled
  REMOTE_USER header - if enabled
  username/password against native db
  jwt - if enabled
  session lookup fallback

As part of implementing this, each of the 5 in the native stack should
be rewritten to be pre-existing registered auths. They could even have
predefined priorities (90, 100, 110...)  so that you could slot your
auth method between them.

For email you have the stack:

  from address lookup
  gpg signature validation

and can add:

   instance.registerAuth('name', SmimeValidate, flow=( "email",))

would allow you to look at the smime envelope for authentication.

I suspect the authenticator would have to return a tuple of:

  (finding, 'method')

where method could be used as db.tx_Source if provided. Finding would be
"passed"/"failed"/"not authorized"... and be used by the authentication loop to
determine if it rejects the user, allows the user in, needs to go to the
next authenticator.

> In this case, the solution to support LDAP authentication would be to provide
> out-of-the-box support for only those roles that are provided by default for that
> schema.

Correct, new_web_user_roles as defined in config.ini.

> And if the tracker needs to be configured to add additional roles, the LDAP
> plugin should also be customized.

Yeah probably.

> Another idea is that the authenticator could get all the roles and then iterate
> through them to check the user's membership in each of them. But we need to
> somehow define their order.

Roles are (maybe) order independent. Agent,User == User,Agent. Hmm, now that I have
said (well typed) that, I am not sure. The role order may be preserved
in the generated permission rules. If there is a negative permission (deny)
in the sequence, then the roles are not commutative.

> We can get it from a mapping file, for example.

We can create a simple mapping (and ordering) in extensions/config.ini. E.G.

  [ldap]
  role_order = Admin(roundup_admin), Agent(roundup_agent), User(Roundup_user:Roundup_user2), Anonymous(Anon)

The ldap code can then check the roundup_admin group in LDAP and see if the user is a
member. If so, append the role Admin to the new role list. If a user is a member of
roundup_agent and Roundup_user (or Roundup_user2) LDAP groups, the role will be
'Agent, User' and not 'User, Agent'.

> Alternatively, perhaps the order (and even the mapping of LDAP groups) could be
> set in the schema.py file and stored in the database.

That's another possibility, but it would be a departure from existing practice.
I prefer to keep things in the DB that are:

  1) user-facing
  2) need updating for business rules/workflow.

This is an admin setting, so not user-facing. Additional Roles can be added. But
defining and implementing them requires access to the underlying tracker which means
access to config.ini.

Quips, comments, evasions, questions or answers?
History
Date User Action Args
2023-12-27 20:01:05rouiljsetmessageid: <1703707265.38.0.315574902751.issue2551307@roundup.psfhosted.org>
2023-12-27 20:01:05rouiljsetrecipients: + rouilj, asavchuk
2023-12-27 20:01:05rouiljlinkissue2551307 messages
2023-12-27 20:01:05rouiljcreate