Bug 1214507

Summary: Can't use internal logins with a specified OpenID provider
Product: [Retired] Zanata Reporter: stephane <stephane>
Component: Authentication-OpenIDAssignee: Damian Jansen <djansen>
Status: CLOSED UPSTREAM QA Contact: Zanata-QA Mailling List <zanata-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: camunoz, dchen, lyz, zanata-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-28 23:10:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description stephane 2015-04-22 21:43:11 UTC
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.

Comment 1 Carlos Munoz 2015-04-28 03:49:30 UTC
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.

Comment 2 Carlos Munoz 2015-04-29 23:13:17 UTC
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?

Comment 3 stephane 2015-04-30 19:54:53 UTC
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.

Comment 4 Elizabeth K. Joseph 2015-04-30 19:58:07 UTC
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.

Comment 5 Carlos Munoz 2015-04-30 23:15:24 UTC
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?

Comment 6 Elizabeth K. Joseph 2015-05-01 00:40:49 UTC
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.

Comment 7 Ding-Yi Chen 2015-05-06 00:47:25 UTC
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?

Comment 8 Zanata Migrator 2015-07-28 23:10:23 UTC
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-45