[GODRIVER-803] Add option to allow authenticating with an arbiter Created: 01/Feb/19  Updated: 28/Oct/23  Resolved: 21/Feb/19

Status: Closed
Project: Go Driver
Component/s: Authentication
Affects Version/s: None
Fix Version/s: 1.0.0-rc1

Type: New Feature Priority: Critical - P2
Reporter: Timothy Olsen (Inactive) Assignee: Isabella Siu (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File go-driver-auth-find.go    
Issue Links:
Depends
Problem/Incident
causes GODRIVER-846 Unable to authenticate to a replica s... Closed

 Description   

While the authentication specification currently prohibits authenticating against an arbiter, users of the Go driver require this behavior. To enable this do the following:

  1. Add an option to options.ClientOptions to enable authenticating with an arbiter
  2. Add a PerformAuthentication field to auth.HandshakerOptions
    1. This field's type is func(description.Server) bool
    2. This field is used to determine if auth should take place. If it returns true, perform authentication
    3. If PerformAuthentication is nil, a default function should be called, which allows authentication following the authentication specification
  3. Inside auth.Handshaker call options.PerformAuthentication with description.Server from the response to command.Handshake
    1. If it is not allowed, skip authentication
    2. If it is allowed, proceed with authentication by calling options.Authenticator.Auth
  4. Remove the current arbiter checks from auth.ConductSaslConversation and auth.MongoDBCRAuthenticator.Auth

While unrelated, add a nil check for options.Authenticator to avoid a nil pointer panic.

 


Under an auth+arbiter setup, the only way to authenticate to an arbiter is to use the keyfile (when X.509 member auth is not used). I am finding that I while I am able to auth using the keyfile to a regular member of the replica set, I am not able to auth to the arbiter.

I am attaching the go program I am using. Here is the output:

with a regular node:

[tim@liquid tst]$ go run go-driver-auth-find.go liquid.local:9001
[tim@liquid tst]$ 

(no output because the collection is empty)

with an arbiter:

[tim@liquid tst]$ go run go-driver-auth-find.go liquid.local:9004
panic: (Unauthorized) command find requires authentication
 
goroutine 1 [running]:
main.main()
	/Users/tim/tst/go-driver-auth-find.go:37 +0x64e
exit status 2
[tim@liquid tst]$ 

Here are the relevant log lines from the regular member:

2019-02-01T16:05:52.565-0500 I NETWORK  [listener] connection accepted from 10.0.1.11:64664 #45 (13 connections now open)
2019-02-01T16:05:52.568-0500 I NETWORK  [listener] connection accepted from 10.0.1.11:64665 #46 (14 connections now open)
2019-02-01T16:05:52.569-0500 I NETWORK  [conn46] received client metadata from 10.0.1.11:64665 conn46: { driver: { name: "mongo-go-driver", version: "v0.3.0-prerelease" }, os: { type: "darwin", architecture: "amd64" }, platform: "go1.10.8" }
2019-02-01T16:05:52.578-0500 I ACCESS   [conn46] Successfully authenticated as principal __system on local
2019-02-01T16:05:52.580-0500 I NETWORK  [conn46] end connection 10.0.1.11:64665 (13 connections now open)
2019-02-01T16:05:52.580-0500 I NETWORK  [conn45] end connection 10.0.1.11:64664 (12 connections now open)

and from the arbiter:

2019-02-01T16:05:59.159-0500 I NETWORK  [listener] connection accepted from 10.0.1.11:64668 #40 (4 connections now open)
2019-02-01T16:05:59.161-0500 I NETWORK  [listener] connection accepted from 10.0.1.11:64669 #41 (5 connections now open)
2019-02-01T16:05:59.162-0500 I NETWORK  [conn41] received client metadata from 10.0.1.11:64669 conn41: { driver: { name: "mongo-go-driver", version: "v0.3.0-prerelease" }, os: { type: "darwin", architecture: "amd64" }, platform: "go1.10.8" }
2019-02-01T16:05:59.163-0500 I NETWORK  [conn41] end connection 10.0.1.11:64669 (4 connections now open)
2019-02-01T16:05:59.163-0500 I NETWORK  [conn40] end connection 10.0.1.11:64668 (3 connections now open)



 Comments   
Comment by Timothy Olsen (Inactive) [ 21/Feb/19 ]

I think the fix for this has introduced a regression: GODRIVER-846

Comment by Timothy Olsen (Inactive) [ 21/Feb/19 ]

Thank you all.  I'll try it out

Comment by Githook User [ 21/Feb/19 ]

Author:

{'name': 'Isabella Siu', 'email': 'isabella.siu@10gen.com', 'username': 'iwysiu'}

Message: GODRIVER-803 add AuthenticateArbiter client option to allow authenticating with arbiter

Change-Id: I580d2801c0ed0e35b20650fc32a5f7ae66362d7b
Branch: master
https://github.com/mongodb/mongo-go-driver/commit/0df304e4131439d6f9ca23b79f8412043ab97c2f

Comment by Isabella Siu (Inactive) [ 20/Feb/19 ]

code review: https://review.gerrithub.io/c/mongodb/mongo-go-driver/+/443635

Comment by Jeffrey Yemin [ 02/Feb/19 ]

Leaving as Critical, but changing to New Feature as the driver is properly implementing the authentication specification, which states:

> If the server is not of type Standalone, RSPrimary, RSSecondary or Mongos, no authentication is possible and the handshake is complete.

We're discussing the options and will figure out a plan to enable this use case.

Generated at Thu Feb 08 08:35:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.