mike-jumper commented on code in PR #797: URL: https://github.com/apache/guacamole-client/pull/797#discussion_r1118232133
########## extensions/guacamole-auth-sso/modules/guacamole-auth-sso-ssl/src/main/java/org/apache/guacamole/auth/ssl/SSLAuthenticationProvider.java: ########## @@ -0,0 +1,48 @@ +/* + * 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 + * "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. + */ + +package org.apache.guacamole.auth.ssl; + +import org.apache.guacamole.auth.sso.SSOAuthenticationProvider; + +/** + * Guacamole authentication backend which authenticates users using SSL/TLS + * client authentication provided by some external SSL termination system. This + * SSL termination system must be configured to provide access to this same + * instance of Guacamole and must have both a wildcard certificate and wildcard + * DNS. No storage for connections is provided - only authentication. Storage + * must be provided by some other extension. + */ Review Comment: My research hasn't revealed any, but I would be very happy to hear of a better approach. The current approach with wildcard certificates and wildcard DNS is rooted in what I encountered while researching how PIV/CAC auth could be implemented. I had access to: * A subset of the set of NIST PIV test cards. * A USB card reader. * https://secure.login.gov/login/piv_cac as a real-world example of what a good PIV/CAC auth flow can be. From the above, I observed: * Browsers cache credentials from X.509 certificates. Initially, I had hoped to work around this by checking SSL session IDs, but that was not sufficient - these were _new_ sessions established with cached credentials. * There is no way for anything not directly handling the SSL/TLS communication to force any sort of behavior with respect to smart cards. * Behavior of an SSL/TLS connection is tied to the domain. It's not possible to require SSL client auth for only a path beneath a domain, because this negotiation occurs when the SSL connection is established and before anything like the HTTP request path would be available. * The `login.gov` site appears to leverage randomly-generated hostnames and wildcard DNS to ensure that clicking the "Insert your PIV/CAC" button always produces a fresh prompt for your card. This occurs through a series of redirects that are not visible unless you take a look at browser dev tools: 1. User visits https://secure.login.gov/login/piv_cac 2. User clicks "Insert your PIV/CAC" 3. Internally, a request is issued to `https://secure.login.gov/login/present_piv_cac` 4. That request is redirected to `https://XXXX.pivcac.prod.login.gov/?nonce=NONCE&...` where `XXXX` is a 4-character random subdomain and `NONCE` is a lengthy, unique nonce value. 5. _Only_ the request to `XXXX.pivcac.prod.login.gov` requests SSL/TLS auth. It then redirects back to the original domain and includes a lengthy token in the query parameters of the redirect URL. 6. The result of auth is obtained through using that token and reported to the user. While I _believe_ the `login.gov` site does things this way for the same reason I did (to ensure the user is guaranteed a fresh auth attempt), I can find no supporting documentation for this sort of requirement, including for established smart card auth solutions that purport to support PIV/CAC. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
