Common Windows Identity Foundation misconceptions - Init

<body> <h1>Common Windows Identity Foundation misconceptions</h1> <p> I am on crusade to get Windows Identity Foundation (WIF) adopted by the Microsoft .NET community at large. Why? Because maintaining a user store within an application as is propagated by ASP.NET Membership is just plain stupid these days. Yes, I may be a little harsh with that judgment, but sparing the rod spoils the child. Applications should no longer be islands, but should be working together. And if applications such as Spotify and Flickr can (re)use a user’s identity from Facebook, Twitter, LinkedIn, and so on, <strong>why can’t yours?</strong> </p> <p> <em>“A thousand mile journey begins with one step” – Lao Tze</em> </p> <p> In the past couple of years I’ve been speaking about WIF on many occasions, both at conference and with individual developers. Across the board I can say that WIF is largely misunderstood. Hence my first step is to address some of the misconceptions surrounding WIF, and more in general the concepts underlying WIF. I’ll follow up with posts showing you (to material on the web) to make it work. </p> <p> <strong>Misconception 1: WIF is Microsoft-only and not interoperable.</strong> <br> WIF actually implements the WS-Federation standard. Microsoft is an active participant in the standards commonly known as the WS-* specifications, a host of web services specifications for security, transactions, and reliable messaging. The WS-Federation standard is implemented by many other platforms, and WIF can interoperate with these just fine. </p> <p> <strong>Misconception 2: WIF can only be used to secure web applications, not web services.</strong> <br> The WS-Federation protocol defines two profiles: Active and Passive. Passive federation is for browser based applications, because browsers don’t support the full cryptographic stack required for WS-Federation to work. Active federation is used for web services and can be used with clients that do support the needed cryptographic capabilities. I’ll get back to what this all means in another post. </p> <p> <strong>Misconception 3: WIF can only be used to secure web services, not web applications.</strong> <br> See misconception #2. </p> <p> <strong>Misconception 4: WIF is only for cloud (Azure) applications.</strong> <br> WIF works with any application written in .NET 3.5 and up. You can host that application anywhere you like, in the cloud or in your own data center. In fact, there is nothing that prevents you from creating applications with WIF for use in just the local network and for internal use only. </p> <p> <strong>Misconception 5: You can’t do role-based security with WIF.</strong> <br> Quite the opposite is true. You can still do role-based security if you want to, but you can do much more. The underlying protocol is much more flexible, and you can implement security checks in your applications based on the information you get about a use any way you like. </p> <p> <strong>Misconception 6: WIF only adds complexity.</strong> <br> It is indeed true that properly connecting a WIF enabled application to a security token service can be a challenge. You need to get the protocol settings to match and need certificates for encryption and signing. However, inside your applications WIF is just as easy as role-based security as you are used to. If you want to do more elaborate things, things obviously get more complex, but this is true for any type of security. </p> <p> <strong>Misconception 7: To use WIF in an existing application I need to re-architect the whole application.</strong> <br> WIF extends the IIdentity and IPrincipal interfaces. This means that your existing application will keep working if you migrate to WIF to get authenticate and authorize the user. The only thing you need to be aware of is the fact that because you don’t have a local user directory anymore, you can’t do things for which you require information about another user. This means you may have to provide a different way to deal with such scenarios. If you use ASP.NET Profiles for th </body>