WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED MOVED
236834
[GTK] Azure portal login with Kerberos requires page reload
https://bugs.webkit.org/show_bug.cgi?id=236834
Summary
[GTK] Azure portal login with Kerberos requires page reload
brian
Reported
2022-02-18 04:50:05 PST
I am experiencing a weird issue with WebKitGTK (2.34.5) and the Microsoft/Azure AD/SSO OAuth2 login service. Specifically in the case of trying to authenticate for EWS/O365 e-mail with an AD/Kerberos ticket. What happens is that Evolution tries to authenticate to the O365 mail account, which is configured for OAuth2 and in doing so an Azure OAuth2 authentication dialog is opened in a WebKitGTK widget. The URL that is opened in that web view is supposed to use the Kerberos ticket to perform the authentication and then the web view widget is supposed to close (without any input required from the user). During this time, a service ticket for HTTP/
autologon.microsoftazuread-sso.com@CORP.EXAMPLE.COM
is used to perform the authentication. What is happening however is that the Azure authentication page loads but rather than completing the authentication with the Kerberos ticket, it asks me for my password. If I enter my password, the authentication in Evolution will continue and Evolution will display my e-mail. However(!), and this part is important, if rather than entering my password into that web view of the Azure authentication page, I simply Reload the web view, the Kerberos authentication will work and I won't have to enter my password. I see this same behaviour in Epiphany when trying to use the same URL as the web view in Evolution. I have to load the URL twice before the authentication succeeds. If I do the same thing, load the URL in Chrome, it works on the first try and no Reload is necessary. Unfortunately, I cannot supply the URL in question as it's related to my work-place's use of MS services and has work-place specific components to the URL. You would not be able to use the URL anyway, as you won't have the AD/Kerberos ticket required to be able to reproduce. I am more than happy to provide the results of any debugging steps you might want me to do however.
Attachments
Add attachment
proposed patch, testcase, etc.
Michael Catanzaro
Comment 1
2022-02-18 07:34:09 PST
No warnings printed on the command line? This is gonna be tough to solve. Kerberos works fine for me across a variety of different websites, so it's got to be somehow specific to this particular page. No clue what could be the problem. :/
brian
Comment 2
2022-02-18 07:43:01 PST
Would that be the evolution and/or epiphany commandline you are referring to, as in starting them from a shell prompt? But yes, do I agree, that "regular" Negotiate seems to work just fine. Epiphany can use a Kerberos ticket to authenticate to a GSSAPI-auth configured Apache server with no problems for example. It is interesting to note though, that in looking at all of HTTP transactions in the devtools in both Chrome and Epiphany when following the auth URL, that none of the Azure log in process is actually using the Negotiate authentication method, via HTTP authentication headers (that I can see at least). I don't know how it is working otherwise but it is.
Michael Catanzaro
Comment 3
2022-02-18 07:55:52 PST
(In reply to brian from
comment #2
)
> Would that be the evolution and/or epiphany commandline you are referring > to, as in starting them from a shell prompt?
Yes.
brian
Comment 4
2022-02-18 08:02:28 PST
So, yes. On the first attempt where the webpage ends up asking for a password, epiphany emits a: (process:1656283): libsoup-WARNING **: 10:58:02.037: Failed to parse auth header But after hitting reload, where the second attempt works without asking for a password, no such message (or any message).
Michael Catanzaro
Comment 5
2022-02-18 08:42:50 PST
OK great, that is
https://gitlab.gnome.org/GNOME/libsoup/-/issues/184
and it's a libsoup bug. Now we're getting somewhere! Please, add your comments to the libsoup issue. Thanks.
Michael Catanzaro
Comment 6
2022-03-02 06:04:21 PST
I'm going to close this as MOVED to the libsoup issue
https://gitlab.gnome.org/GNOME/libsoup/-/issues/184
. It seems to be a server problem, but if other clients are able to work around it, maybe libsoup can too. That's a layer below WebKit, though.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug