Running the client using IIS

Oct 28, 2011 at 11:43 AM

My Silverlight client is using WS-Trust to authenticate against an STS which means that it has to run on IIS with a web.config file.

Does StatLight support such a scenario?  Can I replace the InMemoryWebServer with IIS?

 

/Martin

Coordinator
Oct 28, 2011 at 4:51 PM

So StatLight will rewrite it's own xap with your assemblies/resources etc and create a single xap that is then loaded up into a web browser (originally hosted from the StatLight web server). Excuse my WS-Trust ignorance, but is it not possible to host your WS-Trust services out on a different domain (http://localhost:{SomeOtherPort}/Services/*) and then just call them from your tests (which are hosted in the StatLight domain?)

Regarding replacing the InMemoryWebServer, I have something in the codebase called "remotely hosted" that was more of a spike I tried out a long while back. It's probably not working, and is not supported ATM but could be a work around for you.

How do you currently test this code? Do you have a test web site in IIS that loads up your test xap? If this is the case, I would break you "integration" tests out into one project and have a separate unit test project that can then be run with StatLight. This way you can get the C.I. on your integration tests, and you can periodically check your Integration test project(s).

Hope something above might help you.

Nov 1, 2011 at 9:21 AM

We currently test this code "normally", running StatLight. We are about to switch from using HTTPS/username/password to a claims-based model using Windows Identity Foundation and that's when we ran into trouble.  

The issue is really in the implementation details of the SL.IdentityModel that Microsoft distributes in the Identity Developer Training Kit. This assembly implements Silverlight support for WS-Trust by hosting a service for token processing in the same project that hosts the Silverlight application.  Thus our Silverlight client hosting project needs to run on IIS.

I think I'll try to split the Silverlight hosting and token processing into separate services and see where that leads us.

Thanks for your pointers and quick reply.

/Martin

Nov 8, 2011 at 6:43 PM

Well it looks like we need to be part of the application constructor and startup event code in StatLight.Client.Harness.  We need to add a ClaimsIdentitySessionManager to the ApplicationLifetimeObjects; I currently see no way around that,  It is just the way the Silverlight WS-Trust integration part of the Windows Identity Foundation Lab is implemented.

I think we will try to just edit the StatLight source code to integrate it into the security model we are building and see if we can get it running that way.

Nov 16, 2011 at 7:48 PM

Well after a few days of effort, we managed to make StatLight be part of a claims-based security model using the SL.IdentityModel assemblies from the Windows Identity Foundation SDK labs.  Basically, we followed the idea as described above; we registered a ClaimsIdentifySessionManager object with ApplicationLifetimeObjects in the StatLight.Client.Harness application constructor and let StatLights Silverlight application log on to the STS.

It is far from ideal since it means that we have to maintain our own copy of StatLight, but hey, it works.