Any future "user" tables should include necessary information to uniquely identify users of different sources.

[MikeNeilson]

Is your feature request related to a problem? Please describe.
In considering future user management that isn't database accounts and the varied nature of OpenDCS users we intend to support multiple authentication and authorization, likely at the same time through the user of various "identity providers"

Describe the solution you'd like

The table of users, groups, policies, etc, should have sufficient information to tie to the identity provider.

For a list of users this is simply

(provider, subject)

In the specific case of OpenID Connect provider would be the issuer and subject would be the sub from the claim.

In the case of LDAP, the provider is a bit more squishy though. Either the URL or the Distinguished name would work.

Other values, like a simple username would need to have a mechanism of mapping. This is often single variable or simple templating. JWT claims have a really convient preferred_username, email, and other standard values. LDAP has... several standard values.

That is to say, OpenDCS should store it's users and a way that allows multiple providers and also easily linking to user permissions of the system.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
This is basic modernization. All of the current implementation expect database users as that was standard practice. The OpenDCS REST_API should be focused on enforcing the "newer" standard of n-tier architecture and leaving the user management configurable.

(That said one of the implementations could easily be the database accounts, but I think we should develop first for "external" identity management.)