Bug 1459619 - Subscription manager should not allow registration by email address
Subscription manager should not allow registration by email address
Status: CLOSED NOTABUG
Product: Candlepin
Classification: Community
Component: candlepin (Show other bugs)
2.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: candlepin-bugs
Katello QA List
:
Depends On:
Blocks: 1431334
  Show dependency treegraph
 
Reported: 2017-06-07 11:22 EDT by Richard Bernleithner
Modified: 2017-09-11 08:01 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-12 16:20:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Bernleithner 2017-06-07 11:22:00 EDT
Description of problem:

subscription manager allows users to register consumer using associated email address. It passes email address as username in Candlepin, which is incorrect.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.register consumer using email address instead of username

ex: subscription-manager register --username 'pdr-it@pdr.net' --password '[REDACTED]'
The system has been registered with ID: 224c8efc-af63-4bef-9606-dfe54e09bf04

2. Look up username for consumer in Candlepin
3.

Actual results:

username in Candlepin is email address pdr-it@pdr.net

Expected results:

username in Candlepin should be pdrit@pdr.net

or

subscription manager should not allow registration via email address in the first place.


Additional info:
Comment 1 Kevin Howell 2017-06-08 10:19:48 EDT
From our perspective, subscription-manager is simply passing the credentials along, and candlepin simply passes the credentials down to the services (in the case of IT-hosted candlepin, down to those services).

If you are talking about the *consumer name* rather than the *username*, then this can be set explicitly with subscription-manager register with --name=$desiredname. (The default consumer name is the hostname).

Please clarify:
 - Are you talking about username or consumer name?
 - What purpose does removing the '-' from the username serve?
Comment 2 Richard Bernleithner 2017-06-08 12:42:15 EDT
(In reply to Kevin Howell from comment #1)
> From our perspective, subscription-manager is simply passing the credentials
> along, and candlepin simply passes the credentials down to the services (in
> the case of IT-hosted candlepin, down to those services).
> 
> If you are talking about the *consumer name* rather than the *username*,
> then this can be set explicitly with subscription-manager register with
> --name=$desiredname. (The default consumer name is the hostname).
> 
> Please clarify:
>  - Are you talking about username or consumer name?
>  - What purpose does removing the '-' from the username serve?

I'm referring to username. Complete details are in associated bug https://bugzilla.redhat.com/show_bug.cgi?id=1431334#c10

The user's email address is pdr-it@pdr.net and their username is pdrit@pdr.net
They were able to register consumer using their email address. This email address was passed onto Candlepin as username, which is incorrect. subscription-manager should either  pass the associated username to username field in Candlepin, or not allow registration via email address.
Comment 3 Barnaby Court 2017-06-12 16:20:36 EDT
Candlepin is a passthrough to the SSO in this case. There is no validation or normalization that can be done in candlepin or subscription-manager that would be useful. The only change I could think of would be an RFE to replace the username specified with the user with the username from the Principal that is returned from the UserServiceAdapter if they are different.
Comment 4 Richard Bernleithner 2017-08-08 11:53:35 EDT
(In reply to Barnaby Court from comment #3)
> Candlepin is a passthrough to the SSO in this case. There is no validation
> or normalization that can be done in candlepin or subscription-manager that
> would be useful. The only change I could think of would be an RFE to replace
> the username specified with the user with the username from the Principal
> that is returned from the UserServiceAdapter if they are different.

What team would this RFE be filed under?

Note You need to log in before you can comment on or make changes to this bug.