[BUG] MSI authentication fails due to expiry date format mismatch

[yjo]

Driver version

7.4.1

Client details

Running on an Azure App Server Java 11 / Linux instance in the UK west region
OS: Alpine 3.8 Docker container
JVM: OpenJDK Runtime Environment 19.1-(Zulu-11.29+3-linux-musl-x64)-Microsoft-Azure-restricted (build 11.0.2+7-LTS)

Problem description

1. Configure an App Services resource (Java 11 in "UK West" region) and Azure SQL DB for authentication using MSI, following instructions here
2. Deploy code that attempts MSI authentication, e.g.:

//...
public static void main(String[] args) throws Exception {
    SQLServerDataSource ds = new SQLServerDataSource();
    ds.setServerName("my-db-instance.database.windows.net");
    ds.setDatabaseName("my-db-name");
    ds.setAuthentication("ActiveDirectoryMSI");
    Connection connection = ds.getConnection(); 
}
//...

3. The connection fails, with an opaque "MSI Token failure: Failed to acquire token from MSI Endpoint" error.

Unfortunately there's no stack trace or log output that shows the underlying problem (even at java.util.logging.Level.ALL), but by retrying with a patched version of the driver with extra logging I was able to narrow the issue down to SQLServerConnection.java:4376 which throws a java.text.ParseException when attempting to parse the token expiry timestamp. The driver implementation is looking for a 12hr time format - "M/d/yyyy h:mm:ss a X", but the MSI API server (for my App Service instance in UK West at least) is returning a 24hr format, e.g.
"08/30/2019 01:08:02 +00:00".

It's not clear to me whether the issue is with the MSI server (possibly just in some regions?) or the driver. Even if the issue is with the MSI server (in which case I'd appreciate advice on how to raise such an issue), I'd suggest it's probably a bug that the relevant exception details are swallowed by the driver without any logging. I've attached the full log traces from the unmodified 7.4.1 driver from the start of the MSI request so you can see what I mean.
output-trimmed.log

All best,
Joe

[peterbae]

Hi @yjo, thanks for letting us know. I haven't had a chance to look into this today, but I'll look into this and get back to you shortly.

[peterbae]

Hi @yjo, sorry for the wait. I've talked to an Azure engineer and it's an error that the expiry date information is coming in a String format, and it should've been an integer value instead. I will make changes to the driver to reflect that when they deploy the changes to Azure, and that will fix this issue as well. The ballpark time for when the changes will be deployed on Azure is within the next month or two.

In the meantime, I do have a fix for the driver that fixes this issue against UK West region. Would you like to use it, or are you okay with waiting until the fix is deployed on Azure?

[yjo]

Hi @peterbae, I think we're happy working around the issue with another authentication method until the MSI fix is on the mainline release. Many thanks for looking into this issue!

[oneton]

It's too bad I only find this issue after a long day of troubleshooting my first Docker/Tomcat app service deployment with JDBC connection (West-Europe). Initially I thought my configuration was wrong, until I found out that the service actually returned a valid token. The hardest part was figuring out what went wrong due to the absence of a stacktrace. I eventually compiled my own driver version which did log a stacktrace to find the exact same problem.

I'm happy to read that a solution is on its way. Meanwhile, I can use my own patched driver.

[cjosw]

@peterbae Any progress on when this fix will be deployed to Azure?

[peterbae]

We're not the team that deploys the fix to Azure. The last I heard (a week ago), the fix has been checked in but the release is TBD.

[cjosw]

@peterbae Any further progress on when this fix will be deployed to Azure?

[peterbae]

@cjosw is the problem still reproducible for you?

[cjosw]

Er, does that mean that you believe that the fix has already been deployed?
Our current infrastructure is not using MSI authentication; we would have to set up a test instance again to determine whether the bug still exists.

[peterbae]

The last time I heard from Azure team was that the release date was still TBD, but I haven't had time to check if the fix had been deployed. I'll verify myself as soon as possible.

[peterbae]

Update, the fix has been deployed on Windows but not the Linux deployed Azure web apps. The fix for Linux should be deployed on Azure in February or March.

[peterbae]

Also attaching a patched version of the 8.2.0 driver with a fix for this problem. The fix will not be merged as the problem will likely solve itself when the Azure team deploys their fix.

github-1135-temp.zip

[peterbae]

Issue has been fixed on Azure's end, and PR #1308 contains the driver jar that accommodates this fix.

[ulvii]

#1308 merged.

[vladkun]

Still doesn't seem to work in 8.2.2.jre8 release. Same setup: AppService, Linux app plan + North Europe region.
{"access_token":"","expires_on":"06/27/2020 12:14:35 +00:00","resource":"https://database.windows.net/","token_type":"Bearer","client_id":""}
java.text.ParseException: Unparseable date: "06/27/2020 12:14:35 +00:00" (because expected format in lib still:
static final String ACCESS_TOKEN_EXPIRES_ON_DATE_FORMAT = "M/d/yyyy h:mm:ss a X")

[peterbae]

@walk0r this fix is available starting from v.8.3.1 release.

[vladkun]

@peterbae true, my bad. Are there any due dates for stable release?

[peterbae]

The next stable release is targeted to be released by end of this July.