On Wed, Mar 11, 2020, at 2:58 PM, Brian Bouterse wrote: > > > On Wed, Mar 11, 2020 at 2:34 PM Justin Sherrill <jsher...@redhat.com> wrote: > > We had discussed base64 encoding the cert in the webserver on the way in > > and then letting cert guard decode it. While that's not ideal I think it > > has some advantages over moving the full auth into the webserver. What was > > your motivation for going with that approach over the base64 encoding > > approach? > > Thank you for this question! I ended up with a few different concerns > about the base64 encode-and-forward idea. Architecturally the concern > with it is that it's frowned upon to forward the client's TLS cert > beyond the TLS termination point because that is what MITM software > does. Also, there are some practical concerns: one, I don't think nginx > can provide a similar runtime base64 encoding feature. Also I was > concerned with header length truncation and what happens when the > certificates get longer. > > Overall having auth that is based on TLS certificates brought me to the > conclusion that we need to auth where the TLS is terminated. What do > you think? > > More thoughts and questions are welcome. This is a good discussion. >
I agree with your points. Also, having the auth in the web server would allow me (random bystander) to use the functionality without actually running a full pulp; just plain candlepin with yum repos behind a web server. V/r, James Cassell > > > On 3/11/20 2:11 PM, Brian Bouterse wrote: > >> tl;dr: What we have today cannot work with rhsm certificates which Katello > >> uses. To resolve, we need to have content guard checking moved to the > >> webserver configs for apache and nginx and not done in pulp-content as it > >> is today. https://pulp.plan.io/issues/6323 > >> > >> We need to bring the auth to where TLS is terminated because we can't > >> being the client certs to pulp-content due to invalid header characters. > >> As is, pulp-certguard cannot work with Katello's cert types (rhsm certs) > >> so that is driving my changes. > >> > >> If anyone has major concerns or other ideas please let me know. In the > >> meantime I'm proceeding moving the authorization to the webserver and then > >> updating pulp-certguard to work with that. This will make pulp-certguard's > >> GA tied to pulpcore 3.3.0. Feedback is welcome. > >> > >> [0]: https://pulp.plan.io/issues/6323 > >> > >> Thanks, > >> Brian > >> _______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
