Programming Windows® Identity Foundation (Dev - Pro)

Category: Operating Systems
Author: Vittorio Bertocci
All Stack Overflow 8
This Month Stack Overflow 4


by anonymous   2019-07-21

In most cases you don't need to worry about the token validation details. All this is taken care for you by WIF.

But if you really want to know, the best source of information is Vittorio's book:

There are some details here:

Another good way of learning is by looking at the extensions built to handle non-SAML tokens (e.g SWT). Download the samples here and look for the REST services.

by anonymous   2019-07-21

The ADFS 2 sounds like a perfect choice for you. It is a free subsystem implementing the WS-Federation SSO protocol. The protocol itself is a standard from the WS-* family which means that you can easily find toolkits to support authentication in any client technology (.NET, PHP, Java).

Technically, ADFS 2 is a web application running on IIS 7.5/Windows Server 2008 and uses Active Directory as a backend.

There are good books on the WS-Federation protocol programming:

Claims Based Identity and Access Control (free ebook)

Programming Windows Identity Foundation

by anonymous   2017-08-20

I would argue you shouldn't care :-), but we are curious, aren't we? And there's value in knowing how things actually work.

The validation happens on the app with no contact with the STS (e.g. ADFS), that's because in general, the token is digitally signed (and optionally encrypted) and WIF has all the information and means to check the integrity of it.

A great source of WIF internals can be found in Vittorio's book:

There's a lot of information on how all the modules interact and work.

by anonymous   2017-08-20

Well, it could be that one of passive single sign-on protocols could be your choice. You can choose between the WS-Federation, SAML protocol or Shibboleth but the first one, WS-Federation is easily supported on .NET with the Windows Indentity Foundation subsystem.

The way WS-Federation works is that it you externalize the authentication/authorization to a separate web application (so called Security Token Service). Each of federated client applications (so called Relying Parties) rely on the information provided by the service.

The basic control flows is like this:

  1. the client points his/her browser to a RP application
  2. the browser redirects (302) to the STS
  3. if STS was visited and the user is already logged into the STS go to 5.
  4. STS shows the login page and validates the user
  5. STS returns to the browser a page containing a signed XML token with all the auth information as well as a tiny javascript to redirect to the RP application
  6. the RP application picks up the token and creates its own authentication based on the provided information

WIF gives you tools to build both STSes and RPs easily and integration of legacy application is also simple - you can either make an effort to handle the protocol at the legacy application level or provide a "brige", a .NET application using WIF which relies on STS and passes the auth information to the legacy application.

What is also great is that with WIF you still stick with old, good notions like Forms Authentication and Membership Providers - it could be a preferred choice of STS implementation.

The WS-Federation protocol itself not only provides the single sign-on but also lets you easily handle single sign off (which is not supported by some other protocols like openid).

Read more on the topic in this book:

by anonymous   2017-08-20

There's also:

Programming Windows Identity Foundation

If you want Windows Live or Google logins, you need to look at integrating WIF with Azure ACS.

Refer Access Control Service Samples and Documentation.

Also see the how-to's etc. in the TechNet Wiki Windows Identity Foundation (WIF) and Azure AppFabric Access Control Service (ACS) Content Map and Windows Identity Foundation (WIF) Content Map.