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

// Geek Stuff

Windows Azure Pack Authentication Part 3 – Using a Third Party IdP

by Steve Syfuhs / February 07, 2014 06:22 PM

In the previous installments of this series we looked at how Windows Azure Pack authenticates users and how it’s configured out of the box for federation. This time around we’re going to look at how you can configure federation with a third party IdP.

Microsoft designed Windows Azure Pack the right way. It supports federation with industry protocols out of the box. You can’t say that for many services, and you certainly can’t say that those services support it natively for all versions – more often than not you have to pay extra for it.

Windows Azure Pack supports federation, and actually uses it to authenticate users by default. This little fact makes it easy to federate to a 3rd party IdP.

If we searched around we will find lots of resources on federating to ADFS, as that’s Microsoft’s federation product, and there are a number of good (German content) walkthroughs on how you can get it working. If you want to use ADFS go read one or all of those articles as everything we talk about today will be about using a non-Microsoft federation service.

Before we begin though I’d like to point out that Microsoft does have some resources on using 3rd party IdPs, but unfortunately the information is a bit thin in some places.


Federation is a complex beast and we should be clear about what is required to get it working. In no particular order you need the following:

  • STS that supports the WS-Federation (passive) protocol
  • STS that supports WS-Federation wrapped JSON Web Tokens (JWT)
  • Optional: STS that supports WS-Trust + JWT

If you plan to use the public APIs with federated accounts then you will need a STS that supports WS-Trust + JWT.

If you don’t have a STS that can support these requirements then you should really consider taking a look at ADFS, or if you’re looking for customization, Thinktecture Identity Server. Both are top notch IdPs (edit: insert pitch about the IdP my company builds and sells as well [edit-edit: our next version natively supports JWT] Winking smile -- sorry, this concludes the not-so-regularly-scheduled product placement).

Another option is to roll your own IdP. Don’t do this. No seriously, don’t. It’s a complicated mess. You’re way better off using the Thinktecture server and extending it to fit your needs.

Supposing though that you already have an IdP and want to support JWT though, here’s how we can do it. In this context the IdP is the overarching identity providing system and the STS is simply the service issuing tokens.

Skip this next section if you just want to see how to configure Windows Azure Pack. That’s the main part that’s lacking in the MSDN documentation.

JWT via IdentityModel

First off, you need to be using .NET 4.5, and you need to be using the the 4.5 IdentityModel stack. You can’t use the original 3.5 bits.

At this point I’m going to assume you’ve got a working IdP already. There are lots of articles out there explaining how to build one. We’re just going to mod the STS.

Before making any code changes though you need to add the JWT token handler, which is easily installed via Nuget (I Red heart Nuget):

PM> Install-Package System.IdentityModel.Tokens.Jwt

This will need to be added to the project that exposes your STS configuration class.

Next, we need to inject the token handler into the STS pipeline. This can easily be done by adding an entry to the web.config system.identityModel section:

Or if you want to hardcode it you can add it to your SecurityTokenServiceConfiguration class.

There are of course other (potentially better) ways you can add it in, but this serves our purpose for the sake of a sample.

By adding the JWT token handler into the STS pipeline we can begin issuing JWTs to any relying parties that request one. This poses a problem though because passive requests don’t have a requested token type tacked on. Active (WS-Trust) requests do, but not passive. So we need to specify that a JWT should be minted instead of a SAML token. This can be done in the GetScope method of the STS class.

All we really needed to do was specify the TokenType as WIF will use that to determine which token handler should be used to mint the token. We know this is the value to use because it’s exposed by the GetTokenTypeIdentifiers() method in the JWTSecurityTokenHandler class.

Did I mention the JWT library is open source?

So now at this point if we made a request for token to the STS we could receive a WS-Federation wrapped JWT.

If the idea of using a JWT instead of a SAML token appeals to you, you can configure your app to use the JWT token handler similar to Dominick’s sample.

If you were submitting a WS-Trust RST to the STS you could use client code along the lines of:

When the GetScope method is called the request.TokenType should be set to whatever you passed in at the client. For more information on service calls you can take a look at the whitepaper Claims-Based Identity in Windows Azure Pack (docx). A future installment of this series might have more information about using services.

Lastly, we need to sign the JWT. The only caveat to using the JWT token handler is that the minimum RSA key size is 2048 bits. If you’re using a key smaller than that then please upgrade it. We’re going to overlook the fact that the MSDN article shows how to bypass minimum key sizes. Seriously. Don’t do it. I don’t want to have to explain why (putting paranoia aside for a moment, 1024 is being deprecated by Windows and related services in the near future anyway).

Issuing Tokens to Windows Azure Pack

So now we’re at a point where we can mint a JWT token. The question we need to ask now is what claims should this token contain? Looking at Part 1 we see that the Admin Portal requires UPN and Group claims. The tenant portal only requires the UPN claim.

Lucky for us the JWT token handler is smart. It knows to transform certain known XML-token-friendly-claim-types to JWT friendly claim types. In our case we can use http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn in our ClaimsIdentity to map to the UPN claim, and http://schemas.xmlsoap.org/claims/Group to map to our Group claim.

Then we need to determine where to send the token, and who to address it to. Both the tenant and admin sites have Federation Metadata documents that specify this information for us. If you’ve got an IdP that can parse the metadata then all you need to do is point it to https://yourtenantsite/FederationMetadata/2007-06/FederationMetadata.xml for the tenant configuration or https://youradminsite/FederationMetadata/2007-06/FederationMetadata.xml for the admin configuration.

Of course, this information will also map up to the configuration elements we looked at in Part 2. That’ll tell us the Audience URI and the Reply To for both sites.

Finally we have everything we need to mint the token, address it, and send it on its way.

Configuring Windows Azure Pack to Trust your Token

The tokens been sent and once it hits either the tenant or admin site it’ll promptly be ignored and you’ll get an ugly error message saying “nope, not gonna happen, bub.”

We therefore need to configure Windows Azure Pack to trust our token. Looking at MSDN we see some somewhat useful information telling us what we need to modify, but frankly, its missing a bunch of information so we’re going to ignore it.

First things first: if your IdP publishes a Federation Metadata document then you can just configure everything via PowerShell:

You can replace the target “Admin” with “Tenant” if you want to configure the Tenant Portal. The only caveat with doing it this way is that the metadata document needs to be accessible from the server. I’ve submitted a feature request that they also support local file paths too; hopefully they listen! Since the parameter takes the full URL you can put the metadata document somewhere public if its not normally accessible. You will only need the metadata accessible while applying this configuration.

If the cmdlet completed successfully then you should be able to log in from your own IdP. That’s all there is to it for you. I would recommend seriously considering going this route instead of configuring things manually.

Otherwise, lets carry on.

Since we can’t import our federation metadata (since we probably don’t have any), we need to configure things manually. To do that we need to modify settings in the database.

Looking back to Part 2 we see all the configuration elements that enable our federated trust to the default IdPs. We’ll need to update a few settings across the Microsoft.MgmtSvc.Store and Microsoft.MgmtSvc.PortalConfigStore databases.

As per the MSDN documentation it says to modify the settings in the PortalConfigStore database. It’s wrong. It’s incomplete as that’s only part of the process.

The PortalConfigStore database contains the settings used by the Tenant and Admin Portals to validate and request tokens. We need to modify these settings to use our custom IdP. To do so locate the Authentication.IdentityProvider setting in the [Config].[Settings] table.  The namespace we need to choose is dependent on which site we want to configure. In our case we select the Admin namespace. As we saw last time it looks something like:

We need to substitute our STS information here. The Realm is whatever your STS issuer is, and the Endpoint is where ever your WS-Federation endpoint is located. The Certificate should be a base 64 encoded representation of your signing certificate (remember, just the public key).

In my experience I’ve had to do an IISRESET on the portals to get the settings refreshed. I might just be impatient though.

Once those values are replaced you can try logging in. You should be redirected to your IdP and if you issue the token properly it’ll hit the portal and you should be logged in. Unfortunately this’ll actually fail with a non-useful error message.


Who can guess why? So far I’ve stated that the MSDN documentation is missing information. What have we missed? Hopefully if you’ve read the first two parts of this series you’re yelling at the screen telling me to get on with it already because you’ve caught on to what I’m saying.

We haven’t configured the API services to trust our STS! Oops.

With that being said, we now have proof that Windows Azure Pack flows the token to the services from the Portal and, more importantly, the services validate the token. Cool!

Anyway, now to configure the APIs. Warning: complicated.

In the Microsoft.MgmtSvc.Store database locate the Settings table and then locate the Authentication.IdentityProvider.Secondary element in the AdminAPI namespace. We need to update it with the exact same values as we put in to the configuration element in the other database.

If you’re only wanting to configure the Tenant Portal you’d want to modify the Authentication.IdentityProvider.Primary configuration element. Be careful with the Primary/Secondary elements as they can get confusing.

If you’re configuring the Admin Portal you’ll need to update the Authentication.IdentityProvider.Secondary configuration element in the TenantAPI namespace to use the configuration you specified for the Admin Portal as well. As I said previously, I think this is because the Admin Portal calls into the Tenant API. The Admin Portal will use an admin-trusted token – therefore the TenantAPI needs to trust the admin’s STS.

Now that you’ve completed configuration you can do an IISRESET and try logging in. If you configured everything properly you should now be able to log in from your own IdP.


For those rock star Ops people who understand identity this guide was likely pretty easy to follow, understand, and implement. For everyone else though, this was probably a pain in the neck. Here are some troubleshooting tips.

Review the Event Logs
It’s surprising how many people forget that a lot of applications will write errors to the Windows Event Log. Windows Azure Pack has quite a number of logs that you can review for more information. If you’re trying to track down an issue in the portals look in the MgmtSvc-*Site where * is Tenant or Admin. Errors will get logged there. If you’re stuck mucking about the APIs look in the MgmtSvc-*API where * is Tenant, Admin, or TenantPublic.

Enable Development Mode
You can enable developer mode in sites by modifying a value in the web.config. Unprotect the web.config by calling:

And then locate the appSetting named Microsoft.Azure.Portal.Configuration.PortalConfiguration.DevelopmentMode and set the value to true. Be sure to undo and re-protect the configuration when you’re done. You should then get a neat error tracing window show up in the portals, and more diagnostic information will be logged to the event logs. Probably not wise to do this in a production environment.

Use the PowerShell CmdLets
There are a quite a number of PowerShell cmdlets available for you to learn about the configuration of Windows Azure Pack. If you open the Windows Azure Pack Administration PowerShell console you can see that there are two modules that get loaded that are full of cmdlets:

PS C:\Windows\system32> get-command -Module MgmtSvcConfig

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Cmdlet          Add-MgmtSvcAdminUser                               MgmtSvcConfig
Cmdlet          Add-MgmtSvcDatabaseUser                            MgmtSvcConfig
Cmdlet          Add-MgmtSvcResourceProviderConfiguration           MgmtSvcConfig
Cmdlet          Get-MgmtSvcAdminUser                               MgmtSvcConfig
Cmdlet          Get-MgmtSvcDatabaseSetting                         MgmtSvcConfig
Cmdlet          Get-MgmtSvcDefaultDatabaseName                     MgmtSvcConfig
Cmdlet          Get-MgmtSvcEndpoint                                MgmtSvcConfig
Cmdlet          Get-MgmtSvcFeature                                 MgmtSvcConfig
Cmdlet          Get-MgmtSvcFqdn                                    MgmtSvcConfig
Cmdlet          Get-MgmtSvcNamespace                               MgmtSvcConfig
Cmdlet          Get-MgmtSvcNotificationSubscriber                  MgmtSvcConfig
Cmdlet          Get-MgmtSvcResourceProviderConfiguration           MgmtSvcConfig
Cmdlet          Get-MgmtSvcSchema                                  MgmtSvcConfig
Cmdlet          Get-MgmtSvcSetting                                 MgmtSvcConfig
Cmdlet          Initialize-MgmtSvcFeature                          MgmtSvcConfig
Cmdlet          Initialize-MgmtSvcProduct                          MgmtSvcConfig
Cmdlet          Install-MgmtSvcDatabase                            MgmtSvcConfig
Cmdlet          New-MgmtSvcMachineKey                              MgmtSvcConfig
Cmdlet          New-MgmtSvcPassword                                MgmtSvcConfig
Cmdlet          New-MgmtSvcResourceProviderConfiguration           MgmtSvcConfig
Cmdlet          New-MgmtSvcSelfSignedCertificate                   MgmtSvcConfig
Cmdlet          Protect-MgmtSvcConfiguration                       MgmtSvcConfig
Cmdlet          Remove-MgmtSvcAdminUser                            MgmtSvcConfig
Cmdlet          Remove-MgmtSvcDatabaseUser                         MgmtSvcConfig
Cmdlet          Remove-MgmtSvcNotificationSubscriber               MgmtSvcConfig
Cmdlet          Remove-MgmtSvcResourceProviderConfiguration        MgmtSvcConfig
Cmdlet          Reset-MgmtSvcPassphrase                            MgmtSvcConfig
Cmdlet          Set-MgmtSvcCeip                                    MgmtSvcConfig
Cmdlet          Set-MgmtSvcDatabaseSetting                         MgmtSvcConfig
Cmdlet          Set-MgmtSvcDatabaseUser                            MgmtSvcConfig
Cmdlet          Set-MgmtSvcFqdn                                    MgmtSvcConfig
Cmdlet          Set-MgmtSvcIdentityProviderSettings                MgmtSvcConfig
Cmdlet          Set-MgmtSvcNotificationSubscriber                  MgmtSvcConfig
Cmdlet          Set-MgmtSvcPassphrase                              MgmtSvcConfig
Cmdlet          Set-MgmtSvcRelyingPartySettings                    MgmtSvcConfig
Cmdlet          Set-MgmtSvcSetting                                 MgmtSvcConfig
Cmdlet          Test-MgmtSvcDatabase                               MgmtSvcConfig
Cmdlet          Test-MgmtSvcPassphrase                             MgmtSvcConfig
Cmdlet          Test-MgmtSvcProtectedConfiguration                 MgmtSvcConfig
Cmdlet          Uninstall-MgmtSvcDatabase                          MgmtSvcConfig
Cmdlet          Unprotect-MgmtSvcConfiguration                     MgmtSvcConfig
Cmdlet          Update-MgmtSvcV1Data                               MgmtSvcConfig

As well as the MgmtSvcConfig module which is moreso for daily administration.

Read the Windows Azure Pack Claims Whitepaper
See here: Claims-Based Identity in Windows Azure Pack (docx).

Visit the Forums
When in doubt take a look at the forums and ask a question if you’re stuck.

Email Me
Lastly, you can contact me (steve@syfuhs.net) with any questions. I may not have answers but I might be able to find someone who can help.


In the first two parts of this series we looked at how authentication works, how it’s configured, and now in this installment we looked at how we can configure a third party IdP to log in to Windows Azure Pack. If you’re trying to configure Windows Azure Pack to use a custom IdP I imagine this part is the most complicated to figure out and hopefully it was documented well enough. I personally spent a fair amount of time fiddling with settings and most of the information I’ve gathered for this series has been the result of lots of trial and error. With any luck this series has proven useful to you and you have more luck with the configuration than I originally did.

Next time we’ll take a look at how we can consume the public APIs using a third party IdP for authentication.

In the future we might take a look at how we can authenticate requests to a service called from a Windows Azure Pack add-on, and how we can call into Windows Azure Pack APIs from an add-on.

Visual Studio 2010 Desktop Background Images

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

Last night a couple people asked where I got all the neat VS2010 desktop backgrounds.  I couldn’t remember the URL off the top of my head last night, but the website is http://vs2010wallpapers.com/.  There are a lot of great backgrounds.  My favorite though is the ducky. Smile


Act II: New Opportunities

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

Sometime last week I sent out an email to quite a few people:

As is the way of things in the tech industry, jobs change.  More specifically, mine.

Sometime around October 1st this email will be turned off as I am starting a new position with ObjectSharp working with some of the brightest minds in Toronto.  If you need to get in touch with me after that date you can do it through a few channels.  My personal email is steve@syfuhs.net, which gets checked more often than it should, and my O# email will be ssyfuhs@objectsharp.com.


Steve Syfuhs, MCP
Soon to be ex-Software Developer / Database Analyst
Woodbine Entertainment Group
416.675.3993 Ext 2592

While I really enjoyed my job here at Woodbine (even though I complained about it from time to time), it’s time for change and to move on to new opportunities. 

Barry Gervin offered me such an opportunity and I start with ObjectSharp on October 1st.  Bonus for starting on a Friday.

My role has many functions.  Some internal; some external.  Some loud; some…notsomuch.  Some cryptic. Winking smile  It sounds like it will be an amazing experience!

So… I leave you with this:


Working with Certificates in Code

by Steve Syfuhs / August 04, 2010 04:00 PM

Just a quick little collection of useful code snippets when dealing with certificates.  Some of these don’t really need to be in their own methods but it helps for clarification.

Namespaces for Everything

using System.Security.Cryptography.X509Certificates;
using System.Security;

Save Certificate to Store

// Nothing fancy here.  Just a helper method to parse strings.
private StoreName parseStoreName(string name)
    return (StoreName)Enum.Parse(typeof(StoreName), name);
// Same here
private StoreLocation parseStoreLocation(string location)
    return (StoreLocation)Enum.Parse(typeof(StoreLocation), location);
private void saveCertToStore(X509Certificate2 x509Certificate2, StoreName storeName, StoreLocation storeLocation)
    X509Store store = new X509Store(storeName, storeLocation);



Create Certificate from byte[] array

private X509Certificate2 CreateCertificateFromByteArray(byte[] certFile)
     return new X509Certificate2(certFile); 
	// will throw exception if certificate has private key

The comment says that it will throw an exception if the certificate has a private key because the private key has a password associated with it. If you don't pass the password as a parameter it will throw a System.Security.Cryptography.CryptographicException exception.

Get Certificate from Store by Thumbprint

private bool FindCertInStore(
    string thumbprint, 
    StoreName storeName, 
    StoreLocation storeLocation, 
    out X509Certificate2 theCert)
    theCert = null;
    X509Store store = new X509Store(storeName, storeLocation);


        string thumbprintFixed = thumbprint.Replace(" ", "").ToUpperInvariant();

        foreach (var cert in store.Certificates)
            if (cert.Thumbprint.ToUpperInvariant().Equals(thumbprintFixed))
                theCert = cert;

                return true;

        return false;

Have fun!

Upgrade to DasBlog

by Steve Syfuhs / July 31, 2010 04:00 PM

One of the downsides to using a Blog Engine one wrote while in High School is that you are using a blog engine that someone wrote while in High School. 

I got tired of writing a new feature every time I wanted to do anything different.  The logical approach was to upgrade to a bigger and better system, and DasBlog was the engine of choice.

With any luck I’ll stick with it, and won’t need to write any more code for this site in the near future.

The Known Universe

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

Holy crap this is cool:

> > >

A Thought on Windows Mobile 7

by Steve Syfuhs / January 03, 2010 04:00 PM

The other day while I was sitting in the airport in Washington, D.C., I had a random thought.  When the ZuneHD first hit the shelves people were talking about how Mobile 7 might borrow the look and feel.  It’s sleek, easy to use/easy to understand, and is very simple.  So I started thinking about what such an interface might look like.  This is something I did quickly.  Nothing was provided by Microsoft.  Nobody has said anything about Mobile 7 design (at least, not at that point, but nobody cared anyway).  This is simply something I thought the interface might look like.


Some things to notice are the list-like menu’s, and the bing search at the bottom.  Blah-blah-blah anti-trust, the point is search is easily accessible, not necessarily just to Microsoft’s own search engine.  It could be Google’s search too.  Also, there is the location-specific information at the top showing the current weather.  Also mimicking the Windows 7 interface is the idea of pinning things to the home screen such as the Internet Explorer application.

There are some things that should probably change.  It feels a little cluttered at the bottom showing current messages and the appointments color is iffy.  There may not be any need for the middle separation either.

Just a thought…

A Trip to the Microsoft Store

by Steve Syfuhs / January 03, 2010 04:00 PM

While I was in California last week I decided to visit the new Microsoft Store in Mission Viejo.  While there, the managers graciously allowed me to take pictures of the store.  Frankly, they probably thought it was a little creepy.  But nevertheless, they said go for it, and I did.

Now, Microsoft did one hell of a job making it known that the store existed while I was at the mall.  While I was grabbing coffee in the food court, these stickers were on each table:


Following that, as you head towards the store you see two large LCD screens in the centre of the walkway.  On one side you have a Rock Band - Beatles installation running XBox 360 over HD.


On the other side was a promotional video.


Microsoft designed their store quite well.  Large floor to ceiling windows for the storefront, with an inviting light wood flooring to create a very warm atmosphere.  While there were hundreds of people in the store, it was very welcoming.


Along the three walls (because the 4th is glass) is a breathtaking video panorama.  I’m not quite sure how to really describe it.  It’s as if the entire wall was a single display, running in full HD.




In the center of the store is a collection of laptops and assorted electronics like the Zune’s.  There’s probably a logical layout, perhaps by price, or performance.  I wasn’t paying too much attention to that unfortunately.


At the center-back of the store is Microsoft’s Answers desk.  Much like the Apple Genius Bar, except not so arrogant.  Yes, I said it.  Ironically, the display for customer names looked very iPod-ish here, and in the Apple Store, the equivalent display looked like XP Media Center.  Go figure.


One of the things I couldn’t quite believe was the XBox 360 being displayed overlay the video panorama video.  The video engine for that must have been extremely powerful.  That had to be a 1080P display for the XBox.  As a developer, I was astonished (and wondered where I could get that app!)  A few of the employee’s mentioned that it was driven by Windows 7.  Pretty freakin’ sweet.


Also in the store were a couple Surfaces!  This was the first time I actually had the opportunity to play with one.  They are pretty cool.



And that in a few pictures was my trip to the Microsoft store.  There was also a couple pamphlets in store describing training sessions and schedules for quick how-to’s in Windows 7 that I walked away with.

Microsoft did well.

Presenting at Techdays 2009!

by Steve Syfuhs / July 15, 2009 04:00 PM

Still working out session details, but it looks like I will be presenting in Ottawa and Montreal for Techdays 2009.  I will be loitering around at the Toronto event soaking up all the techie-goodness, so come find me at any of the three events.  We can talk shop, shoot the breeze, or just mill about having a good time.

I promise I won’t embarrass anyone.  Except maybe myself.  But that’s a warning for all occasions.

Here are the dates of the events across Canada.  Buy your tickets before the early-bird deal runs out!

City Date Venue
VANCOUVER SEPTEMBER 14-15 Vancouver Convention Centre
TORONTO SEPTEMBER 29-30 Metro Toronto Convention Centre
HALIFAX NOVEMBER 2-3 World Trade & Convention Centre
CALGARY NOVEMBER 17-18 Calgary Stampede
MONTREAL DECEMBER 2-3 Mont-Royal Centre
OTTAWA DECEMBER 9-10 Hampton Inn & Convention Centre
WINNIPEG DECEMBER 15-16 Winnipeg Convention Centre

The Early Bird price is $299.  The regular Price is $599.

I will post more on the sessions I will be presenting at a later date when I get the full details.

See you there!

Bing Search Provider

by Steve Syfuhs / June 20, 2009 04:00 PM

Seems it automatically updates itself in IE.



// About

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