Allow gathering token ids from multiple sources (authfile,LDAP,etc.)

[mark-casey]

I'd like to attempt a patch to allow for using more than one source for token ids so that things don't go bad if LDAP goes unavailable.

I'm still mulling over methodologies and the current logic and hope to post a couple of brief ideas in the next couple of days to make sure I'm not heading down a path that wouldn't be likely to get merged in.

So this issue is for tracking that...

Thank you, Mark

[mark-casey]

I'd propose that the way this should work is to add an option called something like multi_method or multi_source.

If a user were to specify multiple options (ldap, authfile, etc.) and did not include the multi_source option, they would get an error (and on the inverse case, using the multi option with only one source may be able to give a warning).

Values for the multi option would be "any" and "all" (or similar names). One means "it is okay if a source has an error", the other means "if any source has a problem, give up". (I haven't actually thought of a use-case for the latter, "all" option, and may abandon that part).

Any concerns/suggestions/questions?

[mark-casey]

Source precedence is probably possible too, but I was planning on token IDs from all sources going into the same pool.

edit: on second thought, precedence may not ever be important since it isn't really possible for one source to provide a token ID and another source to say "no" to that token ID. Sort of always cumulative except perhaps if you knew there were different tokens in different sources and wanted to match/use a particular one.

[klali]

Hello,

I have a couple of worries with a feature like this:

Added complexity by making the feature to dynamic and configurable. It'd need tests to make sure it isn't broken at a later time.

My thinking around something like this would be that you add everything you want authorized to your ldap directory and have something for fallback locally authorized? Are there cases where this eases administration compared to just distributing the local config file?

As a slightly separate thought: Maybe our backend sources for authorization should be abstracted and pluggable so you could substitute ldap/file with your own as needed?

/klas

[mark-casey]

I also see this working as you have described. To me, the key benefit is that I do not have to hard-code a large number of tokens into the local config for distribution (I can let LDAP hold them), but instead maintain a config with only a small number of backup user token(s) for in the event of LDAP failure. There is certainly some maintenance penalty to keep the config up to date with the backup tokens on each host, but it is much less maintenance (and more dynamic) than distributing a config that has all users' tokens in it.

I definitely see the concern for complexity.

I like your last thought... Perhaps a "authorized_token_mappings_command" that models what has been done in some other projects? (this blog has a couple posts on OpenSSH's version of the idea 1. http://blather.michaelwlucas.com/archives/1562, which includes in it a link to the older 2. http://blather.michaelwlucas.com/archives/1470)

That could keep things fairly simple within the pam module by only having the options: file, script, or both. ...Distribute a sample script or two, and let folks go to town.

Mark

[ahilsend]

I love the idea of being able to specify a command, similar to ssh' AuthorizedKeysCommand.

Is there any chance this could be implemented?