All;
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
I don't necessarily want to enable authentication. I am working through a general security guide for Tomcat and I am trying to understand how Candlepin/Gutterball work so that I can make educated decisions of what things I can and cannot change. Right now I'm trying to understand why Candlepin will prompt me for a username/password when basic authentication doesn't seem to be enabled.
-LJK
On Mon, Feb 15, 2016 at 1:47 PM, Stas Fomin stas-fomin@yandex.ru wrote:
If you want to use basic auth, you can create first admin user (with password "admin") like "GET /candlepin/admin/init"
Also, you can use candlepin without any users and disabled basic auth, using OAuth authorization just adding line like that to candlepin.conf candlepin.auth.oauth.consumer.domainname.secret=XXXXXXXXXXX
self.candlepin_session = requests_oauthlib.OAuth1Session(self.settings.candlepin_oauth_key, #domainname
client_secret=self.settings.candlepin_secret) #XXXXXXXXXXX
As far, as I understand, tomcat only checks TLS layer, against candlepin public certificate (stored for tomcat in /etc/candlepin/certs/keystore)
Sincerely, Stas Fomin.15.02.2016, 18:11, "Lesley Kimmel" lesley.j.kimmel@gmail.com:
All;
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 ,
candlepin mailing list candlepin@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/candlepin@lists.fedorahosted.org
Sincerely, Stas Fomin
https://ru.linkedin.com/in/stasfomin https://moikrug.ru/belonesox
candlepin mailing list candlepin@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/candlepin@lists.fedorahosted.org
-----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
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
On 02/15/2016 03:26 PM, Lesley Kimmel wrote:
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? ________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/candlepin@lists.fedorahosted.org
With a Katello installation, Candlepin is generally set up to only use client certificate authentication and OAuth. Katello uses OAuth while registered consumers use certificate authentication. If you want to enable basic authentication and create a user, I can provide instructions on that. The users themselves are in Candlepin's postgresql database under cp_user in a standalone Candlepin instance, but I seem to recall that Katello may implement its own user interface and integrate that with Candlepin.
To explain the relationships, Katello runs over top of Candlepin and provides its own REST API. Many of the calls are forwarded directly on to Candlepin, but in some cases Katello intercepts the calls and performs additional work. Think of Candlepin as just an engine. Katello is the car portion. You can interact directly with the engine of course, but it's tedious.
To answer your question about Tomcat and the null certificate, you are correct in suspecting that Candlepin does it's own certificate validation after Tomcat. We do this to allow multiple forms of authentication and we also need some information out of the certificate (namely the CN). ------------- Regards, Alex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
To answer your question about Tomcat and the null certificate, you are correct in suspecting that Candlepin does it's own certificate validation after Tomcat. We do this to allow multiple forms of authentication and we also need some information out of the certificate (namely the CN).
Having looked at the code, let me amend that a little. If a client cert is provided, Tomcat will verify that it is signed by the CA listed in the Tomcat connector's truststore. If so (or if no cert is provided), the request moves to Candlepin. Candlepin will examine the request and perform its own authentication steps. In the case of client certificate authentication, Candlepin introspects the certificate and grabs the CN so we know exactly who we are talking to. - -------------- Regards, Alex
Can you explain a little how Candlepin generates certificates for clients? Does it have a self-signed CA certificate that it uses to sign these client certs? Would it be possible (albeit inconvenient) to use 3rd part signed certs for these client certs?
On Mon, Feb 15, 2016 at 2:52 PM, Alex Wood awood@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
To answer your question about Tomcat and the null certificate, you are correct in suspecting that Candlepin does it's own certificate validation after Tomcat. We do this to allow multiple forms of authentication and we also need some information out of the certificate (namely the CN).
Having looked at the code, let me amend that a little. If a client cert is provided, Tomcat will verify that it is signed by the CA listed in the Tomcat connector's truststore. If so (or if no cert is provided), the request moves to Candlepin. Candlepin will examine the request and perform its own authentication steps. In the case of client certificate authentication, Candlepin introspects the certificate and grabs the CN so we know exactly who we are talking to.
Regards, Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJWwjqEAAoJECmNHVSZd5sYAdkQAMPfwS9NfuZ1CTdfSkkXA3O4 7xtzf+S4NR7vniUggyNeXkyCzQ9Jk/GEGnB5RuXq4DhskLK2Mx19v97+G2uQwktu YKiY2hgmIFdav4brIY7IZMX2PoP4+JFDhLmp7Baducd1kRNfSbvGPESz9TYfc7wZ FWZ6UdAthRo0C22EZVqEGYLJHdvH6p1Fie8WlvxTJSCmGbXqNQqVcoq+UCrTaKgk tzuqNEn2A7MTAREuqkZ66dXK75ab+cvPXTZ3rwbnnr1NBzzUf00bjsi6frGClHku 2Vp28RS1G/Nd4Fgi+oHeJK/bWRduwD4I1xuEg5XDW2ewcwPODHLUUyXM2XKnOpbP +lsAhrYGjFYHmCxRDIBqYi0XV5vSJmW/VrWjNOo8Dx2c2IceUnxOLId6EwpjbfIK s4khRES3MZQkmIIBNvK8lU4zJttC2bVK0iQKpvDy83pm8NlvotF2fv8mNWXmLPaV G6nUN7ryIy51qK3wxaunzG23jgPXNZSPzX++HnJl9BDlKtlqoffvoMnX1k4QOwaf qOFusn+sOzQ3ETqwyaDy258mHzo+bZjcxxPIz/0bu5DzpulyPshg54cr9lpk1Wiu cyZWsJFfkibVYaIElyqyXw4MF2mjbrho29WY0uZ3b64YfBFimOS/OxG9veKTs+g9 9mr9MXHqF1I4EgCvWH0n =R/tw -----END PGP SIGNATURE----- _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/candlepin@lists.fedorahosted.org
On 02/16/2016 08:39 AM, Lesley Kimmel wrote:
Can you explain a little how Candlepin generates certificates for clients? Does it have a self-signed CA certificate that it uses to sign these client certs? Would it be possible (albeit inconvenient) to use 3rd part signed certs for these client certs?
Yes, client certificates are signed by a self-signed CA certificate that is created when Katello is installed.
Candlepin issues two types of certificates: identity certificates and entitlement certificates. Identity certificates are issued when a system registers to Candlepin and are henceforth used when the client communicates with Candlepin. Entitlement certificates are issued by Candlepin when a subscription is used and are presented to the content delivery network when attempting to install packages from repositories in /etc/yum.repos.d/redhat.repo.
As for whether it would be possible to use third-party signed certificates... That is a good question. If it is possible, it's going to be very difficult. For one, Candlepin is designed to send the identity certificate and key back in the HTTP response body after registration. That certificate and key are kept in escrow in Candlepin's database (not a practice I am personally a fan of, but that's the way it's designed at the moment). As well, the CN of the identity certificate is a unique identifier that Candlepin assigns.
So while you could modify Tomcat to use a different truststore and create a third-party signed certificate after the fact using the CN that Candlepin assigns, the system's record in the Candlepin database would have an incorrect cert and key. I don't know off the top of my head if we ever use the cert and key again, but it doesn't look like we accept updates to those values via the update consumer method (PUT /consumers/{consumer_id}). Additionally, I can't say for certain whether or not subscription-manager would just overwrite the third-party signed certificate arbitrarily at some point since the identity cert it has would be in conflict with what Candlepin returned in HTTP response bodies.
As for using third party signed entitlement certificates, I think that would be even harder. Our entitlement certificates have data embedded in them as custom certificate extensions. You would have to pull that data out and then get it into the CSR for the third party to sign.
Ultimately, I would consider third-party signed certificates to be impractical to implement. However, if you are dealing with an internal CA that you want to sign Candlepin issued certificates, it might make more sense to have that internal CA create a sub-CA for Candlepin to use. That sub-CA would have the path length constraint set to 0 in the basic constraints section (so that it could not issue further sub-CAs). You might also explore the using the NameConstraints extension to limit the namespaces that the Candlepin CA could sign (although I believe support and respect for NameConstraints is generally very poor) [1]
[1] http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-... ----------------- Regards, Alex
Cool. And one more inquiry: -What does the authentication scheme for Gutterball look like (in relation to its use in Katello)
On Tue, Feb 16, 2016 at 12:43 PM, Alex Wood awood@redhat.com wrote:
On 02/16/2016 08:39 AM, Lesley Kimmel wrote:
Can you explain a little how Candlepin generates certificates for clients? Does it have a self-signed CA certificate that it uses to sign these client certs? Would it be possible (albeit inconvenient) to use 3rd part signed certs for these client certs?
Yes, client certificates are signed by a self-signed CA certificate that is created when Katello is installed.
Candlepin issues two types of certificates: identity certificates and entitlement certificates. Identity certificates are issued when a system registers to Candlepin and are henceforth used when the client communicates with Candlepin. Entitlement certificates are issued by Candlepin when a subscription is used and are presented to the content delivery network when attempting to install packages from repositories in /etc/yum.repos.d/redhat.repo.
As for whether it would be possible to use third-party signed certificates... That is a good question. If it is possible, it's going to be very difficult. For one, Candlepin is designed to send the identity certificate and key back in the HTTP response body after registration. That certificate and key are kept in escrow in Candlepin's database (not a practice I am personally a fan of, but that's the way it's designed at the moment). As well, the CN of the identity certificate is a unique identifier that Candlepin assigns.
So while you could modify Tomcat to use a different truststore and create a third-party signed certificate after the fact using the CN that Candlepin assigns, the system's record in the Candlepin database would have an incorrect cert and key. I don't know off the top of my head if we ever use the cert and key again, but it doesn't look like we accept updates to those values via the update consumer method (PUT /consumers/{consumer_id}). Additionally, I can't say for certain whether or not subscription-manager would just overwrite the third-party signed certificate arbitrarily at some point since the identity cert it has would be in conflict with what Candlepin returned in HTTP response bodies.
As for using third party signed entitlement certificates, I think that would be even harder. Our entitlement certificates have data embedded in them as custom certificate extensions. You would have to pull that data out and then get it into the CSR for the third party to sign.
Ultimately, I would consider third-party signed certificates to be impractical to implement. However, if you are dealing with an internal CA that you want to sign Candlepin issued certificates, it might make more sense to have that internal CA create a sub-CA for Candlepin to use. That sub-CA would have the path length constraint set to 0 in the basic constraints section (so that it could not issue further sub-CAs). You might also explore the using the NameConstraints extension to limit the namespaces that the Candlepin CA could sign (although I believe support and respect for NameConstraints is generally very poor) [1]
[1]
http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-...
Regards, Alex
candlepin mailing list candlepin@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/candlepin@lists.fedorahosted.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 02/16/2016 02:32 PM, Lesley Kimmel wrote:
Cool. And one more inquiry: -What does the authentication scheme for Gutterball look like (in relation to its use in Katello)
It looks like Gutterball uses OAuth exclusively. OAuth can be disabled via configuration option, in which case no authentication is performed at all. - --------------- Regards, Alex
candlepin@lists.stg.fedorahosted.org
-
Alex Wood -
Lesley Kimmel -
Stas Fomin