Deploying to IIS6 an IIS-hosted STS with usernametoken token processing capabilities

So lets go through the (hard to recall IIS6-era) basics using interactive tools (vs a prepp’ed script). The goal is to host in this production-like environment the STS site already working in a developer IIS Express 8.5 server (based on source code from Microsoft’s Claims Aware sample code for active clients. The workstation is to figure what we need in code/config so things work in production (not on a silly developer workstation setup).

We create a website (not a  virtual directory of the default website), to which we assign 2 bindings. Back in IIS6 era, we assign to all the Ethernet adaptors responsibility for port 80 and assign the host header used for the site’s identity exposed at the NAT’ing load balancer. We also see that this site exposes port 8443 (so we can expose a direct SSL (non LB-terminated) path through the firewall/loadbalancer


We assign the default application of the website to a non-default active application pool, with a domain identity assigned to on the worker process (and this account has all NT ACL rights and privileges on the source directory (and files) in the file system supporting the website.




We clearly have my testing (but production-real) SSL cert assigned, which establishes authority for the name (which is the host-header we assigned).


The process identity also has access to the private key (but we cannot show this, back in IIS6 era)

And we see from a browser on the same host (where Fiddler is mapping to localhost in its HOSTS file).


and from a browser OUTSIDE the loadbalancer, with a single resource server in its pool and a flow policy set for SSL pass through:


from outside the loadbalancer (the internet…)

And, in the STS webapp’s web.config we set the following behaviours so WSDL is exposed with external names in the addressing:


and for which cert 1 I GUESS is to enable the metadata services to work ,whereas cert 2 in WIF is there for use when encrypting RST-R TO the STS. Anther configuration of a cert in the application properties sets the STS code. Getting these right (and pointing via a CN=XYZ reference to a cert in the MY/Personal store for the local machine), we can read the WSDL – which has the right internal address names:


So clearly, our STS has been activated – able to produce metadata about the ws-trust13 port and its message capabilities. Will it now cooperate with a WS-trust client?

It seems so, given the client logging view of the request and response:


clearly we see a SAML1.1 response, in a ws-trust “13” era responsecollection, sourced to our resource server (visible to the outside world, for the Americans/British/Chinese to spy on!!). Now that we have no firewall protecting us so SSL works end-end, we will need to be more careful on the (PRODUCTION) web server config…

So there is little about the (almost) production environment itself that is interfering with our production STS built into a production webapp (with real username token processors).


About home_pw

Computer Programmer who often does network administration with focus on security servers. Sometimes plays at slot machine programming.
This entry was posted in SSO. Bookmark the permalink.