CODEWITHSUNDEEP
google-chromeselenium-webdriverfirefoxkerberosspnego
Ivar Suisalu
Ivar Suisalu

Reputation: 1

SPNEGO authentication (Kerberos) for browser inside selenium/standalone-chrome docker container

The plan is to use selenium/standalon-chrome for UI test automation. Some of our internal urls require Windows integrated authentication(SPNEGO, Kerberos).

Inside this container we have Linux of course and I used https://www.chromium.org/administrators/linux-quick-start/ for chrome configuration and the policy file included:

 {
  "AuthServerAllowlist" : "*.mydomain.ee",
  "AuthNegotiateDelegateAllowlist" : "*.mydomain.ee",
  "DisableAuthNegotiateCnameLookup" : true,
  "EnableAuthNegotiatePort" : true
 }

but this didn't worked and when I checked chrome://policy those policies wasn't shown.

I tried also chrome arguments

    --auth-server-allowlist="*mydomain.ee"
    --auth-server-delegate-allowlist="*mydomain.ee"

but this didn't work either.

Also I tried firefox container selenium/standalone-firefox using https://mozilla.github.io/policy-templates/

I put policy.json under /etc/firefox/policies. When test starts the firefox shows those policies after navigating to about:config, but still I get the error

CWWKS4306E: SPNEGO authentication is not supported on this client browser..

I wonder if it possible to configure browser this way inside container at all or I am missing some bits here?

Upvotes: 0

Views: 82

Answers (1)

grawity_u1686
grawity_u1686

Reputation: 16552

Your browser is configured correctly, but the problem is that it doesn't have the Kerberos tickets that it could use. All of the instructions you've found were written with the assumption of a standard browser running in a standard desktop session, where the user logs in to Windows (or Linux) and the OS automatically gets them a Kerberos ticket which programs may use.

But since your browser is running in a container, it has (by design!) no access to anything on the host, so even if you do have a Kerberos ticket in general, the container still won't. It needs to have the tickets somehow provided to it.

The initial ticket is typically obtained with a username and password, such as by running kinit. When it comes to automating it, Linux tools would store the password in the form of a "keytab" file (which can also be used with kinit). You could technically create a keytab for your own account using ktutil, but really should get a dedicated user account made for the whole automation thing. (Otherwise you'll forget about it and change your password six months later and all automation will break the next day.)

Kerberos tickets expire in ~10 hours, so if the container runs longer, it'll need the kinit to be run on a schedule – either there needs to be a cron job, or a dedicated tool such as k5start, which would re-obtain the initial ticket using the provided keytab.

Upvotes: 0

Related Questions