Getting Up-to-Speed with WS-Federation and WS-Trust

09.04.2012 12:58 by kbeckman | Comments

As part of a recent client request, I’ve been asked to provide a list of resources that an organization can use to become familiar with the technologies and protocols behind enterprise Single Sign-On (SSO) and Federated Identity. Single Sign-On between enterprises is a difficult topic, especially when you get to scenarios beyond the initial user authentication. Trust me, there’s a lot more to think about organizationally than just accepting authenticated users from other security domains. The topic of Federated Identity forces organizations to think of users in terms of a global identity rather than a single account in some enterprise application. Users from the local security domain may or may not be treated differently than users from trusted partners. Application authorization rules may differ based on where your user actually authenticated…

 

The protocols at the core of enterprise SSO are WS-Federation and WS-Trust. At a high-level, WS-Federation defines the transport mechanism for security tokens and WS-Trust defines the procedures for signing, encrypting, validating and renewing authentication tokens. Another popular protocol is SAML 2.0 / SAML-P. [Sorry for the Wikipedia links… I have a better list of resources shortly.] Without getting into the details, there are a lot of functional similarities between WS-Fed and SAML-P… However, the differences are painful enough that we’re going to leave the SAML story for another day (or hopefully never).

 

Microsoft’s implementation of WS-Federation comes in the form of Windows Identity Foundation (WIF) – a subset of the .NET Framework that contains the types and classes for managing identity. Once a standalone extension to the .NET Framework, WIF is now included in the mscorlib. Below are some valuable resources to help you get started with WS-Federation, WS-Trust and WIF.

 

For Business Folks [and Developers Before They Start Developing]…

  • Understanding WS-Federation – This is an MSDN article from back in 2007 (pre-WIF) that describes WS-Federation and it’s sub-protocols (WS-Trust, WS-Security, WS-SecurityPolicy). Brace yourself… The article leads off with a copyright notice and never really recovers.
  • A Guide to Claims-Based Identity and Access Control, 2nd Edition – In my opinion, this is the best resource for explaining SSO and Federated Identity across enterprises. With each chapter, the authors setup an enterprise scenario and explain the interactions required by participating organizations to accomplish SSO. More importantly though, this book goes into detail to explain the business problems solved by SSO implementations. Developers will get a lot from this too as it touches on all of the Microsoft technology offerings that are either necessary or helpful in pulling off SSO – ASP.NET, WIF, Active Directory Federation Services 2.0, and Windows Azure Access Control Service.

For Developers…

 

For ‘Only the Lonely’

If you haven’t gotten your fill from the resources above, you can always take a look at the official OASIS protocol specs. Although I don’t advise this unless you’re working on your own framework or plug-in, etc.

ASP.NET Authorization Configuration with WIF

02.23.2011 06:45 by kbeckman | Comments

I recently ran into an issue after using Windows Identity Foundation (WIF) to modify an existing ASP.NET application as a Relying Party to use a Secure Token Service (Identity Provider) rather than using traditional ASP.NET Forms Authentication. I began by applying a very aggressive ASP.NET authorization configuration to the entire site. I locked-down the site disallowing any anonymous access using the <authorization> element in the <system.web> section. Not all areas of the site required restricted access so <location> tags were used to allow anonymous access to certain folders and page resources. Everything seemed to be functioning exactly as desired. It worked; It was secure; and it restricted access to secure areas of the application to anyone who hadn’t first authenticated against the Identity Provider. All is well!

 

Then one day a defect crosses my inbox… Our QA analyst was testing the custom errors pages on the site. Without authenticating, she purposefully entered an incorrect URL expecting to see our custom error page for HTTP 404 errors. Instead, she was redirected to our Identity Provider for authentication. After authentication, she was correctly redirected back to the site and to the 404 custom error page… This wasn’t the desired behavior as she shouldn’t have had to authenticate before redirecting to the custom error page.

 

So what’s the deal? The problem was that as a default behavior, the entire site was configured to require WIF authentication. This is also the case for non-existent resources that produce HTTP 404 errors. Following is a sample of the web.config file elements that are of interest here. This is how the site was originally configured.

 

<system.web>
    <authorization>
        <deny users="?"/>
    </authorization>
</system.web>

<location path="SomeAnonymousResource.aspx">
    <system.web>
        <authorization>
            <allow users="*"/>
        </authorization>
    </system.web>
</location>

<location path="SomeAnonymousFolder">
    <system.web>
        <authorization>
            <allow users="*"/>
        </authorization>
    </system.web>
</location>

 

Here’s what the configuration elements look like now… I’ve replaced the aggressive authorization restrictions at the site root with a more targeted approach restricting access only as necessary. Instead of <location> elements to allow anonymous access for resources, there are <location> elements for restricting secure parts of the application. Problem solved – no more redirects for authentication just to end up at the 404 custom error page.

 

<system.web>
    <authorization>
        <allow users="*"/>
    </authorization>
</system.web>

<location path="SomeSecureResource.aspx">
    <system.web>
        <authorization>
            <deny users="?"/>
        </authorization>
    </system.web>
</location>

<location path="SomeSecureFolder">
    <system.web>
        <authorization>
            <deny users="?"/>
        </authorization>
    </system.web>
</location>