I am, for example, accessing "https://<server>:8443/candlepin/products". You are correct it does not appear that putting something in this form will succeed. However, I guess I don't know what user(s) I might even try to use.

I don't know if it matters but this Candlepin installation is part of Katello/Satellite. Maybe that even goes without saying I am still trying to understand the relationships between the various components.

I would guess that by accessing it as I did above I am going straight to the Candlepin application deployed to Tomcat. I'm sure the Katello piece is using a certificate which Candlepin is configured to trust.

I'm also curious how the authN piece works since Tomcat is configured with "want" which, from what I understand will still allow access to the application while passing a null certificate. Is Candlepin doing its own validation of the cert after Tomcat does its part?

On Mon, Feb 15, 2016 at 2:17 PM, Alex Wood <awood@redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> I am not a developer so don't fully understand all of the
> configuration points of apps and Tomcat. I am trying to understand
> the authN/authZ flow for candlepin. I don't understand why I am
> prompted for a username and password when accessing
> http[s]://<server>:<port>/candlepin/<something>. The only places I
> know to look are web.xml and candlepin.conf. The web.xml only
> specifies CLIENT-CERT authentication but tomcat is configured only
> for "clientAuth=want" which shouldn't be mandatory. candlepin.conf
> has:
>
> candlepin.auth.basic.enable = false candlepin.auth.trusted.enable =
> false candlepin.enable_cert_v3=true candlepin.auth.oauth.enable =
> true
>
> This seems to show that basic (username/password) authentication
> is disabled. I'm assuming that a specification of some other form
> (cert) of authentication must fall back to basic if it fails. Where
> is that configured and where to the users and roles come from?
>
> Thanks, -LJK

Lesley,

That's very strange.  Looking at the code, if
candlepin.auth.basic.enable is set to false, Candlepin shouldn't even
try to use basic auth.

Can you tell me a little more about which API endpoint you are hitting
and also how you are accessing it?

I.e. Whether you are accessing /candlepin/owners/{some_org_name}/info
in a browser or using curl.  Accessing methods like that when you are
unauthorized (as you would be when basic auth is disabled and no
client certificate is provided), Candlepin will return a 401
NotAuthorized and a header 'WWW-Authenticate: Basic realm=candlepin'.
 I believe many browsers will then interpret this to mean "create a
basic auth dialog so the user can resubmit" (at least Firefox 43 does).

In this case, however, putting anything in that dialog box would still
not work.

We probably shouldn't be putting that WWW-Authenticate header in the
response when basic auth is disabled, but that header is getting added
deep within the library we use for JAX-RS.  If you want to file a bug,
we will certainly investigate it.
- -----------------
Regards,
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWwjI3AAoJECmNHVSZd5sYRpoP/2teAl9E3PqIt2/UfHEkpmzK
wx/LXW0fYiP2LPSWF41hUv04UGpKo3qT9wt8mNIoRHCWfLZ31RTzV6VMuJQsmznX
GAdRKWLuV2efFG8iRzL5RYpmCepzMYBeRNN57LwpsNkt4935rT56Y/D1PHUWF09M
x+1myRIuvD3nxNgxuIYlyFH47Yx3nQfq1+bZVRIXoEosgVgxNhaZP+ckcowJNlbL
NDLmTLdDFkH5CzCqOcT0Pwv/w93FkcCrr4RbmIeABFUXDOWge3yVLz6UfUNC+94o
L6G7D1XPfbdRiGEQszJ8/m38++UPcvAnJVBM09dzUIp7uB5FP5qq7BL+9REad5Ge
71XfFU2OKAwYGUbGtgL3eVgT4hXErwupPpmsPc8WXrvRnnR9i1G8N3CmhnTWEhEs
YUB55p3B+CD6h2mJOCmrWMTY+XWFs2Rmh6gilcrQTZ5mJ3rncIvLjxAyty/RvKti
TXiop0DFcleF4qMjp7H2WQSoQStLJK4u/75IFxPi/6iPunEOItJjOYnSbGjcUJML
D29zXf3NG3zesaoNOfRrpMSDhUFkdJfq0gBy2rM0aoc86rPhLyBBTM/RfgLKB9sf
+FA9wSlyhmM9+1VdB8hXkkBNULH7Dz3M6EHjGVs7c2xxYJ0OXHrxZjgOL8q1oZ2X
cYY6qYIN+YzOSrW0BGqd
=24HR
-----END PGP SIGNATURE-----
_______________________________________________
candlepin mailing list
candlepin@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/candlepin@lists.fedorahosted.org