Home
About
Contact
Friday, June 25, 2010

A few months back I went on a tour with MSDN Live here in Norway talking about WIF and ADFS. These talks where recorded, but only in Norwegian, so I did a screen cast of the same talk in English. This will eventually be available on Channel9, but until then I’ve made it available here.

WIF together with AD FS 2.0 really made it easy to do federation with partner organizations which was exactly what we needed in the company I work for. This talk is however not limited to that scenario, so if your looking for good solutions around Single Sign-On or identity management in general I recommend you check this out.

Friday, June 25, 2010 11:23:00 AM (W. Europe Daylight Time, UTC+02:00)
Monday, April 19, 2010

When working with passive federation you quickly run into Home Realm Discovery (HRD) (I couldn’t help notice that the short name became HRD which reads HARD :-) ). Anyways, HRD is about which identity provider (IP-STS) should authenticate the user and how to properly redirect the user to their home IP-STS. One example where HRD comes into play is when an organization have multiple partners that authenticate using their own internal STS. An example of that is illustrated in Figure1 below:

image
Figure 1

The Default Behavior
Using ADFS 2.0 as RP-STS you will by default be presented with this screen when you have trusts to one or more IP-STS’s:

image
Figure 2

Home Realm Query String
You probably do not want to reveal all of your federated partners like this. A better solution is to add a query string to the application URL where you specify the home realm, like this:

https://someWebApp/?whr=[Home Realm URI)

If the home realm (IP-STS) is ADFS 2.0, and using the URLs from Figure1 above, the URL would be:

https://rp.mydomain.com/?whr=https://ip-sts.partner1domain.com/adfs/services/trust

Let WIF Know About WHR
In order for your RP-STS to receive the whr parameter and automatically redirect the user to his home realm, you need to plug into the WIF pipeline of your application. You can do this very easily by editing your Global.asax.cs and listen to the RedirectingToIdentityProvider event like this:

using Microsoft.IdentityModel.Web;
...
protected void Application_Start(object sender, EventArgs e)
{
    FederatedAuthentication.WSFederationAuthenticationModule.RedirectingToIdentityProvider += new EventHandler<RedirectingToIdentityProviderEventArgs>(WSFederationAuthenticationModule_RedirectingToIdentityProvider);
}
void WSFederationAuthenticationModule_RedirectingToIdentityProvider(object sender, RedirectingToIdentityProviderEventArgs e)
{
    e.SignInRequestMessage.HomeRealm = Request["whr"];
}

Remove The Manual Home Realm Selection From ADFS
The next thing you probably want to do is prevent the RP-STS of displaying its home realm selection page. I didn’t find clear guidance of how to do this, but I found a solution that works. In the ADFS web folder of the RP-STS (C:\inetpub\adfs\ls\) you can edit the HomeRealmDiscovery.aspx and HomeRealmDiscovery.aspx.cs to display a message to the user and remove the dropdown for selecting home realm.

In HomeRealmDiscovery.aspx I removed the <div class="GroupXXLargeMargin"> section and changed the message “The site that you are accessing…” to something more informative. In the HomeRealmDiscovery.aspx.cs page I commented out everything related to the PassiveIdentityProvidersDropDownList control.

<%@ Page Language="C#" MasterPageFile="~/MasterPages/MasterPage.master" AutoEventWireup="true"
CodeFile="HomeRealmDiscovery.aspx.cs"
ValidateRequest="false"
Inherits="HomeRealmDiscovery" Title="Sign In"%>
<%@ Register TagPrefix="adfs" Namespace="Microsoft.IdentityServer.Web.UI" assembly="Microsoft.IdentityServer" %>
<%@ OutputCache Location="None" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
    <script type="text/javascript" src="FederationPassiveJScript.js"></script>
        <div class="GroupXLargeMargin">
            The site that you are accessing requires Home Realm Discovery to sign in. Please contact your system administrator for further details.
        </div>
        <asp:Panel ID="CardSignInPanel" Visible="False" runat="server" CssClass="GroupXXLargeMargin">Or, <a href="#" onclick="InfocardLink_onclick( document.infoCardObject );">sign
        in</a> with an Information Card.
            <adfs:InformationCardControl ID="InformationCard" runat="server"></adfs:InformationCardControl>
            <script>
                AddOnload( LoadCardPanel );
            </script>
        </asp:Panel>
</asp:Content>

HomeRealmDiscovery.aspx

//------------------------------------------------------------
// Copyright (c) Microsoft Corporation.  All rights reserved.
//------------------------------------------------------------
using System;
using Microsoft.IdentityServer.Web.Configuration;
using Microsoft.IdentityServer.Web.UI;
/// <summary>
/// This page enables home realm discovery if this STS is configured to trust multiple claims providers.
///
/// If the persistIdentityProviderInformation setting is enabled and the user has previously
/// selected a claims provider, that claims provider will be used automatically.
/// </summary>
public partial class HomeRealmDiscovery : Microsoft.IdentityServer.Web.UI.HomeRealmDiscoveryPage
{
    protected void Page_Init( object sender, EventArgs e )
    {
        //PassiveIdentityProvidersDropDownList.DataSource = base.ClaimsProviders;
        //PassiveIdentityProvidersDropDownList.DataBind();
        if( IsIssuedTokenViaSelectorEnabled() )
        {
            InformationCard.TokenSubmitted += TokenSubmitted;
            CardSignInPanel.Visible = true;
        }
    }
    private bool IsIssuedTokenViaSelectorEnabled()
    {
        foreach( AuthenticationTypeElement authenticationType in FederationPassiveConfigurationSection.Current.AuthenticationTypes )
        {
            if( authenticationType.Name == "IssuedTokenViaSelector" )
            {
                return true;
            }
        }
        return false;
    }
    protected void TokenSubmitted( object sender, InformationCardControl.TokenSubmittedEventArgs e )
    {
        SignIn( e.Token );
    }
    //protected void PassiveSignInButton_Click( object sender, EventArgs e )
    //{
    //    SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );
    //}
}

HomeRealmDiscovery.aspx.cs

You then get a page like this if no whr is provided:

image  

Anything I can do about that URL?
If you don’t want your users to relate to the rather cryptic URL needed to support HRD there are several ways to make it a bit more user friendly. I will give a few suggestions here, but there are probably other (and maybe better) solutions than I can come up with right now.

  • Provide a shortcut on your users desktop or similar and have them use this to access the application
  • Detect by IP range and redirect to proper IP-STS
  • Provide a nice URL redirect either from the Relying Party (application) or IIS. E.g. https://someWebApp/YourCompany/ redirects to https://rp.mydomain.com/?whr=https://sts.yourCompany.lan/adfs/services/trust

One thing to note if you have the default settings in the web.config file for your RP-STS, specifically the <persistIdentityProviderInformation> set to true, is when a user have been redirected correctly to his/her home realm the RP-STS will issue a cookie to the user which contains the user’s home realm. If the user at a later time access the application from its root URL, he will be automatically redirected to his home realm. This is however only true as long as the cookie has not expired or the user uses the same computer as he did when the cookie was issued. Because of this I prefer sticking to one of the solutions above and not rely on the users having this cookie.

.Net | ADFS | Security | WIF
Monday, April 19, 2010 6:00:00 AM (W. Europe Daylight Time, UTC+02:00)
Saturday, April 17, 2010

Yesterday I had my Windows Identity Foundation (WIF) talk at MSDN Live in Stavanger. My last slide on that talk listed a set of resources to help you get started and understand WIF, Claims based Identity, Federation, Security Token Services (STS) etc, so I thought I’d share them here:

Tools and frameworks

WIF
Shouldn’t be too hard to find, but I provide the link anyways. This is formerly known as the Geneva Framework.

WIF SDK
This SDK will add some nice tooling support to Visual Studio for adding a reference to a Security Token Service (FedUtil). There is also a set of coding examples as part of this download.

AD FS 2.0 RC
Formerly known as Geneva Server, this is Microsoft’s Security Token Service with Active Directory integration.

StarterSTS
This is a open source project created by the security expert Dominick Baier from ThinkTecture. What makes this project interesting (except from using WIF to implement an STS) is that it has full support for the ASP.NET membership provider as well as having a OpenID bridge and a REST endpoint. On this web site you’ll also find a good collection of screen casts by Dominick showing you how to do various things in/with StarterSTS.

Books, whitepapers and coding examples

A Guide to Claims-Based Identity and Access Control (PDF Book)
This is a real must to get a proper understanding of WIF, SSO and Federation. They’ve done a great job explaining these concepts in a simple manner. This without using the many technical terms within the security domain throughout the paper, but rather spend time in the beginning to explain them so you have the proper understanding should you run across these terms in other resources.

Identity Developer Training Kit
This training kit (updated in March) have some great examples of how to do Active and/or Passive federation in ASP.NET, Silverlight, WCF and Azure. Highly recommended learning resource.

A collection of Whitepapers (older but still valuable)
The download includes:

  • David Chappell’s Claims Based Identity for Windows
  • Keith Brown and Sesha Mani’s WIF Whitepaper for Developers
  • Windows Identity Foundation - Changes between Beta 2 and RTW
.Net | ADFS | Security | WIF
Saturday, April 17, 2010 6:00:00 AM (W. Europe Daylight Time, UTC+02:00)
Monday, March 15, 2010

Next coming months I’ll be having a few talks about Single Sign-On (SSO), Windows Identity Foundation (WIF), Active Directory Federation Services 2.0 (AD FS) and Federation.

imageThe IASA talk will be a 1/2 hour high level presentation of how to accomplish Single Sign-On (SSO) across applications and organizations. One of my motivations for heading over to Oslo to do this talk is to hear and meet the other speakers that night as well as attending the Open Space session at the end. Overall topic for the night is “Security in Architecture”.

image At MSDN Live I’ll go more in depth into WIF and how to simplify identity management in and across applications. I will also show AD FS, but more as a simple way of setting up a Security Token Service (STS) and not go into the inner workings of AD FS. At MSDN there’s a great variety of talks, so check out the agenda!

Hope to see you there!

Monday, March 15, 2010 7:00:00 AM (W. Europe Standard Time, UTC+01:00)
Sunday, May 17, 2009

image When so called secure institutions like banks, insurance companies and others ask you to create a password, you expect them to allow strange characters like ,.$#@{}[] to make the password stronger. To my surprise on several occasions I’ve experienced that they did not accept other than plain letters and numbers! What!? Didn’t the developer that implemented that logic raise a flag??

One specific case is with BankId (a national authentication mechanism for all banks in Norway), where I know the underlying implementation support strong passwords. However, when prompted by my bank to create the password, you’re not permitted. Actually I had to type in a temporary weak password and then change the password in the login screen which support the expected behavior!

At some point there had to be a discussion like this:

Developer: What type of password should we support?

Product Owner: What do you mean?

Developer: Should we allow people to make up their password from everything that they can find on their keyboard?

Product Owner: No, the normal alphabet and numbers should be sufficient. Or else people just forget their passwords.

My above experience with BankId was just an example from today, and in that case there were a workaround, which is not the common case. I always get puzzled when this happens. What puzzles me even more is that to prevent people from entering strong password, you actually have to code a business rule for exactly that! And what about those who only permit numbers!? What’s that all about?

Sorry for this rant, but I think it is important that we as developers, architects and technically skilled people take responsibility to avoid stuff like this to happen. I just can’t see one single good reason for limiting the users choice when it comes to passwords.

Sunday, May 17, 2009 4:48:33 PM (W. Europe Daylight Time, UTC+02:00)
Monday, October 06, 2008

This is my third post in my WiX and DTF series for WiX 3.0. Here are some others I’ve written:

Normally bootstrappers are used for adding prerequisites to your installation; like the .Net Framework, Windows Installer etc. You can also use it for other purposes though. Basically it's an exe file with the msi (and any other installers) embedded. For the WiX series I'm currently doing we need this because:

  1. Use as workaround for the WiX bug in IIS extension where the installer fails because of missing privileges on Vista SP1.
  2. We want to do IIS custom actions in InstallUISequence which require elevated privileges which I will cover in a later post (hopefully very soon!).

I briefly mentioned InstallUISequence above. Windows Installer have several sequences, for details you can check them out here, but I'm just going to shortly explain two of them now. The InstallUISequence is the wizard part in the installer, InstallExecuteSequence is where things are happening and files are getting installed (when you click "Install" in the wizard).

Here's a bit of background. In Vista msi files does not run elevated (as admin) when you start them directly (double click on the msi). To do that you need to open an elevated command prompt and run the msi with msiexec /i yourInstaller.msi. That's not a good solution.

Normally there should be no need for admin privileges in UISequence (it's a reason it's not permitted per default), but there are exceptions, like the above. At least from my perspective. If you have a better way of solving this, I'm very interested.

So, with a bootstrapper or exe file you can do a bit more. For instance you can use mt.exe to add a manifest to he exe defining which privileges it requires to run. In this article I will describe how you can accomplish this using WiX and .Net.

Here's how to go about it:

  1. Copy Setup.exe found in the WiX bin folder to your project location (so we don't modify the original)
  2. Create a manifest file (e.g. Vista.manifest) in your favorite text editor by adding this xml:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    
      <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="Setup" type="win32" />
    
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    
        <security>
    
          <requestedPrivileges>
    
            <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
    
          </requestedPrivileges>
    
        </security>
    
      </trustInfo>
    
    </assembly>
  3. Add the manifest to Setup.exe by using mt.exe found in the .Net SDK:

    mt.exe -manifest [pathToYourProject\]Vista.manifest -outputresource:[pathToYourProject\]Setup.exe;#1

  4. Use setupbld.exe found in the WiX bin folder to embed the msi installer into a exe like this:

    setupbld.exe" -out Setup.exe -msu MyMsi.msi -setup Setup.exe

    or even better, add it as a post-build event (Right click your project -> Properties -> Build Event -> Post-build Event Command Line):

    "C:\Program Files\Windows Installer XML v3\bin\setupbld.exe" -out $(TargetDir)Setup.exe -msu "$(TargetPath)" -setup "$(ProjectDir)setup.exe"

The interesting thing to note about the manifest file is this:

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

When setting the level to requireAdministrator Vista will show a UAC prompt when executing this file. The default level is asInvoker, which will run the exe with the current users privileges, but then the exe would have the same behavior as the msi.

Also note the assemblyIdentity node where you can set the actual version number of your installer and the name (if you use something else than Setup.exe).

.Net | Deployment | Security | Vista | WiX
Monday, October 06, 2008 12:47:02 PM (W. Europe Daylight Time, UTC+02:00)
Sunday, September 14, 2008

openid I've updated my DasBlog to version 2.2.8252.15582 and it has OpenID support! If you have an OpenID you can now use that for posting comments to my blog. I'm not taking the same stand as Aaron Hockley though, refusing to comment on blogs without OpenID support (at least not yet...).

So why use OpenID except from identifying yourself on my blog? :-) The number one reason as I see it is that you have one ID to identify yourself across multiple web sites. This will remove the need for "forgot your password?" links, your favorite pet etc. Also that you rely on one provider for your id that you trust (hopefully) and don't have to "give away" passwords, which you probably only have a few of, using them on all the different accounts you're creating around the Internet.

When you sign into a site using OpenID you get redirected to your provider for authentication. Here you can choose how much information you want to submit about yourself to the site you're logging on to. E.g. you may chose to send no information at all, just your name or email etc.

If you want to know more about OpenID and how it works, check out openid.net. Scott Hanselman has a Weekly Source Code edition of OpenID and also a podcast.

Don't have OpenID? I use myOpenId.com where I've also added my domain (torresdal.net), allowing me to use that instead of [myname].myopenid.com. My id is jon.torresdal.net. Another popular way of using your ID is to map it to your web site. Below is an example from my web site using myopenid.com:

    <link rel="openid.server" href="http://www.myopenid.com/server" />
    <link rel="openid.delegate" href="http://torresdal.myopenid.com/" />
    <link rel="openid2.local_id" href="http://torresdal.myopenid.com" />
    <link rel="openid2.provider" href="http://www.myopenid.com/server" />
    <meta http-equiv="X-XRDS-Location" 
          content="http://www.myopenid.com/xrds?username=torresdal" />

This way I can use blog.torresdal.net as my id. However, one side effect of this is that many blog engines use the name before the dot as your name. If I use my blog url as identifier on e.g. a blog hosted by blogger.com, the comment will say "blog said...", which is not very helpful.

I mentioned myopenid.com, but there are several other suppliers out there. Just Google openid and you'll find many.

PS! All comments to this blog post is expected to use OpenId! :-)

Sunday, September 14, 2008 10:11:58 PM (W. Europe Daylight Time, UTC+02:00)
RSS RSS - Comments Twitter LinkedIn
         
SEARCH
 
 
         
TOP POSTS
   
         
NAVIGATION
   
         
CATEGORIES
  .Net (61) ADFS (3) Agile (30) Ajax (5) Architecture (20) Articles (1) ASP.NET (6) ASP.NET-MVC (1) Blogging (12) Books (2) BPEL (1) CleanCode (1) CloudComputing (7) Community (4) CSharp (11) DasBlog (5) Database (2) DDD (5) Deployment (16) DSL (1) Events (38) ExtremeProgramming (6) Fun (6) Gadgets (4) IIS (10) InfoQ (4) Java (2) Lean (3) Linq (2) MemoryLeaks (5) Microsoft (37) MVC (1) NDC (2) NNUG (36) Other (10) Patterns (9) Performance (3) Scrum (17) Security (7) ServiceBus (1) Silverlight (4) Software (19) TeamManagement (11) TechEd (7) Testing (4) Tools (25) TvGuide (1) WCF (8) Web (15) WebDeploy (1) WIF (3) Windows (10) Vista (15) VisualStudio (16) WiX (9) Work (16) Workflow (3)  
         
ARCHIVE
   
         
BLOGROLL
   
         
ON THIS PAGE...
 
Screen Cast: Windows Identity Foundation and Active Directory Federation Services
Home Realm Discovery In WIF And ADFS 2.0 By Query String
Some useful WIF resources
Talks
Password Security Annoyances
WiX and DTF: Using a bootstrapper to force elevated privileges in Vista
OpenID support