Bad Precedent

Here's why this the Supreme Court's ruling sets a bad precedent: It opens the door to the following very likely scenario. Let's say I am a city council in Boulder and want to expand public transportation service in and around Boulder as well as allow everyone in Boulder the opportunity to use public transportation whether they can afford it or not. As a council we pass a law requiring that you buy a bus pass if you make over $40,000 per year and those who make under that amount will receive bus passes for free. You can choose to NOT buy a bus pass, but then you will be "fined" $250 per year. This is no different in the Court's eyes than Obamacare.
 
Additionally it puts no bounds on what the government can "mandate/tax" what we buy. Want more affordable housing? The government just mandates that EVERYONE own mortgage insurance regardless of their credit level or what they still owe on their mortgage. With the additional insurance, lenders can feel more secure in lending money to those who are likely to default knowing that there is money coming from those who won't default.

Want to lower polution and increase fuel economy? -- Just mandate that all Americans must purchase a hybrid vehicle and "penalize" them if they don't. While we're at it, let's stimulate American manufacturing and create more jobs by simply mandating that the hybrid you buy must be an American-made car.
We all know that incandescent lightbulbs are evil, but how about those cfl bulbs? Those contain harmful mercury and still aren't as efficient as LED bulbs, so let's just mandate that all Americans buy LED lightbulbs. Can't afford LED lightbulbs? Well, the government will give them to you if you live below the poverty line with the money that is coming in from taxing those who aren't buying LED bulbs.

Where will it end? My hope is that it stops before the government says that we all need to install iPads in our homes with FaceTime continually running, so that they can make sure we are doing our calisthenics each morning.

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.