When a providerURL is specified for the zanata.openid security domain, users with internal accounts cannot log in via the web UI. It would be nice to be able to have an option to use internal accounts in addition to OpenID if desired.
This should be possible by displaying a specific UI for the "custom open id + internal" authentication setup. Our current UI for this setup doesn't show the internal login option, simply redirects directly to the Open Id provider.
Stephane, enabling internal authentication usually also means enabling the ability to sign up for the system with an internal account (no open id). Is this acceptable?
Not really - I think we would want to use internal logins only for admin purposes and force translators signing up to use OpenID. So if we were going down that road, we'd have prebaked internal accounts and maybe a 'hidden' login page for them, plus the usual OpenID sign on.
Yeah, we run an openid server so we don't have to get into the messy business of managing full account rosters for every service we run, so we really don't want to have regular contributors directly creating non-openid accounts here.
Ok, just clarifying your needs. So it sounds like what we want here is a way to allow existing OpenId users to create alternative internal credentials (username/password) to log in without enabling full user registration. Does that sound about right?
That's correct. Likely it's mostly going to be for admins and any "bot" users that we need to give higher privileges to since we want to define their usernames in the text-based config, but still use openid to log in.
For "bot" user, it would be best to use the client to perform the tasks. In terms of human admins, the reason of using internal authentication I can think of is when Open ID failed, are there any other consideration?
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-45