Bug 1214507
Summary: | Can't use internal logins with a specified OpenID provider | ||
---|---|---|---|
Product: | [Retired] Zanata | Reporter: | stephane <stephane> |
Component: | Authentication-OpenID | Assignee: | Damian Jansen <djansen> |
Status: | CLOSED UPSTREAM | QA Contact: | Zanata-QA Mailling List <zanata-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | 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
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 |