Forwarding IIS Windows Authentication User Information to Streamlit (st.context.headers)

Deployment
, ,
1

I’ve created and deployed an internal tool at my company using Streamlit, running behind an IIS reverse proxy configured with:

  • Windows Authentication

  • URL Rewrite

  • Application Request Routing (ARR)

Architecture:

Browser → IIS (Windows Auth + URL Rewrite + ARR) → Streamlit app

Only users connected to our internal network and part of our Active Directory (AD) can access the site. The app has been deployed for ~6 months and works great.

Goal

I’d like to seamlessly retrieve uniquely identifiable user information (e.g. DOMAIN\username or UPN) inside my Streamlit app for:

  • usage analytics
  • observability
  • audit logging

Without prompting the user to log in again.

IIS already captures this via Windows Authentication (e.g. cs-username), so ideally I’d like to forward that identity to Streamlit via HTTP headers.

What I’ve Tried

I attempted multiple approaches using:

  • Custom HTTP headers
  • Server variables
  • URL Rewrite outbound rules
  • ARR header forwarding

Even with hardcoded test values, nothing I inject shows up in:

st.context.headers

Standard headers (Host, User-Agent, etc.) appear normally — but any custom headers defined in IIS never arrive at Streamlit.

Suspected Root Cause

This Microsoft thread suggests that URL Rewrite executes before Windows Authentication, meaning the authenticated identity does not exist yet when forwarding occurs:

If this is correct, it would explain why:

  • IIS logs show cs-username
  • But Streamlit never receives that identity via headers

To me, this does not explain why I still cannot see my custom hardcoded HTTP headers, which do not rely on any external information from the Windows Authentication module.

Questions

  1. Has anyone successfully forwarded IIS Windows Authentication user identity to a Streamlit app?

  2. If so:

  • What IIS modules were used?
  • How was it configured?
  1. If this truly isn’t feasible with Windows Auth + URL Rewrite + ARR, are there alternative approaches that preserve:
  • Seamless SSO experience
  • No additional login prompt
  • Minimal architectural complexity

Additional Context

I’ve already set up Microsoft Entra (Azure AD) authentication and can retrieve user identity that way. However, the team is strongly preferring a non-intrusive, zero-interaction solution where identity is available automatically as soon as the user accesses the app, similar to classic intranet IIS apps using Windows Auth.

Any insights, patterns, or battle-tested approaches would be greatly appreciated.

2

Welcome to the Streamlit community, and thanks for the super detailed question! :blush: It could be possible that forwarding the authenticated Windows user identity from IIS to Streamlit via HTTP headers is tricky due to how IIS modules process requests. According to community discussions, Streamlit apps behind reverse proxies (including IIS) often can’t access custom headers injected by IIS, especially those set after authentication, because Streamlit’s Python backend only sees headers present at the time the WebSocket connection is established—not those added later or by outbound rules. Even hardcoded custom headers may not appear due to how IIS and ARR handle header forwarding and the timing of authentication modules. This is a known limitation, and several users have reported similar issues when trying to pass Windows Auth info to backend apps like Streamlit via headers or server variables, with the headers not surfacing in st.context.headers or previous workarounds like _get_websocket_headers() (source, source).

Though I’m not entirely certain, it might be that the only robust way to achieve seamless SSO with user identity in Streamlit is to use a reverse proxy that can inject headers before the WebSocket handshake, or to use a custom authentication component that leverages cookies or tokens set by IIS. Some users have had success with Nginx (not IIS) by ensuring headers are set before the WebSocket upgrade, but IIS’s module order and ARR’s handling may prevent this. There doesn’t seem to be a battle-tested, out-of-the-box solution for IIS + Windows Auth + Streamlit that meets your requirements without additional login prompts or architectural changes. If you want to share your IIS config and Streamlit version, the community might be able to suggest more targeted workarounds! And if anyone else has cracked this, please jump in and share your insights! :man_superhero:

Sources: