Oracle WebCenter Interaction: Using multiple logins and URLs to access your portal

When we purchased Plumtree licenses way back in the day we had visions of using the software to run our intranet and as an extranet for small groups of outside users.  The setup was fairly vanilla in terms of experience definitions, rules, and URLs - we based everything upon what folder a user object was stored in and fed the experience definition on that.  Extranet users are directed to a secure URL which points to the IP of our DMZ portal server and then exposes the portals functionality, while internal users access a pair of load balanced internal portal servers using the same URL.  In IIS 6 and what is now WCI 10.3, this type of setup is quite straight-forward.

Recently we were asked to build a new site for medical professionals which would use a different secure URL and allow users to create their own accounts before logging in and viewing targeted content.  Because security certificates attach to IIS Web Sites we needed to create a new site and obtain a new certificate.  Could we have put 2 certs on a single site? Maybe...but that didn't seem like a best practice and we figured the tried and true approach would pay off in the end.

We pointed the new URL to a new IP address which was attached to a new "Web Site" in IIS with a corresponding certificate.  Once that was setup we created a virtual directory to point to the /portal and /imageserver directories.  The default site page routed to /portal/server.pt as required but there we received nothing but a 404 message.  After some head scratching and browsing of the Oracle Support archives and Oracle Technology Network discussion boards a quick conversation with support identified the obvious issue - we hadn't registered the product specific file extension within IIS! duh!
On the Web Site you must configure the application settings.  Go to the mapping application extensions area and add a new mapping for .pt which points to the executable located in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
then limit the verbs to: GET,HEAD,POST,OPTIONS,PROPFIND,PROPPATCH,MKCOL,LOCK,UNLOCK,
PUT,DELETE,COPY,MOVE

Restart IIS and voila!

To complete the experience we developed a new login page which included a "Create Account" link, and defaulted the Auth Source to our portal repository.  An Experience Rule was created for the new URL and points to an Experience Definition that has a custom Login page defined (if you don't do this your site will use whatever your Guest login page is).