WCF Federated Security

Service security has been an ongoing issue with these products that we currently have in development. Each inidividual product we have created thus far generally has its own mechanism for authorization and authentication, though we definitely reuse certain components and libraries between them. For some time our vision has been to have a composite application using WPF with Prism with calls to different WCF services. In brief the architecture would be a basic application shell with some intrinsic administration functionality like user management, and each component of our election management system would be a plug-in module to the shell at the interface level along with its own WCF service at the server level. A further issue is whether each module would have its own database or there be a joint election database or series of common databases for all modules. That issue is another series of blog posts in itself.

The issue we are tackling is with shared security amongst the different modules. Once a user logs in to the application, those credentials need to be verified or otherwise trusted by each plug-in's respective service. To date, we have bounced around a number of ideas about how to do this having come to no real decision yet. I would like to explore a federated security model, since it seems to lend itself to this specific issue.
I want to create a spike solution with our basic architecture -- a shell with a couple plug-ins each with a backing WCF service -- and run through different security scenarios with it. I'm starting with reading the MSDN articles on the subject here: http://msdn.microsoft.com/en-us/library/ms731161.aspx.

So after reviewing the articles there, I have a bit of a chicken-egg problem in creating my spike solution. What component do I try to tackle first? I think that I may start with the Security Token Service, since it seems the other services and client will rely on that existing. Ah - there is a Federation Sample here: http://msdn.microsoft.com/en-us/library/aa355045.aspx. Looks simple enough. I'll try and implement my own solution as described above, but think I just need the one STS.