Introduce optional subject name-based authorization #18
Labels
enhancement
New feature or request
Comments
m-ronnblom
added a commit
that referenced
this issue
Nov 11, 2022
In case a client connects over TLS, the client's X.509 subject key identifier (SKI) will be used as a server-side user id. In case the client certificate changes (and the SKI with it) and the Pathfinder protocol connection is torn down and reestablished (e.g., due to a network outage), the client will typically connect under a new user id, but the same client id. The server currently accepts such clients, but does not allow them to republish services owned by the previous user id. The services published under the old user id would be marked as orphans, and will eventually be removed, allowing the new client to republish the services. This patch fixes a bug where such a reconnecting client would keep orphaned services alive upon disconnecting. This in turn, with current libpaf behavior, result in a situation where services published under the original user id would never be removed, if the service TTL was larger than the retry period. For a better solution than using SKI for access control, see issue #18. Signed-off-by: Mattias Rönnblom <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Pathfinder server-side-only concept of a user uses the client's X.509 subject key id to classify a user connected over TLS. Each subject key id is a user.
The subject key id is used for both to enforce per-user resource limits, and to maintain the server's access control rules (e.g., preventing a user to overwrite or unpublish other users' services). This is in turn an attempt to limit the damage that a malicious (or buggy) client may cause.
The subject key id-based approach requires no configuration, but has two limitations. It does not allow a client to replace its certificate. Also, it does not allow to group many Pathfinder clients originating from different systems (with different certificates and private keys) into the same Pathfinder user.
The server should support authorization based on client certificate subject name as well. "Subject name" here is (as in RFC 6125) meaning the subject field common name (CN) and/or a subject alternative name of type DNS.
The text was updated successfully, but these errors were encountered: