Refactor preauth provider configuration structure
Closed this issue · 6 comments
It seems like the preauth provider is really a sub-component of the user identity provider and should therefore be registered as an additional API sub-object on that provider. This way, configuring the identity provider in the webauthn_config.json would implicitly set the appropriate preauth provider, and the sysadmin would be unable to configure a nonsensical combination of providers.
One reason to consider leaving this as-is is that, if we ever want to support more than one authentication method on the same webauthn instance (which may be more likely after #9), then we'd want to configure a preauth method that let the user select (or read some configuration about which method(s) to implement for which services, or something).
I worry that we are allowing too much programming-like variability in the config file. Perhaps we should really have a higher level notion of supported configurations as Python modules that import and compose a particular set of providers (allowing code reuse where we'd want). The sysadmin should only be choosing between the available compositions we've tested and plan to support...
We could just put together some example templates. That would also help
people know, for example, which options go with which OAuth providers
(things like scope, discovery URL, and some behavioral options are
different for different providers).
-- Laura
On 2/5/16 1:29 PM, karlcz wrote:
I worry that we are allowing too much programming-like variability in
the config file. Perhaps we should really have a higher level notion
of supported configurations as Python modules that import and compose
a particular set of providers (allowing code reuse where we'd want).
The sysadmin should only be choosing between the available
compositions we've tested and plan to support...—
Reply to this email directly or view it on GitHub
#7 (comment)
Bug from MailScannerWebBug
@ljpearlman I think we sort of did this issue or at least voided it with the current globus_auth branch, right?
@karlcz who should this issued be assigned to? @karlcz or @ljpearlman ?
I think we can just close this issue now. We've gone in a different direction with providers, documentation, and our own internal provisioning and configs so there are lots of examples floating around and no clear action to take here...