TaylorCFrey commented on code in PR #6622: URL: https://github.com/apache/trafficcontrol/pull/6622#discussion_r958560648
########## blueprints/client-certificate-auth.md: ########## @@ -0,0 +1,240 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +<Paste>"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> + +# Client Certificate Authentication + +## Problem Description + +Passwords currently serve as a powerful, but inflexible, way for clients to +authenticate with Traffic Ops. However, an account can only have one password +at a time, which means that service accounts tend to have a single shared +password. This is undesirable from a security perspective. + +Client certificates are a flexible tool that allows operators to assign +independent credentials to users of a service account. These credentials can +have varying expirations and be issued in accordance with the operator's +security policy. + +## Proposed Change + +When Traffic Portal or Traffic Ops receives a request, in addition to accepting +a valid token, it will accept a valid TLS certificate chain. Traffic Ops will +have a list of root certificates that it accepts. + +Issuance and management of these certificates will occur outside of Traffic +Control and is the responsibility of the operator. + +### Traffic Portal Impact + +Traffic Portal will pull user information from requests before they are +proxied. Connections between TP and TO will be signed with a client certificate +to protect the connection. + +When TP proxies a connection to TO, it validates the TLS certificate against +it's list of authorized roots. Iff it is valid, it includes the Subject of the +certificate verbatim in a request header named `Client-Cert-Subject`. Review Comment: Are these standard headers (`Client-Cert-Subject` `Client-Cert-Public-Key` etc)? My brief searching for `Client-Cert` headers shows the IETF draft https://www.ietf.org/id/draft-ietf-httpbis-client-cert-field-02.html. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@trafficcontrol.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
