Office Web Parts / Office Web Components connecting to SQL Server from extranet

I am using Office Web Parts (specifically the PivotView) on several Web Part
pages. The IIS virtual directory serving the pages uses basic security over
SSL. The pages with Office Web Parts on them work correctly when accessed
via our intranet; users are logged on seamlessly using their domain
credentials, and the PivotView parts retrieve data from our SQL Server
database and display it in the page. However, when we access these pages via
our extranet, even if the user logs in using their domain credentials, the
Office Web Parts fail to retrieve data because of a SQL login failure
("Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection."). All other pages on the portal are displayed correctly
from the extranet.
The IIS box (running WSS) is outside our firewall, and the SQL Server box is
behind our firewall. The machines are on different domains with a one-way
trust relationship (the extranet domain trust accounts from our intranet
domain). We've opened the generally accepted ports on the firewall to
support SQL Server (at least we know that WSS is able to access the SQL
Server box to deliver all other portal content). Using connection strings
similar to the following, the Office Web Parts fail to login (when the pages
are accessed from the extranet):

Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
Info=False;Initial Catalog=ourDB;Data Source=ourSQLserver;
Provider=SQLOLEDB.1;Trusted_Connection=Yes;Persist Security
Info=False;Initial Catalog=ourDB;Data Source=ourSQLserver;

So far, the only way that we've been able to get this to work from the
extranet has been to use SQL Authentication and a connection string similar
to the following:

Provider=SQLOLEDB.1;Persist Security Info=True;User
Id=ourUserId;Password=ourPwd;Initial Catalog=ourDB;Data Source=ourSQLserver;

Obviously, we'd rather not use SQL Authentication, since the connection
string is written to the page, where it is readable in the browser using the
View/Source command. I researched the problem and discovered the following
article (among others) which looked promising:

 http://www.**--****.com/ 

However, the steps outlined in the article didn't correct the problem. I
also read the following article which suggested that we may need to open
more outbound ports on the firewall to make this work:

 http://www.**--****.com/ 

I've also seen references to Kerberos authentication that suggest that it
could solve the problem. However, rather than plow blindly ahead, I thought
I'd seek input.

Any suggestions?