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

// steve

Multiple Identity Providers in a Multi-tenant System using Access Control Services

by Steve Syfuhs / February 21, 2011 04:00 PM

Here at ObjectSharp we’ve been having some internal discussions on certain architectural designs in the cloud.  The biggest question here lately has been:

Single-tenant or multi-tenant?

Short answer: It depends on what you want to do with the system.

Long answer: It depends on what you want to do with the system.

Smartass comments aside, that question is a post on its own.  This post is about the different ways you can deal with multiple identity providers in a system that allows multi-tenancy.

Maybe an example will help.

Imagine you’ve built a super-awesome web application, and you are providing it as (in?) a SaaS model.  You can have any number of customers, and you want to let the customers log in with their own identity providers.  More concretely, lets say a customer wants to log in to your application with their Active Directory credentials.

In a single-tenant model, the application could just make a hardcoded request directly to the given ADFS server for a token.

This can’t work in a multi-tenant model because each customer would have their own STS.

Alright, so how do we solve this problem?  We need to break it down a little further.

The first problem is that the application needs to know about each STS, and each user in the application needs to be linked to an STS.

Things start getting hinky when you need to support different token formats from STS’s.

Windows Azure Access Control Services (ACS) is a good example of how to solve parts of each problem.  ACS can consume tokens from multiple IdP’s of varying formats and normalize them into a single format that your application can them consume.  Part of the normalization is a potential transformation of claim types and values to something that the application can understand.

Here it is up to the customer’s IdP to provide the correct information, but you don’t have much control of that.

Once the application has received a token that it understands, there are a couple considerations.  How do you track new users within the application?  By this I mean, do you create a new user when they log in for the first time, or must an administrator create a record in the application for any new users?

This is important for a couple reasons. 

First is licensing.  How do you define how many users can log in to your application at any given point?  Must they be named users?

Second is authorization.  Can anyone with a valid token just start using the application immediately, or do they need to be explicitly allowed?  Are roles defined in the token?

Another question that needs to be raised is how does the customer configure the application to use their STS?  Can they just provide a couple pieces of information like a link to Federation Metadata and let the application automagically configure a new identity provider with ACS, or must they submit a request so you can do it manually?

Once all of these questions have been answered you are a step closer to building the identity model for your application.

In the end, I think we end up with something kinda like this:



Within the application, you can then partition data based on the user, the user’s STS, or any combination of the claims within the received token.

Multifactor Authentication with ADFS v2

by Steve Syfuhs / February 21, 2011 04:00 PM

More and more companies are requiring that their IT departments start introducing multifactor authentication into their systems as the threat landscape changes over time.

Multifactor authentication isn’t a new concept – it’s been around for quite a few years within the enterprise.  Microsoft has supported this for a decade in Windows.

However, it’s just now starting to become a popular solution in the consumer space.  Proof of this is PayPal introducing their hardware tokens a few years ago as well as Google introducing its support for two-factor authentication not too long ago.

I can’t really explain why it took this long to make the shift.  So, frankly, I’m not going to try. Smile

This post is simply about getting ADFS to support multifactor authentication.

The premise is simple.  We want two secrets from the principal.  Their password and a pin.  The password is secret; it’s what you use to log into Windows.  The pin can be any number of things.  It could be a one-time-password (OTP) that is generated via a cryptographically sound algorithm, or it could be a secret stored on a smart card.

For the sake of this article, we don’t actually care what it is.  Let’s assume it’s an OTP.

First things first.  ADFS works via Windows Authentication, which allows for the single sign-on experience.  We don’t actually want this because we need to be able to enter in the secondary credential.  Within the web.config file for the ADFS website, you have a section called localAuthenticationTypes.  By default Integrated is the authentication type of choice, which is Windows Auth.  Let’s remove it, and everything else but Forms.  This will tell ADFS to render the FormsSignin.aspx page when authentication is required.

<!--  <add name="Integrated" page="auth/integrated/" /> -->
  <add name="Forms" page="FormsSignIn.aspx" />
<!--  <add name="TlsClient" page="auth/sslclient/" /> –>
<!--  <add name="Basic" page="auth/basic/" />-->

When we go to log into ADFS, we are now presented with a new page:


There isn’t anything particularly exciting about this page on a code level.  The markup is a table with some textboxes.  The code is just a callout to a method in the base class that validates the credentials from the textboxes via Windows Authentication:

protected void SubmitButton_Click( object sender, EventArgs e )
        SignIn( UsernameTextBox.Text, PasswordTextBox.Text );
    catch ( AuthenticationFailedException ex )
        HandleError( ex.Message );

In a two-factor authentication world, we now have half the requirements.  Now we need to collect the pin, so take the markup and add a new row, with a textbox.


Next we need to validate the second credential.  The validation is somewhat arbitrary because I haven’t defined what sort of credential it is, so we just need to mock something up:

protected void SubmitButton_Click( object sender, EventArgs e )
        string userName = UsernameTextBox.Text;
        string pin = PinTextBox.Text;
        if(!ValidatePin(userName, pin));
             throw new AuthenticationFailedException();
        SignIn(userName, PasswordTextBox.Text);
    catch ( AuthenticationFailedException ex )
        HandleError( ex.Message );

Next you compile it, and deploy.  Don’t forget what i said about properly securing your ADFS deployment Smile.

How you handle the pin validation is dependent on the technology, but that is about all there is to it when it comes to a simple two-factor authentication mechanism for ADFS v2.

Redirecting to SAML Relying Party using ADFS v2 Query String

by Steve Syfuhs / February 21, 2011 04:00 PM

A quickie, but a goodie. 

In an earlier post on setting Salesforce.com as a SAML Relying Party to ADFS, I talked about how I felt a little dumb because I couldn’t figure out how to get ADFS to post the token to Salesforce.  The reason I felt that way was because with WS-Federation there is a URL parameter that is designed to tell the STS which relying party requested the token.  Notsomuch with SAML.

Turns out with ADFS there is such a parameter.  By default if you pass in ?loginToRp=[rpIdentifier] to the IdpInitiatedSignOn.aspx page, ADFS will look for a relying party based on the parameter.

If you are unsure of what identifier to use, you can go to the relying party properties, and check out the Identifiers tab.  It will accept any of the identifiers in the list:


As an aside, if you don’t like that URL parameter name, you can go into the IdpInitiatedSignOn.aspx.cs file and update line 21 to whichever you feel is appropriate:

const string RpIdentityQueryParameter = "loginToRp";

Then you compile the site, and redeploy.

You are properly securing ADFS by compiling the site’s source code, right? Smile

Salesforce.com Single Sign On using ADFS v2

by Steve Syfuhs / February 14, 2011 04:00 PM

For the last few years ObjectSharp has been using Salesforce.com to help manage parts of the business.  As business increased, our reliance on Salesforce increased.  More and more users started getting added, and as all stories go, these accounts became one more burden to manage.

This is the universal identity problem �� too many user accounts for the same person.  As such, one of my internal goals here is to simplify identity at ObjectSharp.

While working on another internal project with Salesforce i got to thinking about how it manages users.  It turns out Salesforce allows you to set it up as a SAML relying party.  ADFS v2 supports being a SAML IdP.  Theoretically we have both sides of the puzzle, but how does it work?

Well, first things first.  I checked out the security section of the configuration portal:


There was a Single Sign-On section, so I followed that and was given a pretty simple screen:


There isn’t much here to setup.  Going down the options, here is what I came up with:

SAML Version

I know from previous experience that ADFS supports version 2 of the SAML Protocol.


What is the URI of the IdP, which in this case is going to be ADFS?  Within the ADFS MMC snap-in, if you right click the Service node you can access the properties:


In the properties dialog there is a textbox allowing you to change the Federation Service Identifier:


We want that URI.

Within Salesforce we set the Issuer to the identifier URI.

Identity Provider Certificate

Salesforce can’t just go and accept any token.  It needs to only be able to accept a token from my organization.  Therefore I upload the public key used to sign my tokens from ADFS.  You can access that token by going to ADFS and selecting the Certificates node:


Once in there you can select the signing certificate:


Just export the certificate and upload to Salesforce.

Custom Error URL

If the login fails for some reason, what URL should it go to?  If you leave it blank, it redirects to a generic Salesforce error page.

SAML User ID Type

This option is asking what information we are giving to Salesforce, so it can correlate that information to one of their internal ID’s.  Since for this demo I was just using my email address, I will leave it with Assertion contains User’s salesforce.com username.

SAML User ID Location

This option is asking where the above ID is located within the SAML token.  By default it will accept the nameidentifier but I don’t really want to pass my email as a name so I will select user ID is in an Attribute element.

Now I have to specify what claim type the email address is.  In this case I will go with the default for ADFS, which is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

On to Active Directory Federation Services

We are about half way done.  Now we just need to tell ADFS about Salesforce.  It’s surprisingly simple.

Once you’ve saved the Salesforce settings, you are given a button to download the metadata:


Selecting that will let you download an XML document containing metadata about Salesforce as a relying party.

Telling ADFS about a relying party is pretty straightforward, and you can find the detailed steps in a previous post I wrote about halfway through the article.

Once you’ve added the relying party, all you need to do is create a rule that returns the user’s email address as the above claim type:


Everything should be properly configured at this point.  Now we need to test it.

When I first started out with ADFS and SAML early last year, I couldn’t figure out how to get ADFS to post the token to a relying party.  SAML is not a protocol that I’m very familiar with, so I felt kinda dumb when I realized there is an ADFS URL you need to hit.  In this case it’s https://[adfs.fqdn]/adfs/ls/IdpInitiatedSignOn.aspx.

It brings you to a form page to select which application to post a token to:


Select your relying party and then go.

It will POST back to an ADFS endpoint, and then POST the information to the URL within the metadata provided earlier.  Once the POST’ing has quieted down, you end up on your Salesforce dashboard:


All in all, it took about 10 minutes to get everything working.

GoodBye CardSpace; Hello U-Prove

by Steve Syfuhs / February 14, 2011 04:00 PM

Other possible titles:

  • So Long and Thanks for all the Identity
  • Goodbye awesome technology; Hello Awesomer Technology
  • CardSpace? What’s CardSpace?

Over on the Claims Based Identity Blog they made an announcement that they have stopped development of CardSpace v2.  CardSpace was an excellent technology, but nobody used it.  Some of us saw the writing on the wall when Microsoft paused development last year, and kept quiet about why.  For better or for worse, Microsoft stopped development and moved on to a different technology affectionately called U-Prove.

U-Prove is an advanced cryptographic technology that, combined with existing standards-based identity solutions, overcomes this long-standing dilemma between identity assurance and privacy. This unlocks a broad range of scenarios that have historically been out of the reach of both the private and public sectors - cases where both verified identity information and privacy are required.

So what exactly does this mean?  Central to U-Prove is something called an Agent:

Specifically, the Agent provides a mechanism to separate the retrieval of identity information from trusted organizations from the release of this information to destination sites. The underlying mechanisms help prevent the issuing organizations from tracking where or when this information is used, and to help prevent different destination sites from trivially linking users’ actions together.

Alright, what does that really mean?

Short answer: it’s kind of like CardSpace, except you—the developer—manage the application that controls the flow of claims from IdP to RP.

The goal is to enable stronger control of the release of private data to relying parties.

For more information check out the FAQ section on Connect.

Custom Home-Realm Selection Page for AppFabric Access Control Service

by Steve Syfuhs / February 03, 2011 04:00 PM

One of the major benefits to using ACS is that it reduces the heavy lifting when it comes to dealing with multiple Identity Providers, especially if they use different token types and specifications.

The consequence of using multiple identity providers is something called the Home-Realm Discovery problem.  Frankly, it deserves it’s own book on the subject, but suffice to say here is the basic problem: if your customer can log in from multiple identity providers, how do you know which provider to send them to?

There is no elegant solution to this problem (I lie, InfoCards are an elegant solution), so each developer has to make a decision how to find the appropriate provider.  Microsoft didn’t want to make any assumptions so they kept it simple: just ask.

As a result you ended up with a pretty simple menu:


A lot of times people aren’t too happy with this and want to change how the user gets to the provider.

It’s actually pretty simple.  Log into your Access Control management panel and find the Develop section.  Select Application Integration.


Once there, select the Login Pages:


Then select which Relying Party you want a custom login page for:


Then select Option 2:


This will provider you with a JSON metadata feed of all the providers your particular Relying Party can accept tokens from.  The feed is pretty simple:

  • Name: Describes the IdP – e.g. “Windows Live ID”.
  • LoginUrl: The URL to redirect to if the user wants to login with this particular provider.
  • ImageUrl: A URL for a logo for the IdP.  Could be blank.
  • EmailAddressSuffixes: A collection of email domains associated with the IdP.  Currently these can only be configured for ADFS 2v providers.

The JSON feed looks something like this:

     "Name":"Windows Live ID",

For more information on customizing ACS, check out the CodePlex site.

Once you have pulled down the feed you can break it down into a custom menu or interface of your choosing.  All you need to do is redirect to the LoginUrl of their choosing.

The Anatomy of a Security Breach

by Steve Syfuhs / February 01, 2011 04:00 PM

Without going into too much detail, there is a guy who the security industry collectively hates.  When you hear a statement like that, the happy parts of our brains think this guy must be an underdog.  He must be awesome at what he does, and the big corporations hate him for it.  Or maybe he’s a world-renowned  hacker that nobody can catch.

Suffice to say, neither are the case.

Earlier today it appears that Greg Evans of LIGATT was, for lack of a better word, pwned.  His twitter account was broken into, his email was ransacked, and by the looks of it, his reputation has been ruined.  I think it’s time to look into how and why this happened.

Side Note: I have zero affiliation with whoever broke into his accounts and stole his data.

The Impetus

Before going into the how, it might help to explain why this happened.

[My opinion doesn’t necessarily reflect that of the attackers, nor does the opinion of my employer.  This is strictly an interpretation of the messages]

Good people get hacked.  It’s a fact of life.  Bad people get hacked.  It’s a fact of life. 

Part of this attack left a note explaining why all of this happened, and explained the contents of the data.  You can find the original post to this from his twitter account.

As it happens, the people who did this see it as retribution for all the things Evans has done in the name of the InfoSec industry.

"Do not meddle in the affairs of hackers, for they are subtle and quick to anger"

The first argument being made is that he tries really hard to be a major representative of the industry.

He's been on TV, he's been on radio, he's trying to draw as much attention to himself as possible.

This I would argue isn’t too much of a problem.  The industry needs spokespeople.  However, it goes on:

This man in no way represents this industry. […] He's gone after people at their home to intimidate them and their family. He's gone after them at their work to discredit them with their employer. And as everyone knows, he recklessly sues anyone who speaks negatively of him on the internet.

Nobody likes it when someone says something mean about you, or when they correct you in public.  However, sometimes it happens.  We are all sometimes wrong.  Evans doesn’t appear to agree with that statement, and will try to sue or slander anyone who disagrees with him. 

Don’t poke the bear.  It pisses the bear off, and gets you attacked.

Especially when you have a secret or two to hide:

Finally, to Gregory D Evans: it is done. All your lies are out in the open. Your investors will know. Your lawyers will know. Your employees will know. Your mother will know. Your lovers will know. Just step away and move on. Stop the stock scams. Stop the lawsuits. Stop the harassment. Stop robbing your employees. Stop embezzling. Stop deceiving every person in your life.

If you were someone who wanted to take justice into your own hands, I guess this is reason enough.

So how did this breach happen?

The Attack

It looks like an inside job:

To the brave soul who helped make this possible: thank you. You took great personal risk to bring this information forward, and none of it would be possible without you. It's unclear how you tolerate his lies day after day, but you've redeemed yourself by supporting this cause.

i can only speculate, but there are two-and-a-half basic ways this could have gone down.

  • Insider has administrator access to email servers and downloads the contents of Evans’ inbox
  • Insider gets Evans’ password and downloads the contents of the inbox
  • Insider gives administrative access to attacker and does one of the first two things

Once they had the contents of the email they had to get access to his twitter account.  This leads me to believe that the insider had administrative access, because they could then reset the twitter account’s password and catch the reset email before it got to the inbox.  Seems like the simplest approach.

Either that, or Evans used really weak passwords.

Once the attacker had their package, they just needed to distribute it and the message explaining their actions.  From his twitter account they posted the anonymous message to pastebin.com:


Enough is enough. He must be stopped by any means necessary. To that end, at the end of this message is a torrent of the inbox of [Evans’ redacted email address]; the only condition of receipt is that you not talk about the spool or this email release on twitter until after you have the full copy and are seeding it. He may be an idiot but his staff watch twitter for any mention of him, and it's imperative that this file be distributed as much as possible before takedown begins.


The message had a final, succinct message:

Happy Birthday Mr. Evans
[Redacted link to torrent]
archive password will be released shortly

I haven’t downloaded the torrent, so I don’t know what’s in the package.  I suspect the contents will be publicly disclosed shortly on a number of anonymous sites once there are enough seeders.

This could potentially just be a hoax.

The Fallout

Lots of people get hurt when security is breached.  In this case, quite a number of people will have some of their most private information disclosed.

Contained within his inbox is personal information of many, many people. Social security numbers, bank account routing numbers, credit reports, and other reports by private investigators. It was completely impractical to redact all of this information in any effective manner […].

Some people say that justice comes at the price of people’s privacy.  The attackers feel guilty about this:

This release immediately follows with a small regret. Apologies much be given to all the bystanders, innocent or otherwise. […] and for that: sadness. If in your search through this release you find personal information, please contact the person and notify them.

They also don’t have much faith in the likelihood of Evans properly disclosing the breach:

Even when GDE finds out of this breach, it's quite unlikely that he will follow proper breach notification procedures.

Once enough people have downloaded the torrent and started seeding the content, there isn’t any real way to remove the data from public access.  That means every one of those SSN, bank numbers, credit reports, and whatever else is in the archive will be publicly available for the foreseeable future.


Breaches occur all the time for reasons of profit.  This particular breach on the other hand was done in the name of justice and retribution.  While the motives may be different, the moving pieces work the same way, and there are still three basic parts to a breach: the motive to do it, the attack itself, and the fallout after the attack.

Hopefully everyone learns a little something from this particular breach.

My guess is that Evans will.

The Problem with Claims-Based Authentication

by Steve Syfuhs / January 31, 2011 04:00 PM

Homer Simpson was once quoted as saying “To alcohol! The cause of, and solution to, all of life's problems”.  I can’t help but borrow from it and say that Claims-Based Authentication is the cause of, and solution to, most problems with identity consumption in applications.

When people first come across Claims-Based Authentication there are two extremes of responses:

  • Total amazement at the architectural simplicity and brilliance
  • Fear and hatred of the idea (don’t you dare take away my control of the passwords)

Each has a valid truth to them, but over time you realize all the problems sit somewhere between both extremes.  It’s this middle ground where people run into the biggest problems. 

Over the last few months there’s been quite a few people talking about the pains of OpenID/OpenAuth, which when you get right down to the principle of it, is CBA.  There are some differences such as terminology and implementation, but both follow the Trusted Third Party Authentication model, and that’s really what CBA is all about.

Rob Conery wrote what some people now see as an infamous post on why he hates OpenID.  He thinks it’s a nightmare for various reasons.  The basic list is as follows:

  • As a customer, since you can have multiple OpenID providers that the relying party doesn’t necessarily know about, how do you know which one you originally used to setup an account?
  • If a customer logs in with the wrong OpenID, they can’t access whatever they’ve paid for.  This pisses off said customer.
  • If your customer used the wrong OpenID, how do you, as the business owner, fix that problem? 
    • Is it worth fixing? 
    • Is it worth the effort of writing code to make this a simpler process?
  • “I'll save you the grumbling rant, but coding up Open ID stuff is utterly mind-numbing frustration”.  This says it all.
  • Since you don’t want to write the code, you get someone else to do it.  You find a SaS provider.  The provider WILL go down.  Laws of averages, Murphy, and simple irony will cause it to go down.
  • The standard is dying.  Facebook, Google, Microsoft, Twitter, and Joe-Blow all have their own particular ways of implementing the standard.  Do you really want to keep up with that?
  • Dealing with all of this hassle means you aren’t spending your time creating content, which does nothing for the customer.

The end result is that he is looking to drop support, and bring back traditional authentication models.  E.g. storing usernames and passwords in a database that you control.

Following the Conery kerfuffle, 37signals made an announcement that they were going to drop OpenID support for their products.  They had a pretty succinct reason for doing so:

Fewer than 1% of all 37signals users are currently using OpenID. After consulting with a fair share of them, it seems that most were doing so only because that used to be the only way to get single sign-on for our applications.

I don’t know how many customers they have, but 1% is nowhere near a high enough number to justify keeping something alive in any case.

So we have a problem now, don’t we?  On paper Claims-Based Authentication is awesome, but in practice it’s a pain in the neck.  Well, I suppose that’s the case with most technologies. 

I think one of problems with implementations of new technologies is the lack of guidance.  Trusted-Third Party authentication isn’t really all that new.  Kerberos does it, and Kerberos has been around for more than 30 years.  OpenID, OpenAuth, and WS-Auth/WS-Federation on the other hand, haven't been around all that long.  Given that, I have a bit of guidance that I’ve learned from the history of Kerberos.

First: Don’t trust random providers.

The biggest problem with OpenID is what’s known as the NASCAR problem.  This is another way of referring to Rob’s first problem.  How do you know which provider to use?  Most people recognize logo’s, so show them a bunch of logo’s and hopefully they will pick the one that they used.  Hoping your customer chooses the right one every time is like hoping you can hit a bullseye from 1000 yards, blindfolded.  It could happen.  It won’t.  But it could.

The solution to this is simple: do not trust every provider.  Have a select few providers you will accept, and have them sufficiently distinguishable.  My bank as a provider is going to be WAY different than using Google as a provider.  At least, I would hope that’s the case.

Second: Don’t let the user log in with the wrong account.

While you are at it, try moving the oceans using this shot glass.  Seriously though, if you follow the first step, this one is a by product.  Think about it.  Would a customer be more likely to log into their ISP billing system with their Google account, or their bank’s account?  That may be a bad example in practice because I would never use my bank as a provider, but it’s a great example of being sufficiently distinguishable.  You will always have customers that choose wrong, but the harder you make it for them to choose the wrong thing, the closer you are to hitting that bullseye.

Third: Use Frameworks.  Don’t roll your own.

One of the most important axioms in computer security is don’t roll your own [framework/authn/authz/crypto/etc].  Seriously.  Stop it.  You WILL do it wrong.  I will too.  Use a trusted OpenID/OpenAuth framework, or use WIF.

Forth: Choose a standard that won’t change on you at the whim of a vendor. 

WS-Trust/Auth and SAML are great examples of standards that don’t change willy-nilly.  OpenID/OpenAuth are not.

Fifth: Adopt a provider that already has a large user base, and then keep it simple.

This is an extension of the first rule.  Pick a provider that has a massive number of users already.  Live ID is a great example.  Google Accounts is another.  Stick to Twitter or Facebook.  If you are going to choose which providers to accept, make sure you pick the ones that people actually use.  This may seem obvious, but just remember it when you are presented with Joe’s Fish and Chips and Federated Online ID provider.

Finally: Perhaps the biggest thing I can recommend is to keep it simple.  Start small.  Know your providers, and trust your providers.

Keep in mind that everything I’ve said above does not pertain to any particular technology, but of any technology that uses a Trusted Third Party Authentication model.

It is really easy to get wide-eyed and believe you can develop a working system that accepts every form of identification under the sun, all the while keeping it manageable.  Don’t.  Keep it simple and start small.

The Azure Experience Lab

by Steve Syfuhs / January 30, 2011 04:00 PM

Every year ObjectSharp puts on a handful of events, and this year we are pushing hard for Azure.  Next week we have such an event geared towards ISV Developers and Business people.  ObjectSharp would like to welcome you to the Azure Experience Lab!

Windows Azure is Microsoft’s cloud operating system. Leveraging the .NET Platform, developers can easily take advantages of their skills to move their applications to the cloud.  The Azure Experience Lab is all about discovering new business opportunities and learning new technologies to leverage cloud computing for your organization and your customers.

For ISVs looking to augment their traditional software models with subscription and service models, cloud computing represents a huge growth opportunity. Join us for a day of exploration and experience with Windows Azure as we explore both the business value and the technologies available for cloud computing with Microsoft.

There are two tracks available for this event, and ideally, we recommend you include individuals in both tracks from your organization to get the most value from our Experience Lab.

  • The Business Value Track is recommended for product managers, strategic planners, CTOs, architects and other decision making leaders who evaluate strategic directions for their organization and their customers.

  • The Azure Development Track is recommended for Solution and Infrastructure Architects, Lead Developers and other technologies who evaluate technologies as part of their solution offerings.

What's Windows Azure About?
Windows Azure is Microsoft’s cloud operating system. Developing for Azure leverages your existing ASP.NET Development Experience and provides developers with on-demand compute and storage to host, scale, and manage web applications in the cloud through Microsoft® datacenters or even hybrid off/on premise hosting models. In the Experience Lab you'll learn how to develop ASP.NET Applications and Services for Cloud Computing.

We Provide
Light refreshments and a networking lunch. Attendees of the Hands-on-labs in the Azure Development Track are provided with computer equipment, labs and various technical resources.

You Provide
To get the most out of this event, we recommend those attending the Azure Development Track bring their personal or business credit card required for Azure activations as part of the hands on labs. This is required, even if you only setup for a trial period and shut down your account after the event.

Monday, February 7th, 2011.
Two Learning Tracks:
Business Value of Azure - 9:00am - 5:00pm
Developing for Azure - 9:00am - 5:00pm

Azure Experience Lab
11 King Street West, Suite 1400, Toronto, ON M5H 4C7

$99 (incl. refreshments)

By invitation only. Please quote Invitation code XLAB02
Limited to 20 ISVs (max 2 people, 1 in each track)

8:30-9:00 Registration
9-10:15 What is Azure? All up overview and demonstration of the various services and capabilities of Windows and SQL Azure including a review of costs and benefits associated with each.
10:15-10:30 Break
  Business Value Track Azure Development Track
10:30-12:00 Fireside chat about Business Scenarios for Cloud Computing and Azure and how to unlock business value for your organization and your customers. All about Storage in Azure (including hands on lab)
12:00-1:00 Networking Lunch
1:00-2:30 Understanding, evaluating and mitigating Risks associated with Cloud Computing Building Services in Azure (including hands on lab)
2:30-2:45 Break
2:45-4:15pm Open Discussion for business discussions, individual break outs, q&a panel discussion with ObjectSharp and Microsoft Executives All about Security in Azure (including hands on labs)
4:15pm Closing Summary, Next Steps

If you are an ISV and are interested in attending, please register now!

PrairieDevCon Identity and Security Presentations on June 13th and 14th

by Steve Syfuhs / January 25, 2011 04:00 PM

Sometime last week I got confirmation that my sessions were accepted for PrairieDevCon!  The schedule has not yet been announced, but here are the two sessions I will be presenting:

Changing the Identity Game with the Windows Identity Foundation

Identity is a tricky thing to manage. These days every application requires some knowledge of the user, which inevitably requires users to log in and out of the applications to prove they are who they are as well as requiring the application to keep record of the accounts. There is a fundamental shift in the way we manage these users and their accounts in a Claims Based world. The Windows Identity Foundation builds on top of a Claim based architecture and helps solve some real world problems. This session will be a discussion on Claims as well as how WIF fits into the mix.
Track: Microsoft, Security
Style: Lecture
Speaker: Steve Syfuhs

Building a Security Token Service In the Time It Takes to Brew a Pot of Coffee

One of the fundamental pieces of a Claims Based Authentication model is the Security Token Service. Using the Windows Identity Framework it is deceivingly simple to build one, so in this session we will.
Track: Microsoft, Security
Style: Lecture
Speaker: Steve Syfuhs

What is PrairieDevCon?

The Prairie Developer Conference is the conference event for software professionals in the Canadian prairies!

Featuring more than 30 presenters, over 60 sessions, and including session styles such as hands-on coding, panel discussions, and lectures, Prairie Developer Conference is an exceptional learning opportunity!
Register for our June 2011 event today!

Okay, how much $$$?

Register early and take advantage of Early Bird pricing!
Get 50% off the post-conference price when you bundle it with your conference registration!

Conference Conference +
Post-Conf Workshop
Until February 28 $299.99 $449.99
Until March 31 $399.99 $549.99
Until April 30 $499.99 $649.99
May and June $599.99 $749.99
Post-Conference Workshop Only $299.99

For more information check out the registration section.

// About

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