Home / My Disclaimer / Who am I? / Search... / Sign in

// Security

Security Leaks, Software Updates

by Steve Syfuhs / December 13, 2010 04:00 PM

[My opinions are probably different than those of my employer.  Have a grain of salt handy, please.]

Sorry, but when a twitter client starts making fun of a politically charged security issue (WikiLeaks), the problem is a bit more trivial than most people are willing to admit.

metroTwitUpdate

At least, from the technology perspective.  When you get right down to it, technology is not what caused the breach of classified diplomatic cables.  People had to leak the stuff.  Period.

That’s what I find so funny about the screenshot.  So many companies are bound to find an in because they can now market their product as a way to deter these types of leaks, and they’ll market it as a full solution meaning it will solve every problem under the sun.

MetroTwit obviously had their tongue's planted firmly in cheek when they labelled their update, but they made fun of what so many companies will do in the future: label their product/feature/service as a security solution.

There is no practical solution to security when people are involved.  Just lots of little fixes and maybe a little bit of planning. 

Actually, a lot more planning might solve a number of those little fixes.

Preventing Frame Exploits in a Passive Claims Model

by Steve Syfuhs / November 30, 2010 04:00 PM

At a presentation a few weeks ago someone asked me about capturing session details during authentication at an STS by way of frames and JavaScript.  To paraphrase the question: “What prevents a malicious developer from sticking an RP within an iframe, cause a redirect to an STS, get some user to log in, and then capture the details through JavaScript from the parent page?”  There are a couple of ways this problem can be solved.  It’s a defense-in-depth problem where on their own, each piece won’t close every attack vector, but when used together you end up with a pretty solid solution.

  • First, a lot of new browsers will actually prevent cross-frame JavaScript calls when SSL is involved.  Depending on the browser, the JavaScript will throw the equivalent of an Access Denied exception.  This is not the case with all browser versions though.  Older browsers may not do this.
  • Second, some browsers will not allow you to host an SSL page in a frame if the parent page is not using SSL.  The easy fix for the malicious developer is to simply use SSL for the parent site, but that could be problematic as the CA’s theoretically verify the sites requesting certificates.
  • Third, you could write some JavaScript for the STS to bust out of the frame.  It would look something like this:

if (top != self)
{
    try
    {
        top.location.replace(self.location.href);
    }
    catch (e)
    {
    }
}

The problem with this is that it wouldn’t work if the browser has JavaScript disabled.

  • Fourth, there is a new HTTP header that Microsoft introduced in IE 8 that tells the browser that if the requested page is hosted in a frame to simply stop processing the request.  Safari and Chrome support it natively, and Firefox supports it with the NoScript add on.  The header is called X-Frame-Options and it can have two values: “DENY” which prevents all requests, and “SAMEORIGIN” which allows a page to be rendered if the parent page is the same page.  E.g. the parent is somesite.com/page and the framed page is somesite.com/page.

There are a couple of ways to add this header to your page.  First you can add it via ASP.NET:

Context.Response.AddHeader("x-frame-options", "DENY");

Or you could add it to all pages via IIS.  To do this open the IIS Manager and select the site in question.  Then select the Feature “HTTP Response Headers”:

image

Select Add… and then set the name to x-frame-options and the value to DENY:

image

By keeping in mind these options you can do a lot to prevent any exploits that use frames.

The Basics of Building a Security Token Service

by Steve Syfuhs / October 29, 2010 04:00 PM

Last week at TechDays in Toronto I ran into a fellow I worked with while I was at Woodbine.  He works with a consulting firm Woodbine uses, and he caught my session on Windows Identity Foundation.  His thoughts were (essentially—paraphrased) that the principle of Claims Authentication was sound and a good idea, however implementing it requires a major investment.  Yes.  Absolutely.  You will essentially be adding a new tier to the application.  Hmm.  I’m not sure if I can get away with that analogy.  It will certainly feel like you are adding a new tier anyway.

What strikes me as the main investment is the Security Token Service.  When you break it down, there are a lot of moving parts in an STS.  In a previous post I asked what it would take to create something similar to ADFS 2.  I said it would be fairly straightforward, and broke down the parts as well as what would be required of them.  I listed:

  • Token Services
  • A Windows Authentication end-point
  • An Attribute store-property-to-claim mapper (maps any LDAP properties to any claim types)
  • An application management tool (MMC snap-in and PowerShell cmdlets)
  • Proxy Services (Allows requests to pass NAT’ed zones)

These aren’t all that hard to develop.  With the exception of the proxy services and token service itself, there’s a good chance we have created something similar to each one if user authentication is part of an application.  We have the authentication endpoint: a login form to do SQL Authentication, or the Windows Authentication Provider for ASP.NET.  We have the attribute store and something like a claims mapper: Active Directory, SQL databases, etc.  We even have an application management tool: anything you used to manage users in the first place.  This certainly doesn’t get us all the way there, but they are good starting points.

Going back to my first point, the STS is probably the biggest investment.  However, it’s kind of trivial to create an STS using WIF.  I say that with a big warning though: an STS is a security system.  Securing such a system is NOT trivial.  Writing your own STS probably isn’t the best way to approach this.  You would probably be better off to use an STS like ADFS.  With that being said it’s good to know what goes into building an STS, and if you really do have the proper resources to develop one, as well as do proper security testing (you probably wouldn’t be reading this article on how to do it in that case…), go for it.

For the sake of simplicity I’ll be going through the Fabrikam Shipping demo code since they did a great job of creating a simple STS.  The fun bits are in the Fabrikam.IPSts project under the Identity folder.  The files we want to look at are CustomSecurityTokenService.cs, CustomSecurityTokenServiceConfiguration.cs, and the default.aspx code file.  I’m not sure I like the term “configuration”, as the way this is built strikes me as factory-ish.

image

The process is pretty simple.  A request is made to default.aspx which passes the request to FederatedPassiveSecurityTokenServiceOperations.ProcessRequest() as well as a newly instantiated CustomSecurityTokenService object by calling CustomSecurityTokenServiceConfiguration.Current.CreateSecurityTokenService().

The configuration class contains configuration data for the STS (hence the name) like the signing certificate, but it also instantiates an instance of the STS using the configuration.  The code for is simple:

namespace Microsoft.Samples.DPE.Fabrikam.IPSts
{
    using Microsoft.IdentityModel.Configuration;
    using Microsoft.IdentityModel.SecurityTokenService;

    internal class CustomSecurityTokenServiceConfiguration
: SecurityTokenServiceConfiguration
    {
        private static CustomSecurityTokenServiceConfiguration current;

        private CustomSecurityTokenServiceConfiguration()
        {
            this.SecurityTokenService = typeof(CustomSecurityTokenService);
            this.SigningCredentials =
new X509SigningCredentials(this.ServiceCertificate);
            this.TokenIssuerName = "https://ipsts.fabrikam.com/";
        }

        public static CustomSecurityTokenServiceConfiguration Current
        {
            get
            {
                if (current == null)
                {
                    current = new CustomSecurityTokenServiceConfiguration();
                }

                return current;
            }
        }
    }
}

It has a base type of SecurityTokenServiceConfiguration and all it does is set the custom type for the new STS, the certificate used for signing, and the issuer name.  It then lets the base class handle the rest.  Then there is the STS itself.  It’s dead simple.  The custom class has a base type of SecurityTokenService and overrides a couple methods.  The important method it overrides is GetOutputClaimsIdentity():

protected override IClaimsIdentity GetOutputClaimsIdentity(
IClaimsPrincipal principal, RequestSecurityToken request, Scope scope)
{
    var inputIdentity = (IClaimsIdentity)principal.Identity;

    Claim name = inputIdentity.Claims.Single(claim =>
claim.ClaimType == ClaimTypes.Name);
    Claim email = new Claim(ClaimTypes.Email,
Membership.Provider.GetUser(name.Value, false).Email);
    string[] roles = Roles.Provider.GetRolesForUser(name.Value);

    var issuedIdentity = new ClaimsIdentity();
    issuedIdentity.Claims.Add(name);
    issuedIdentity.Claims.Add(email);

    foreach (var role in roles)
    {
        var roleClaim = new Claim(ClaimTypes.Role, role);
        issuedIdentity.Claims.Add(roleClaim);
    }

    return issuedIdentity;
}

It gets the authenticated user, grabs all the roles from the RolesProvider, and generates a bunch of claims then returns the identity.  Pretty simple.

At this point you’ve just moved the authentication and Roles stuff away from the application.  Nothing has really changed data-wise.  If you only cared about roles, name, and email you are done.  If you needed something more you could easily add in the logic to grab the values you needed. 

By no means is this production ready, but it is a good basis for how the STS creates claims.

Kerberos: Very Claims-y

by Steve Syfuhs / October 24, 2010 04:00 PM

I’ve always found Kerberos to be an interesting protocol.  It works by way of a trusted third party which issues secured tickets based on an authentication or previous session.   These tickets are used as proof of identity by asserting that the subject is who they claim to be. Claims authentication works on a similar principle, except instead of a ticket you have a token.  There are some major differences in implementation, but the theory is the same.  One of the reasons I find it interesting is that Kerberos was originally developed in 1983, and the underlying protocol called the Needham-Schroeder protocol, was originally published in 1978.

There have been major updates over the years, as well as a change to fix a man-in-the-middle attack in the Needham-Schroeder protocol in 1995, but the theory is still sound.  Kerberos is the main protocol used in Windows networks to authenticate against Active Directory.

The reason I bring it up is because of a comment I made in a previous post.  I made an assertion that we don’t necessarily abstract out the identity portion of our applications and services. 

Well, It occurred to me that up until a certain period of time, we did.  In many environments there was only one trusted authority for identity.  Whether it was at a school, in a business, or within the government there was no concept of federation.  The walls we created were for a very good reason.  The applications and websites we created were siloed and the information didn’t need to be shared.  As such, we created our own identity stores in databases and LDAP directories.

This isn’t necessarily a problem because we built these applications on top of a foundation that wasn’t designed for identity.  The internet was for all intents and purposes designed for anonymity.  But here is where the foundation became tricky: it boomed.

People wanted to share information between websites and applications, but the data couldn’t be correlated back to the user across applications.  We are starting to catch up, but it’s a slow process.

So here is the question: we started with a relatively abstract process of authentication by way of the Kerberos third party, and then moved to siloed identity data.  Why did we lose the abstraction?  Or more precisely, during this boom, why did we allow our applications to lose this abstraction?

Food for thought on this early Monday.

What makes Claims Based Authentication Secure?

by Steve Syfuhs / October 17, 2010 04:00 PM

Update: I should have mentioned this when I first posted, but some of these thoughts are the result of me reading Programming Windows Identity Foundation.  While I hope I haven’t copied the ideas outright, I believe the interpretation is unique-ish. Smile

One of the main reasons we as developers shy away from new technologies is because we are afraid of it.  As we learned in elementary school, the reason we are afraid usually boils down to not having enough information about the topic.  I’ve found this especially true with anything security related.  So, lets think about something for a minute.

I’m not entirely sure how valid a method this is for measure, but I like to think that as developers we measure our understanding of something by how much we abstract away the problems it creates.  Now let me ask you this question:

How much of an abstraction layer do we create for identity?

Arguably very little because in most cases we half-ass it.

I say this knowing full well I’m extremely guilty of it.  Sure, I’d create a User class and populate with application specific data, but to populate the object I would call Active Directory or SQL directly.  That created a tightly coupled dependency between the application and the user store.  That works perfectly up until you need to migrate those users in a SQL database to Active Directory.  Oops.

So why do we do this?

My reason for doing this is pretty simple.  I didn’t know any better.  The reason I didn’t know better was also pretty simple.  Of the available options to abstract away the identity I didn’t understand how the technology worked, or more likely, I didn’t trust it.  Claims based authentication is a perfect example of this.  I thought to myself when I first came across this: “are you nuts?  You want me to hand over authentication to someone else and then I have to trust them that what they give me is valid?  I don’t think so.”

Well, yes actually.

Authentication, identification, and authorization are simply processes in the grand scheme of an application lifecycle.  They are privileged, but that just means we need to be careful about it.  Fear, as it turns out, is the number one reason why we don’t abstract this part out.*

With that, I thought it would be a perfect opportunity to take a look at a few of the reasons why Claims based authentication is reasonably secure.  I would also like to take this time to compare some of these reasons to why our current methods of user authentication are usually done wrong.

Source

First and foremost we trust the source.  Obviously a bank isn’t going to accept a handwritten piece of paper with my name on it as proof that I am me.  It stands to reason that you aren’t going to accept an identity from some random 3rd party provider for important proof of identity.

Encryption + SSL

The connection between RP and STS is over SSL.  Therefore no man in the middle attacks.  Then you encrypt the token.  Much like the SSL connection, the STS encrypts the payload with the RP’s public key, which only the RP can decrypt with its private key.  If you don’t use SSL anyone eavesdropping on the connection still can’t read the payload.  Also, the STS usually keeps a local copy of the certificate for token encryption.

How many of us encrypt our SQL connections when verifying  the user’s password?  How many of us use secured LDAP queries to Active Directory?  How many of us encrypt our web services?  I usually forget to.

Audience whitelist

Most commercial STS applications require that each request come from an approved Relying Party.  Moreover, most of those applications require that the endpoint that it responds to also be on an approved list.  You could probably fake it through DNS poisoning, but the certificates used for encryption and SSL would prevent you from doing anything meaningful since you couldn’t decrypt the token.

Do we verify the identity of the application requesting information from the SQL database?  Not usually the application.  However, we could do it via Kerberos impersonation.  E.g. lock down the specific data to the currently logged in/impersonated user.

Expiration and Duplication Prevention

All tokens have authentication timestamps.  They also normally have expiration timestamps.  Therefore they have a window of time that defines how long they are valid.  It is up to the application accepting the token to make sure the window is still acceptable, but it is still an opportunity for verification.  This also gives us the opportunity to prevent replay attacks.  All we have to do is keep track of all incoming tokens within the valid time window and see if the tokens repeat.  If so, we reject them.

There isn’t much we can do in a traditional setting to prevent this from happening.  If someone eavesdrops on the connection and grabs the username/password between the browser and your application, game over.  They don’t need to spoof anything.  They have the credentials.  SSL can fix this problem pretty easily though.

Integrity

Once the token has been created by the STS, it will be signed by the STS’s private key.  If the token is modified in any way the signature wont match.  Since it is being signed by the private key of the STS, only the STS can resign it, however anyone can verify the signature through the STS’s public key.  And since it’s a certificate for the STS, we can use it as strong proof that the STS is who they say they are.  For a good primer on public key/private key stuff check out Wikipedia.

It's pretty tricky to modify payloads between SQL and an application, but it is certainly possible.  Since we don’t usually encrypt the connections (I am guilty of this daily – It’s something I need to work on Winking smile), intercepting packets and modifying them on the fly is possible.  There isn’t really a way to verify if the payload has been tampered with.

Sure, there is a level of trust between the data source and the application if they are both within the same datacenter, but what if it’s being hosted offsite by a 3rd party?  There is always going to be a situation where integrity can become an issue.  The question at that point then is: how much do you trust the source, as well as the connection to the source?

Authentication Level

Finally, if we are willing to accept that each item above increases the security and validity of the identity, there is really only one thing left to make sure is acceptable.  How was the user authenticated?  Username/password, Kerberos, smart card/certificates, etc.  If we aren’t happy with how they were authenticated, we don’t accept the token.

So now that we have a pretty strong basis for what makes the tokens containing claims as well as the relationship between the RP’s and STS’s secure, we don’t really need to fear the Claims model.

Now we just need to figure out how to replace our old code with the identity abstraction. Smile

* Strictly anecdotal evidence, mind you.

Managing Identity in SharePoint

by Steve Syfuhs / October 14, 2010 04:00 PM

Yet another presentation on the docket!  I submitted an abstract to SharePoint Summit 2011 and they accepted!  I will be presenting on SharePoint and how it manages Identity.  More specifically, how SharePoint 2010 uses WIF to handle Claims based authentication and Federation.

Here are the details

Event: SharePoint Summit 2011, January 31st 2011 – February 2nd, 2011

When: 11:30 a.m. - 12:45 p.m. February 1st, 2011

Where: Four Seasons Hotel, Toronto

Abstract: Managing identities within an organization is relatively easy. However, as business changes, we need to be able to adapt quickly. Identity is something that often gets overlooked in adaptation. In this session we will discuss the Windows Identity Foundation and how SharePoint uses it to adapt easily to change.

Link: http://www.sharepointsummit2011.com/Toronto/conference_day2.htm#session_7_3

Presenting a TechDays Local Flavours Track Session!

by Steve Syfuhs / October 13, 2010 04:00 PM

Earlier this morning I got an email from John Bristowe congratulating me on being selected to present a session for the local flavours track at TechDays in Toronto!  This bumps up my count to 2.  Needless to say I am REALLY excited.

I was a little disappointed to find out there weren’t any sessions on the Windows Identity Foundation, so that just meant I had to submit my own to the local flavours track…and they accepted it!  Here are the details:

October 27, 3:40 PM to 4:45 PM

Breakout | LFT330: Windows Identity Foundation Simplified: All the Scary Things Made Un-Scary

The Windows Identity Foundation helps simplify user access for developers by externalizing user access from applications via claims and reducing development effort with pre-built security logic and integrated .NET tools. This presentation is an intimate discussion on the basics of the Windows Identity Foundation and its claims model. In this session, you’ll learn how to refactor an existing sample set of applications to use WIF, to connect identities to the Cloud, and to remove the burden of managing multiple disparate user stores.

Location: Metro Toronto Convention Centre - South Building (255 Front Street West, Toronto)

Room: TBA

image

Defending Against Extremely Persistent Storage

by Steve Syfuhs / September 21, 2010 04:00 PM

There are times when you need to question what you are doing, and why you are doing it.  Take for instance the “evercookie” at http://samy.pl/evercookie/.  I came across this when Kevin Dente posted a link to it on Twitter.

The jist of it is to use all the available resources of the browser and it’s plugins to create a truly persistent cookie across browser resets and cookie cleanups.  I’ll admit, it’s kind of a neat idea, but realistically, it will only be used for bad.  As Kevin said, no good can come of this.

Now, nothing is ever truly persistent when it comes to browsers.  At some point you can clean everything.  The problem is the plugins.  Flash is…well, I hate Flash.  It is an abomination.  Then there is Silverlight.  Plus Java, and any plugin or ActiveX control that ties into the browser that stores data locally.

While I could get into the privacy and security debate over all of this, what it really boils down to is that it’s just really annoying.  I don’t want websites keeping persistent data on my machine if I don’t want them to.  It’s my PC, not theirs.

So I’ve started work on a little script.  It will clear cache of IE 7+ and delete all persistent storage for Flash, Java, and Silverlight.

Keep in mind this will delete your history as well!

RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 2
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 1
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 16
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 32
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 255
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 4351

cd %appdata%
cd "Macromedia\Flash Player\"
rmdir "#SharedObjects" /S /Q

cd %appdata%
cd "Macromedia\Flash Player\macromedia.com\support\flashplayer\"
rmdir "sys" /S /Q

cd "C:\Program Files (x86)\Java\jre6\bin"
javaws -Xclearcache -silent -Xnosplash

cd "%userprofile%"
cd AppData\LocalLow\Microsoft\Silverlight"
rmdir "is" /S /Q

Now, I should also give a word of caution.  This is by no means a sure-fire way to protect your privacy.  That’s pretty hard to do.  This is only designed to do a very simple cleanup of the usual suspects.  If you are really wanting to keep your browsing anonymous, turn off all plugins, turn off all scripting, and run in InPrivate Browsing mode.

I’ll update the script as necessary over time.

Modifying and Securing the ADFS 2 Web Application

by Steve Syfuhs / September 12, 2010 04:00 PM

When you install an instance of Active Directory Federation Services v2, amongst other things it will create a website within IIS to use as it’s Secure Token Service.  This is sort of fundamental to the whole design.  There are some interesting things to note about the situation though.

When Microsoft (or any ISV really) releases a new application or server that has a website attached to it, they usually deliver it in a precompiled form, so all we do is point IIS to the binaries and config files and we go from there.  This serves a number of purposes usually along the lines of performance, Intellectual Property protection, defense in depth protection, etc.  Interestingly though, when the installer creates the application for us in IIS, it drops source code instead of a bunch of assemblies.

There is a valid reason for this.

It gives us the opportunity to do a couple things.  First, we can inspect the code.  Second, we can easily modify the code.  Annoyingly, they don’t give us a Visual Studio project to do so.  Let’s create one then.

First off, lets take a look at what was created by the installer.  By default it drops the files in c:\inetpub\adfs\ls.  We are given a few files and folders:

image

There isn’t much to it.  These files only contain a few lines of code.  Next we create the actual project.

DISCLAIMER:  I will not be held responsible if things break or the server steals your soul.  Please do NOT (I REPEAT) do NOT do this with production servers please!  (Notice I said please twice?)

Since we want to create a Visual Studio project, and since ADFS cannot be installed on a workstation, we have two options:

  1. Install Visual Studio on the server running ADFS
  2. Copy the files to your local machine

Each options have their tradeoffs.  The first requires a bit of a major overhaul of your development environment.  It’s very similar to SharePoint 2007 development.  The second option makes developing a lot easier, but testing is a pain because the thing won’t actually work properly without the Windows Services running.  You would need to deploy the code to a test server with ADFS installed.

Since I have little interest in rebuilding my development box, I went with the second option.

Okay, back to Visual Studio.  The assemblies referenced were all built on Framework 3.5, so for the sake of simplicity lets create a 3.5 Web Application:

image

I haven’t tested 4.0 yet.

Since this is a Web Application and not a Web Site within Visual Studio, we need to generate the *.designer.cs files for all the *.aspx pages.  Right-click your project and select Convert to Web Application:

image

At this point if you tried to compile the application it wouldn’t work.  We are missing a few assembly references.  First, add Microsoft.IdentityModel.  This should be in the GAC or the Reference Assemblies folder in Program Files.  Next, go back to the ADFS server and navigate to C:\Program Files\Active Directory Federation Services 2.0 and copy the following files:

  • Microsoft.IdentityServer.dll
  • Microsoft.IdentityServer.Compression.dll

Add these assemblies as references.  The web application should compile successfully.

Next we need to sign the web application’s assemblies.  If you have internal policies on assembly signing, follow those.  Otherwise double-click the properties section in Solution Explorer and navigate to Signing:

image

Choose a key file or create a new one.  Rebuild the web application.

So far we haven’t touched a line of code.  This is all general deployment stuff.  You can deploy the web application back to the ADFS server and it should work as if nothing had changed.  You have a few options for this.  The Publishing Features in Visual Studio 2010 are awesome.  Right click the project and Publish it:

image

Since I set up a test box for ADFS development, I’m just going to overwrite the files on the server:

image

Pro Tip: If you do something terrible and need to revert back to original code (what part of don’t do this on a production box didn’t make sense? Winking smile) you can access the original files from C:\Program Files\Active Directory Federation Services 2.0\WSFederationPassive.Web.

At this point we haven’t done much, but we now have a stepping point to modify the default behavior of ADFS.  This could range from simple theme changes to better suit corporate policy, or to completely redefine the authentication workflow.

This also gives us the ability to better protect our code in the event that IIS craps out and shows contents of files, not to mention the (albeit minor) performance boost we get because the website doesn’t need to be recompiled.

Have fun!

Converting Bootstrap Tokens to SAML Tokens

by Steve Syfuhs / September 09, 2010 04:00 PM

there comes a point where using an eavesdropping application to catch packets as they fly between Secure Token Services and Relying Parties becomes tiresome.  For me it came when I decided to give up on creating a man-in-the-middle between SSL sessions between ADFS and applications.  Mainly because ADFS doesn’t like that.  At all.

Needless to say I wanted to see the tokens.  Luckily, Windows Identity Foundation has the solution by way of the Bootstrap token.  To understand what it is, consider how this whole process works.  Once you’ve authenticated, the STS will POST a chunk of XML (the SAML Token) back to the RP.  WIF will interpret it as necessary and do it’s magic generating a new principal with the payload.  However, in some instances you need to keep this token intact.  This would be the case if you were creating a web service and needed to forward the token.  What WIF does is generate a bootstrap token from the SAML token, in the event you needed to forward it off to somewhere.

Before taking a look at it, let's add in some useful using statements:

using System;
using System.IdentityModel.Tokens;
using System.Text;
using System.Threading;
using System.Xml;
using Microsoft.IdentityModel.Claims;
using Microsoft.IdentityModel.Tokens;
using Microsoft.IdentityModel.Tokens.Saml11;

The bootstrap token is attached to IClaimsPrincipal identity:

SecurityToken bootstrapToken = ((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0].BootstrapToken;

However if you do this out of the box, BootstrapToken will be null.  By default, WIF will not save the token.  We need to explicitly enable this in the web.config file.  Add this line under <microsoft.IdentityModel><service><securityTokenHandlers>:

<securityTokenHandlerConfiguration saveBootstrapTokens="true" />

Once you’ve done that, WIF will load the token.

The properties are fairly straightforward, but you can’t just get a blob from it:

image

Luckily we have some code to convert from the bootstrap token to a chunk of XML:

SecurityToken bootstrapToken = ((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0].BootstrapToken;

StringBuilder sb = new StringBuilder();

using (var writer = XmlWriter.Create(sb))
{
     new Saml11SecurityTokenHandler(new SamlSecurityTokenRequirement()).WriteToken(writer, bootstrapToken);
}

string theXml = sb.ToString();

We get a proper XML document:

image

That’s all there is to it.

// About

Steve is a renaissance kid when it comes to technology. He spends his time in the security stack.