DarksideCookie

Where are we going?

chris@59north.com — Fri, 17 May 2013 08:39:53 +0200

Yesterday I saw a few blog posts coming online, talking about the future of Microsoft’s development sphere. There was one from Scott at OdeToCode that talked about the future of .NET, and that open source might be the the thing that “saves” it. And then there was another one called “The Dying Platform: .NET”. I decided to highlight the later one on Twitter and Facebook, and got a few different replies. All of them more or less solidifying my beliefs, so I decided to write this post about it… And by that, I mean that people with a close connection with Microsoft and/or long experience of the Microsoft spehere, said it was wrong, and the more “regular Joe” developers said that it was spot on…

First of all, due to the fact that a couple of people fairly close to me told me that it was wrong, I will start off by explaining what parts of that second blog post I agree with, and why.

Point 1 – “Inherent hatred for Microsoft and anything it does, even if it is good”. This is absolutely not Microsoft’s fault. It is a generally messed up view of the world, that unfortunately targets Microsoft a lot more than others. Microsoft pretty much can’t do anything right according to a lot of people, while Apple and Google can barely do anything wrong. The thing I find most sadening about this, is that I hear it a LOT from .NET devs. Why stay on a platform that is that bad then? Either support your platform, or move to another one. Or at least shut the @£#% up! Having the devs on the platform talk about it like that, brings it down for everyone, especially people that don’t know enough to have an opinion of their own. And the vast majority of the people out there don’t have a clear opinion of their own…and if they do, it is based on what they hear, not actual facts…

Point 2 – “Windows 8 and WinRT with it’s confusing .net support”. Yes, it is really hard to figure out what is happening here. I can honestly say that I believe I understand it, but it isn’t a simple thing to explain. But if you do listen to what is being said, .NET isn’t going away at all at this point. My biggest concern here is that Microsoft is calling anything not WinRT-based “legacy”, which sounds a lot like deprecated… But that’s mostly a marketing failure, which I will get back to later…

Point 3 – “All the windows phones, and particularly the WP7 fail…”. I mostly agree with this. I believe screwing over the early adopters with a non-upgradable OS update was a MASSIVE mistake that alienated a lot of people. It also fragmented the market, which was the one thing I thought that they would NOT do with this platform. On top of that, the talk about how updates would not be blocked by carriers but come from Microsoft directly turned out to be BS that caused even more aggrevation. I REALLY want to love my WP device, but it is unfortunately really hard. Having that said, it is still very early in the game, and I really hope they catch up to Android fast. If I can get a WP platform that is uniform with the one on Windows 8, and with similar interface driven system integration, it would be a great step in the right direction. But so far, WP is not what I wanted it to be, and I hear a LOT of people saying the same thing… On the other hand, that is also not completely Microsoft’s fault. The fact that well-known apps reach WP in much crappier versions is not Microsoft, that is the app developers not taking the platform seriously…which might be caused somewhat by Microsoft though…

Point 4 – “Half arsed open sourcing…”, just isn’t true. The problem with open sourcing Microsofts platforms is that due to the fact that it is Microsoft, taking pull requests can’t be taken lightly. It has to be a controlled environment for a lot of reasons. It might seem like they are not commited to open source if you just look at the hoops you have to jump through to be able to contribute, but if you start scratching the surface, you will probably understand why. I believe the fact that they have put the source code out there for everyone to see is a MASSIVE step in the right direction.

Point 5 – “Tablets and the fact that MS doesn’t have a significant share…”, I don’t know what this is about to be honest. They have just recently moved into this space, and will be gaining momentum over time. Even my wife has said several times that the Surface is the first Microsoft thing that really cought her interest, and that she is now constantly telling me to buy (she is on a Macbook, uses a couple of iPods and a Lumia 800 (the Lumia is because of me…)).

Point 6 – “For me, killing XNA.”. I don’t really care about that personally, but I believe having an indiegame platform that was utilized properly could have given Xbox a great boost.Not in the form of increased revenue, but on the form of free publicity and support from active gamers, as well as a thing that separates it from the other gaming platforms. Instead they made it, as I understand it, a pretty poor experience, which they are now killing off in a big way. .

Point 7 – “XBOX vnext rumoured online only”, is something I couldn’t care less about. I guess there is a small group of people that doesn’t have reliable internet, or can’t get an “always connected” scenario up and running. But they are probably quite few… So I guess the biggest reason people don’t like it is that it gives Microsoft more “control”. Making things like hacking the box harder, as well as bootlegging games…which I believe is a moot point…

Ok, so all in all, I did not agree with all the points in that post, but at least a few of them…

The funky thing is that 2 of the people saying it was wrong, both have extensive experience in the Microsoft areas. However, they have very separate opinions on why it was wrong. One of them told me that we could talk again after an upcoming Microsoft conference, indicating that during this conference the future of .NET would get clearer and solidify that it isn’t dying(and that person should know if we put it like that). The other one said that .NET “is so 2005”, and that WinRT is the future. But that .NET would still be around as there are big legacy systems (SharePoint, CRM, Ax/Nav etc) that still required .NET. So basically, “.NET isn’t going away, because there are legacy stuff that requires it, and since there is money in those, .NET will stick around”. Sweet, that means that .NET is really legacy, and will only be there because of legacy reasons. So basically it is the new VB6… I guess it kind of makes sense, but I’m not sure I like it… We have to leap forward at times, it is just evolution, so of course.NET will be replaced at some point…but I’m really not sure that we are there yet…

Now that I have explained my views on the points in that blog post, let me go ahead and blurt out some of my own thoughts…

Let’s start with something that used to be very dear to me, Silverlight. I can understand why Microsoft would kill off this product. Without plug-in support on a lot of platforms, Silverlight could never be that “reach all platforms technology” that Microsoft initially tried to get it to be. It just wasn’t possible. But, and that is a major “but”, they forgot that it turned out to be a GREAT platform for intranet applications, and still is to be honest. It solves a bunch of problems that pretty much no other platform does, except Adobe Air. It works cross-platform, Windows AND Mac. It is easy to deploy, manage and update.

But if we look away from the technical reasons why they shouldn’t have killed it, there are other factors involved that are more serious. Having Microsoft build, and push a platform as hard as they did with Silverlight, just to kill it off a year or two later left a lot of developers scared and questioning. What platforms from Microsoft can you really bet on? Which ones will really be there in the future? If they are willing to kill off Silverlight after that massive investment, what platform is really a safe bet anymore. I hear this from a lot of people, and I think killing it off hurt Microsoft a lot more than just the loss of a great platform. (And yes, it was a great platform, and I continously hear questions about why it was killed, and that it sucked that it did. It isn’t just me).

And to top it off, twisting the knife and extra turn or two, they decided to add support for Flash in IE10 Metro. Making it a plug-in supporting browser, but not supporting Microsoft’s own plug-in. It just doesn’t make sense, and feels very wrong. And adds even more questions from devs around me… (Yes, I get to answer a LOT of questions about Silverlight due to my previous involvement in the platform…)

And that brings me to another point regarding Silverlight. I am calling it dead. I am saying that they KILLED it. But they never really did. They haven’t officially done so in my opinion. They stopped talking about it, the stopped supporting it in IE10 metro, and they answer all questions about its future with a quote about support agreements… So I am, like pretty much everyone else, calling it dead.

The next thing that bugs me about the current situation is XAML. If Silverlight supposedly has been “converted” into the dev platform for WP and Metro-apps (yes, I did it, I called them Metro-apps), which a lot of Microsoft claim, how come that both those platforms have different XAML support. Which on top of it all are both different from WPF’s XAML. And on top of that, both have less features than both Silverlight and WPF. Microsoft have to get it together and make XAML/C# a uniform thing across all platforms if they want to succeed. However, if they can really do that, then they have a GREAT platform to move forward on. Add support for it on Xbox as well, and they truly have a tchnology that spans the entire Microsoft platform.

The last gripe, and honestly the biggest, is marketing, which is the reason people are questioning the future of .NET and so on. And a big part of why Microsofts strategy for the future is so confusing up at moment. With the release of Windows 8, I believe they made 2 massive marketing errors. Not mentioning the marketing fail of trying to be Apple before the release…

The first one is the name “Windows RT”. Who the hell knows what that means? I do, but my mother, wife and non-geek friends have no idea. For them buying a slate today is really confusing. A lot of them want a Windows slate, but they have no idea of the differences between the OS versions and so on. Buying and iPad is just so simple. You only have to choose the size of storage. While in the Microsoft world, there aremultiple manufacturers, lots of formfactors and on top of that, apparently 2 operating systems. Well, average Joe only sees one, Windows, but there really are 2. They should have called it “Windows 8 Light” or “Windows 8 Slate Edition” or something. That would have made sense to the consumers, which Microsoft is really targeting with this release…

On top of that, if they had made it less obvious from a UI perspective that you enter desktop mode in the WinRT version, people wouldn’t have asked why they couldn’t run all desktop apps. Just a simple thing like launching Office wihout first showing the desktop would have removed that confusion I believe… WinRT without a desktop UI would make more sense…

Secondly, they should not have stopped focusing on the .NET devs. They should not have made all their demos in HTML/JavaScript. They should not have released all their demo-code as HTML/JS before the C#/XAML versions. They should not have called everything that isn’t WinRT for “legacy”. They should have focused on their loyal developer group to begin with, instead of trying to attract new devs by somewhat alienating their existing developers… They could have done both. They could even have focused a lot on recruiting new devs with HTML/JS, but they should have ensured the support of their .NET devs by explaining how they are still great and extremely important to Microsoft and the WinRT platform…

If Windows 8 turns out to be the great platform for apps that they hope for, the other devs will follow along sooner or later anyway. At least when the number of Windows 8 machines out there increases and gains a large marketshare. They won’t jump to Windows before there are machines out there. So I think thet should have focused on they guys that have supported them for years, and then focus on the others when the marketshare was greater…

And finally, I must give my support to Microsoft. I believe that Windows 8 is the massive shift that Microsoft needs to be able to move forward, and to diferentiate it self from they used to be. Very little has happened from a UI standpoint since Windows 95…it is time to move on. It is time to kill the start menu. It is time to do something new. It is time to let Windows 8 start a new era of the PC. Just look at all the cool new formfactors that are coming out. Just look at the fact that my wife wants a Surface. They are definitely doing something right!

Unfortunately, the disjointed experience that currently is Windows 8 is alienating a lot of people. I agree that the Metro vs Desktop situation is a little weird. I understand it, but it is weird. Having that said, a few UI tweaks could have made it less weird and confusing to the consumers. But to move forward from something familiar (Windows 95 to Windows 7), we have to go through a couple of phases of not so comfortable before emerging better on the other side. Windows 8 is still just a first version. Give it a few, like with all Microsoft products, and it will mature and feel natural.

Unfortunately, Windows 8.1 is probably adding the start menu back in, and the option to boot to desktop. I can understand that they do this after the massive outcry that has been heard from the community. But it also makes me feel as though they are a little bit insecure. I think they should just push through it, and go for it. People will get used to it! People learn to ride bikes and drive cars as well. It might not be easy to begin with, and takes time to learn, but once we do, we don’t care that we had to learn it before doing it.

Go ahead and tell me that I lost the plot, that I am stupid etc in the comments. I can take it…

Cheers!

Building a simple custom STS using VS2012 & ASP.NET MVC

chris@59north.com — Tue, 09 Apr 2013 09:43:36 +0200

In my previous post, I walked through how “easily” one can take advantage of claims based authentication in ASP.NET. In that post, I switched out the good old forms authentication stuff for the new FedAuth stuff. In this post, I want to take it a step further and actually federate my security, but instead of just using the Windows Azure ACS’s built in identity providers, I want to build a very simple one of my own.

A lot of the solution is based on the STS project that we could get by using VS2010 and the WIF SDK. However, this project was a Web Site project using Web Forms, and I really wanted a MVC version for different reasons.

If you are fine with using VS2010 and the WIF SDK, adding a custom STS is really easy. Just create a new web project, right-click the project and choose “Add STS Reference…” and then, walking through the wizard, there will be a step that offers you to select an STS. In this step, you choose “Create a new STS project…”, which will generate a custom STS project that you can modify to your needs. Unfortunately, that option isn’t available in VS2012. Using the “Identity and Access” add-on, you are only allowed to connect to an existing STS, the ACS or a local test STS, not an STS project.

So, the task is to create a custom STS based on the stuff from the WIF SDK, but updated to run MVC and VS 2012. The task however, is NOT to create and ADVANCED and configurable STS that will replace things like ADFS and Thinktecture’s Identity Server. It will be a very simple STS that can be extended and modified to pretty much whatever one might need. You could for example combine it with my previous post and build and STS based on the ASP.NET providers… Neither is it the goal to create a very well architected application. The goal is to create an STS that works as a proof of concept. It will have a bunch of coupling and hard-coded values that really should be refactored out to config and so on, but the main goal was to show the general idea…

Ok, after all of that disclaimer stuff, it is time to get started!

I start with a new empty MVC 4 project, and even if “empty project” actually means almost empty nowadays, I still remove the NuGet package for WebApi (as well as all related packages). Once that is gone, there is still the matter of removing a line of code in Global.asax.cs to get the whole thing to build… But once that is done, I can start looking at the actual implementation…

Unfortunately, there is actually one more step before I can do that. I need to prepare a certificate to use for signing the tokens. In this case, I am just quickly generating a new self-signed cert using a tool that can be found here. It is a GUI-based way of creating a self-signed cert which removes the need to get down and dirty with the command-line and learning the 20 parameters needed to create a cert.

I save the cert to a pfx and put it somewhere where I can find it (on the desktop of course). Next I install the cert by double clicking it, choosing to install it using LocalMachine and letting the installation tool decide where to put it. Once it has been installed, I need to get hold of the public key, which is not that hard. Using mmc.exe and the Certificate snap-in I can export the cert as a Base-64 encoded .CER file. Once I have the CER file, I can open it in Notepad and get the public key, which I will need in a minute…

Now that I have a cert for signing the tokens, it is time to add the metadata Xml needed for relying parties to interact with the STS. I fudged this by stealing the metadata file from the WIF SDK implementation and switching out some values

In my version, it looks like this

<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor ID="_70a250d5-e3e1-494a-a392-7ed1736f3180" entityID="http://customsts.dev/" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
  <RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706" 
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
    <KeyDescriptor use="signing">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>[MY MASSIVELY LONG KEY]</X509Certificate>
        </X509Data>
      </KeyInfo>
    </KeyDescriptor>
    <ContactPerson contactType="administrative">
      <GivenName>Chris Klug</GivenName>
    </ContactPerson>
    <fed:ClaimTypesOffered>
      <auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706">
        <auth:DisplayName>Name</auth:DisplayName>
        <auth:Description>The name of the subject.</auth:Description>
      </auth:ClaimType>
      <auth:ClaimType Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706">
        <auth:DisplayName>Role</auth:DisplayName>
        <auth:Description>The role of the subject.</auth:Description>
      </auth:ClaimType>
    </fed:ClaimTypesOffered>
    <fed:SecurityTokenServiceEndpoint>
      <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
        <Address>http://customsts.dev/</Address>
      </EndpointReference>
    </fed:SecurityTokenServiceEndpoint>
    <fed:PassiveRequestorEndpoint>
      <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
        <Address>http://customsts.dev/</Address>
      </EndpointReference>
    </fed:PassiveRequestorEndpoint>
  </RoleDescriptor>
</EntityDescriptor>

The parts that I have modified are:
The “entityID” attribute on the EntityDescriptor element.
The “GivenName” for the “ContactPerson”
The “Address” fields for the “EndpointReference”s
And finally the content of the “X509Certificate” element. This value is the key from the CER file put on one line (everything between “-----BEGIN CERTIFICATE-----“ and “-----END CERTIFICATE-----“).

It is possible to generate new FederationMetadata.xml files using different tools, or by hand if you for some reason know the exact Xml required by heart. You can even dynamically generate the Xml using code if you want to. If that is your thing, I suggest looking around the web or possibly here. (I haven’t tried what is said in that post, but it came up while Googling…)

Ok, now that I have the metadata that describes how the STS works and the certificate, I guess it is time to implement the STS functionality…

The first thing I create is an AccountController with a single Login() action. The Login() action takes a string parameter called “returnUrl” which will be used when redirecting from the login. I add the returnUrl to the ViewBag and return a view.

public ActionResult Login(string returnUrl)
{
    ViewBag.ReturnUrl = returnUrl;
    return View();
}

The view in itself is ridiculously simple. It gives the user a form to be used for logging in, including a username textbox and a password textbox. The form is set to post back to a Login() action, including the returnUrl as a querystring

@using (Html.BeginForm(new { returnUrl = ViewBag.ReturnUrl }))
{
    ...
}

The target action uses the posted data to authenticate the user and log in the user using FormsAuthentication. It then redirects the user back to the returnUrl.

[HttpPost]

public ActionResult Login(LoginModel model, string returnUrl)
{
    if (ModelState.IsValid && model.UserName.Equals("chris", StringComparison.OrdinalIgnoreCase) && model.Password.Equals("password"))
    {
        FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);
        return Redirect(returnUrl);
    }

    ViewBag.ReturnUrl = returnUrl;
    ModelState.AddModelError("", "The user name or password provided is incorrect.");
    return View(model);
}

Yes, FormsAuthentication! I know I said I was going to do FedAuth stuff, and still I am using FormsAuth. However, this is only locally on the STS. This will be used to create the FedAuth token later on. The cool thing is that as long as the FormsAuth cookie is in place and valid, the user will automatically be logged in when sent to the STS. Basically enabling single sign on (SSO).

That is actually it for the authentication part. As you can see, I am using hard-coded values, which sucks…but it is a demo! Simple to switch out for real stuff though…

To get the forms stuff going, I need to add some config to the web.config. It looks like this

<system.web>
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
    <authorization>
      <deny users="?" />
    </authorization>
    ...
</system.web>

So…so far the flow is the following: The user browse to the relying party. The Relying party redirects the user to the STS. The STS redirects the user to the log in page. The user logs in and gets redirected back to the root page.

So, what happens at the root page? Well, that is where the token is generated and sent back to the relying party.

I guess it is time to add a HomeController to the solution. The HomeController’s Index() action checks if the user is authenticated, which he/she always should be as the site is using FormsAuthentication denying unauthorized users access.

If the user is logged in, it checks the querystring for a parameter called “wa”. This is added by the federation module when redirecting the user to the STS. If the value of the “wa” parameter is “wsignin1.0”, the user wants to sign in, which would be the standard scenario. If the “wa” parameter is there and set to “wsignin1.0”, I create an HTML form on the fly, and send that back to the user.

public const string Action = "wa";
public const string SignIn = "wsignin1.0";

 
public ActionResult Index()
{
    if (User.Identity.IsAuthenticated)
    {
        var action = Request.QueryString[Action];

        if (action == SignIn)
        {
            var formData = ProcessSignIn(Request.Url, (ClaimsPrincipal)User);
            return new ContentResult() { Content = formData, ContentType = "text/html" };
        }
    }
    return View();
}

Ok, so the flow is now extended with another redirect. In this case, a form is created including the authentication token. This form is then automatically posted back to the relying party. Flow complete!

But as the curious person you are, you have probably realized that I have not done any federated auth stuff at all. All i have done is call a method called ProcessSignIn() which returns an HTML form in the form of a string. And no, ProcessSignIn() isn’t some neat built in thing… So let’s look at how it creates the form!

The first thing I do in the ProcessSignIn() method, is to create a SignInRequestMessage instance, using WSFederationMessage.CreateFromUri(). However, to be able to use these classes, I first add a reference to System.IdentityModel and System.IdentityModel.Services.

Besides the SignInRequestMessage, I also need signing credentials. In my case I create these by creating a new X509SigningCredentials, passing in the cert I created earlier, and put in the cert store. This requires a little bit of code, but I will not cover that. If you want to know how to get a cert from the store, I suggest Googling it, or downloading my sample code at the end…

Ok, now I have a SignInRequestMessage and a X509SigningCredentials object. On top of that, I need a SecurityTokenServiceConfiguration. You can either inherit this, and do some funky stuff like they do in the WIF SDK, or you can do just create an instance of it, passing it the issuer name of the STS and the signing credentials, which is what I do.

In the WIF code, they cache this configuration, which makes me assume that it is a little heavy to create. So in a high-load scenario, I suggest doing that. But being a demo, keeping it simple is the way to go…

The last thing I need (yes, I need even more stuff) is an instance of a class that inherits from SecurityTokenService. In my case, I have created one called CustomSecurityTokenService, which I will get back to in a minute. So I create one of those, passing it the configuration.

Ok, I finally have all the little bits and pieces I need to create my response message. This is created by using the static ProcessSignInRequest() method on the FederatedPassiveSecurityTokenServiceOperations class. Once I have a response message, I can use it to get the HTML form.

private static string ProcessSignIn(Uri url, ClaimsPrincipal user)
{
    var requestMessage = (SignInRequestMessage)WSFederationMessage.CreateFromUri(url);
    var signingCredentials = new X509SigningCredentials(GetCertificate(ConfigurationManager.AppSettings["SigningCertificateName"]));
    var config = new SecurityTokenServiceConfiguration(ConfigurationManager.AppSettings["IssuerName"], signingCredentials);
    var sts = new CustomSecurityTokenService(config);
    var responseMessage = FederatedPassiveSecurityTokenServiceOperations.ProcessSignInRequest(requestMessage, user, sts);
    return responseMessage.WriteFormPost();
}

Ok, there you have it! A whole bunch of standard classes from the framework created and put together in a useful matter. The only thing that I haven’t been covered is the CustomSecurityTokenService, which is responsible for some parts of the generation of the token. More specifically it is the class responsible for setting up a the “Scope” and the identity to add to the token.

When inheriting from SecurityTokenService, you need to do 3 things. You need to pass a SecurityTokenServiceConfiguration to the base class, and implement the GetScope() and GetOutputClaimsIdentity() methods.

The interesting parts are the 2 methods… Let’s start with the GetScope() method, in which you are responsible for creating a new Scope instance and configure it for potential token encryption.

For the sake of simplicity, I will ignore 2 things in this post. The first one being able to limit what relying parties are allowed to use the STS, which can be done by looking at the AppliesTo property of the RequestSecurityToken instance. And the second one being encryption. The sample code includes both, but since I will neither limit the use of the STS, nor encrypt the token by default, I will just skip over that… But it should be done in the GetScope() method…

So all I need to do is to create a new Scope() instance, passing it the Url of the relying party as well as the credentials used for signing the token.

Next, I set the ReplyToAddress of the Scope, which defines where the user is redirected when the form is posted. I pull this Url from the RequestSecurityToken’s ReplyTo property, which is set when configuring the relying party.

protected override Scope GetScope(ClaimsPrincipal principal, RequestSecurityToken request)
{
    var scope = new Scope(request.AppliesTo.Uri.OriginalString, SecurityTokenServiceConfiguration.SigningCredentials);

    scope.ReplyToAddress = request.ReplyTo;

    return scope;
}

The second method, the GetOutputClaimsIdentity(), is just as simple. All that is need here, is to create a new ClaimsIdentity and add the required claims. In this case, I only set the Name and NameIdentifier claims. Like this

protected override ClaimsIdentity GetOutputClaimsIdentity(ClaimsPrincipal principal, RequestSecurityToken request, Scope scope)
{
    var claims = new[]
        {
            new Claim(System.IdentityModel.Claims.ClaimTypes.Name, principal.Identity.Name),
            new Claim(System.IdentityModel.Claims.ClaimTypes.NameIdentifier, principal.Identity.Name),
        };

    var identity = new ClaimsIdentity(claims);

    return identity;
}

Ok, that is all there is to it! A custom STS done and dusted!

However, I guess the question is if it works…? :)

To verify this, I set up the STS in my IIS using a hostheader with the name “customsts.dev”, which I have added in my hosts file. Next, I switch the identity used by the app pool to LocalSystem to give it access to the certificate store. Once I have a site in the IIS and the identity set, it is time to create a new relying party, which is just a glorified new ASP.NET web application.

In the new “relying party” web application, I use the “Identity and Access” add-on in VS to add a “reference” to my STS. During the configuration of the STS, I pointed it to “http://customsts.dev/FederationMetadata/2007-06/FederationMetadata.xml”, disabled “require ssl”. This will re-write the web.config file and add all the required federation stuff. All but one little thing… To get the ReplyTo of the request set properly, I manually had to add the “reply” attribute to the wsFederation element like this

...
<wsFederation passiveRedirectEnabled="true" issuer="http://customsts.dev/" realm="http://localhost:49285/" 
                reply="http://localhost:49285/" requireHttps="false" />
...

That’s it! The add-on configures the rest for us. So browsing to the new web, I get redirected to the STS, where I can log in and get redirected back to the web with a token that authenticates me.

The code for this is available here: DarksideCookie.AspNet.FedAuth.CustomSTS.zip (1.37 mb)

Cheers!

Claims-based identities in ASP.NET MVC 4.5 using the standard ASP.NET providers

chris@59north.com — Wed, 27 Mar 2013 15:52:22 +0200

Lately I have done a bit of work with claims-based identities. Most of it has been about doing federated security using the Windows Azure Access Control Service. However, I have also been working with a client that wanted claims-based identity management without federating it. For the moment, they just want to run locally, but they want to be prepared for a future where they might expand and move to a federated paradigm. And also, the way that they handle multitenancy is a perfect fit for claims…

Interestingly enough, working through their scenario, I found that there is a lot of information on the web about how to set up claims-based identity management using federation, but there is not a whole lot around for running it locally… It might not be that surprising considering that federated security has some really good points. Having been faced with this lack of information, I had to come up with a solution on my own, and building on what I built for them, I decided to create an extended example…

Massive disclaimer first! I have limited experience in the newer features of ASP.NET MVC, so some of the things I am building here might already be built in, but I don’t care…building this gave me some good insight, so I’m going to go ahead and blog it anyway…

As of .NET 4.5, Windows Identity Foundation has been moved from an external library to being a part of the framework. And ClaimsPrincipal is now the the base class for the principals being used in ASP.NET. So it is pretty obvious that Microsoft believes that this is the future…

Anyhow…let’s get started! The first thing to do is to create a new empty MVC 4.5 project and get it secured, which is done like this.

After the project has been created, the web.config has to be changed to enable the “new” security stuff. First of all, 2 new sections need to be added to the top of the file like this

     <?xml version="1.0" encoding="utf-8"?>

    <configuration>

      <configSections>

        <section name="system.identityModel" 

                 type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

        <section name="system.identityModel.services" 

                 type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

      </configSections>

      ...

    </configuration>

This will enable the configuration of the former WIF stuff…hmm..I don’t know what to call it now…is it still WIF? All the code I will be writing uses the FederatedAuthentication class, but I don’t want to bring in federation, so that seems wrong… I will just keep calling it WIF. If that is wrong, let me know…

Ok, now that those sections are in there, I can configure it if needed. Luckily, in this scenario, I am building really simple things, so the configuration needed is tiny. Normally it is much more complicated as we need to configure federation. And to be honest, the only reason that I need any configuration at all is that I will be running this without SSL for this demo… So I need to add this config

    <system.identityModel.services>

        <federationConfiguration>

          <cookieHandler requireSsl="false" />

        </federationConfiguration>

    </system.identityModel.services>

The final thing I need to configure to get the WIF stuff done and dusted, is to add an HttpModule to the request pipe. The module in question is called SessionAuthenticationModule, and it is added like this

    <system.webServer>

        ...

        <modules>

          <add name="SessionAuthenticationModule" 

               type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

        </modules>

    </system.webServer>

Ok…that’s it…all that is left from a configuration point of view is to secure the site. This is done using old-fashioned forms authentication. So I set up the site to use Forms authentication, and deny access to unauthorized users like this

    <system.web>

        <authentication mode="Forms">

            <forms loginUrl="/Auth/Login" defaultUrl="/">

                <credentials passwordFormat="Clear">

                    <user name="Admin" password="changeme" />

                </credentials>

            </forms>

        </authentication>

        <authorization>

            <deny users="?" />

        </authorization>

    </system.web>

As you can see, I have set it up so that the login page is at “/Auth/Login”, and the default Url is the root of the site. I have also added a hardcoded set of credentials just to have a way to test my solution before I get user management going. This will be replaced by the membership provider later…

Ok, that’s it for configuration… The next thing is to create a home page. So I create a basic HomeController with a single Index() action, and a corresponding view that has this bit of HTML

    <!DOCTYPE html>

    <html>

    <head>

        <title>Welcome</title>

    </head>

    <body>

        <div>

            <h1>Welcome @User.Identity.Name</h1>

            <div>

                <h2>Claims</h2>

                @foreach (var claim in ((ClaimsPrincipal) User).Claims)

                {

                    <div>@claim.Type : @claim.Value</div>

                }

            </div>

            <br/>

            @Html.ActionLink("Log Out", "SignOut", "Auth")

        </div>

    </body>

    </html>

Ok, next up is the AuthController, with its 2 Login() actions and a SignOut() action. (This will be extended with registration later on, but let’s start here…)

The first Login() action returns a view that has a textbox for username and a password box for the password. This view posts the login information to the second Login() action, which is responsible for the real functionality… This action takes a LoginModel which is a basic model offering Username and Password properties.

The controller starts by validating the modelstate, and if it succeeds, it uses the FormsAuthentication class to authenticate the user based on the hardcoded credentials from the web.config file. If the credentials are ok, it creates a set of basic claims, which are used to create a new ClaimsIdentity, which in turn is used to create a ClaimsPrincipal, which in turn is used to create a SessionSecurityToken, which in turn is written to a cookie using the FederatedAuthentication class. After this, the user is redirected back to the home page.

Ok, that was a lot of “which in turn”…the code is quite simple

    [HttpPost]

    public ActionResult Login(LoginModel model)

    {

        if (ModelState.IsValid)

        {

            if (FormsAuthentication.Authenticate(model.Username, model.Password))

            {

                var claims = new[]

                            {

                                new Claim(ClaimTypes.NameIdentifier, model.Username), 

                                new Claim(ClaimTypes.Name, model.Username)

                            };

                var identity = new ClaimsIdentity(claims, "Forms");

                var principal = new ClaimsPrincipal(identity);

                var token = new SessionSecurityToken(principal);

                FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(token);

                return Redirect(FormsAuthentication.DefaultUrl);

            }

            ModelState.AddModelError("IncorrectData", "Could not validate username and/or password");

        }

        return View(model);

    }

The reason that I am setting both the ClaimTypes.NameIdentifier and the ClaimTypes.Name is that the ClaimTypes.Name is used by the system to set the Name property of the users identity, but I really want the NameIdentifier as the “key” for my user.

Ok, that’s it! Except for the SignOut() action which is almost a one-liner

    public ActionResult SignOut()

    {

       FederatedAuthentication.SessionAuthenticationModule.SignOut();

       return RedirectToAction("Login");

    }

Running this application will redirect you to the login page where you can login. Logging in will generate a new token cookie and then redirect you back to the home page showing you the users name. Unfortunately, this is hard to show in a blog, but it works…trust me.

Unfortunately, this is a very crappy way of doing things… You can only add users in the web.config, which sucks, which is the reason why one should use the membership provider instead.

You are free to have what ever opinion you want regarding the providers I am using, but they are quick to set up, and work in basic scenarios! I agree that they have some design flaws, but I don’t care! They are there, and ready to use…

To start using the ASP.NET providers, I need a database. So I fire up my SQL Server Management Studio and create a new database named AspNetDb. Once that database is created, I can create the required tables by executing the aspnet_regsql.exe executable using the Visual Studio command prompt. Next I create a user called “webuser” and give it full access to the created tables in AspNetDb database using the predefined database roles.

Ok, now that the database is done, I guess it is time to configure the providers, or at least the membership provider. I will start by walking through the authentication part, and then add roles and custom claims later.

Configuring the membership provider is basic stuff, and well documented, so I won’t go through that. My configuration looks like this

    <connectionStrings>

        <add name="AspNetDb" connectionString="Data Source=.;Initial Catalog=AspNetDb; User Id=webuser; Password=webuser;" />

    </connectionStrings>

    <membership defaultProvider="SqlProvider">

      <providers>

        <clear />

        <add name="SqlProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="AspNetDb" 

             applicationName="DarksideCookie.AspNet.FedAuth.Local" enablePasswordRetrieval="false" enablePasswordReset="true" 

             requiresQuestionAndAnswer="false" requiresUniqueEmail="true" passwordFormat="Hashed" 

             minRequiredNonalphanumericCharacters="0" minRequiredPasswordLength="3" />

      </providers>

    </membership>

There is a lot of config in there, I know, but it is only because I wanted to decrease the somewhat ridiculous levels of security the provider puts on the password by default…

Time to update the Login() action. I replace the FormsAuthentication stuff with the Membership class instead. Other than that, it looks pretty much the same

    if (ModelState.IsValid)

    {

        if (Membership.ValidateUser(model.Username, model.Password))

        {

            var user = Membership.GetUser(model.Username);

            var claims = new List<Claim>

                        {

                            new Claim(ClaimTypes.NameIdentifier, user.Email), 

                            new Claim(ClaimTypes.Name, user.UserName)

                        };

            var identity = new ClaimsIdentity(claims, "Forms");

            var principal = new ClaimsPrincipal(identity);

            var token = SessionSecurityToken(principal);

            FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(token);

            return Redirect(FormsAuthentication.DefaultUrl);

        }

        ModelState.AddModelError("IncorrectData", "Could not validate username and/or password");

    }

    return View(model);

Ok…sweet! That was a simple change! Let’s try it out!

Oh…ehh…I need a user to login. I guess I need a way to register as well!

To do this, I add 2 new actions called Register() to the AuthController, and a simple registration page that looks like this

    <!DOCTYPE html>

    <html>

    <head>

        <title>Register</title>

    </head>

    <body>

        <div>

            <div>

                <b>@Html.ValidationSummary()</b>

            </div>

            @using (Html.BeginForm())

            {

                <div>

                    @Html.LabelFor(model => model.Username)

                    @Html.TextBoxFor(model => model.Username)

                </div>

                <div>

                    @Html.LabelFor(model => model.Email)

                    @Html.TextBoxFor(model => model.Email)

                </div>

                <div>

                    @Html.LabelFor(model => model.Password)

                    @Html.PasswordFor(model => model.Password)

                </div>

                <div>

                    @Html.LabelFor(model => model.RepeatPassword)

                    @Html.PasswordFor(model => model.RepeatPassword)

                </div>

                <div>

                    <input type="submit" value="Register" />

                </div>

            }

        </div>

    </body>

    </html>

The action that takes the posted login data validates the data, and then uses the Membership class to create a new user. However, to be nice, I also sign in the user before redirecting the user to the homepage. Like this

    [HttpPost]

    public ActionResult Register(RegisterModel model)

    {

       if (ModelState.IsValid)

       {

           if (model.Password != model.RepeatPassword)

           {

               ModelState.AddModelError("RepeatPasswordError", "Could not verify password...");

               return View(model);

           }

           var user = Membership.CreateUser(model.Username, model.Password, model.Email);

           var claims = new List<Claim>

                        {

                            new Claim(ClaimTypes.NameIdentifier, user.Email), 

                            new Claim(ClaimTypes.Name, user.UserName)

                        };    

           var identity = new ClaimsIdentity(claims, "Forms");

           var principal = new ClaimsPrincipal(identity);

           var token = new SessionSecurityToken(principal);

           FederatedAuthentication.SessionAuthenticationModule

                .WriteSessionTokenToCookie(GetSecurityTokenForMembershipUser(token));

           return Redirect(FormsAuthentication.DefaultUrl);

       }

       return View(model);

    }

Ok, that wasn’t too hard! And yes, there is some code-duplication in here, but that is just for the simplicity of the post. In the sample code, this has been refactored out, don’t worry! :)

The last step in enabling the registration is to let people access it without being authenticated. This is easily done by adding a <location /> element to the web.config, and allow anonymous access. Like this

    <location path="Auth/Register">

        <system.web>

            <authorization>

                <allow users="*" />

            </authorization>

        </system.web>

    </location>

Now there is a way to register, as well as a way to login. After testing that it all works, which I still can’t show on the blog, it is time to add some role functionality…

To configure the role provider, I add the following config to my web.config

    <roleManager cacheRolesInCookie="false" defaultProvider="SqlProvider" enabled="true">

      <providers>

        <clear/>

        <add connectionStringName="AspNetDb" applicationName="DarksideCookie.AspNet.FedAuth.Local" name="SqlProvider"

             type="System.Web.Security.SqlRoleProvider" />

      </providers>

    </roleManager>

The important things to note here is that I set “enabled” to true, but turn off cookie caching. Why? Well, because the role information will be set in the token anyway, so there is no need to add 2 cookies for that…

In this very simple demo, I leave it up to the user to define what roles he/she wants to be member of as a part of the registration process. This is potentially not the most common scenario, but it makes it simple. Once that this has been added, I can modify the Register() action to add the user to the defined roles as well. However, before adding the user to the role, i make sure that the role is available, and if not, I add it.

The modification means adding the following code right after the user has been created

    ...

    foreach (var role in model.Roles.Where(x => x.Checked))

    {

        if (!Roles.RoleExists(role.Name))

            Roles.CreateRole(role.Name);

        Roles.AddUserToRole(model.Username, role.Name);

    }

    ...

Here is a funky little kicker though. As long as the user has roles defined, the ClaimsPrincipal and the SessionSecurityToken will magically work together and automatically generate the role claims for me.

Ok, trying this out will prove that the role claims are added as before, but also the role claims. Cool…a little confusing…but cool. I actually added them manually when I first built it, but got duplicates. So I removed my code and it just worked…

So, now I have authentication using the membership provider and roles using the role provider without doing any plumbing code or database work…kind of neat. The only thing left now is to add custom claims using the profile provider…

Configuring the profile provider is pretty much identical to the previous provider configurations, with one exception, I also have to define what profile properties I want to have available.

    <profile defaultProvider="SqlProvider">

      <providers>

        <clear/>

        <add name="SqlProvider" type="System.Web.Profile.SqlProfileProvider"

             connectionStringName="AspNetDb" applicationName="DarksideCookie.AspNet.FedAuth.Local" />

      </providers>

      <properties>

        <add name="Organization" type="String" customProviderData="http://chris.59north.com/claims/organization/" />

      </properties>

    </profile>

In this case, I define a single profile property called “Organization” of type string. The profile configuration also offers the ability to add custom data to each of the properties using an attribute called customProviderData. Normally, this attribute is supposed to be used by custom profile providers to do custom work or whatever, but in this case, I’m hijacking that attribute to add the name of the claim that it corresponds to.

Next I modify the registration page and model to include an Organization property, and then I head to my AuthController to update the registration and token creation code.

During the registration, I create a new profile using the ProfileBase class, and set the profile property before saving the new profile to the database. This is done by adding the following code right after the code for adding the roles

    var profile = ProfileBase.Create(user.UserName, true);

    profile.SetPropertyValue("Organization", model.Organization);

    profile.Save();

While creating the claims for the session token, I bring up the profile and use the values in it to populate the claims. Notice the use of the property.Attributes[“CustomProviderData”] to get hold of the claim type name.

    var profile = ProfileBase.Create(user.UserName, true);

    foreach (SettingsProperty property in ProfileBase.Properties)

    {

        claims.Add(new Claim(property.Attributes["CustomProviderData"].ToString(), profile[property.Name].ToString()));

    }

Ok, that’s it! Registering a new user and logging in, I am now faced with a page that looks like this

Yes, I do need to create a new account in this case, as the profile is populated at registration. If you really don’t want to create a new user because you love the username you used before, you can just open the database and clean out the existing user and roles…

That’s all folks! Claims-based identity management using the ASP.NET providers instead of federation. This might seem unnecessary, but it does set you up nicely for the future. Having claims-based authentication and authorization offers a quick route to enable federated security if needed.

A little side-note though… Don’t add too many claims. They are sent back and forth as a cookie with each call, so adding a lot of them will slow down the communication…

And as usual, there is obviously code for this. A complete solution is available for download here:DarksideCookie.AspNet.FedAuth.Local.zip (3.74 mb)

Sorry for the hefty download! ASP.NET MVC adds quite a few NuGet packages, bloating the solution a LOT, and I am not sure if it is safe to ditch the NuGet packages and get them re-downloaded when opening the solution… Sorry… I suck at NuGet…

Just remember that you have to configure the database as described, and update the database connection in the web.config.

Cheers!

Compressing messages for the Windows Azure Service Bus

chris@59north.com — Tue, 19 Mar 2013 10:16:02 +0200

As a follow up to my previous post about encrypting messages for the Service Bus, I thought I would re-use the concepts but instead of encrypting the messages I would compress them.

As the Service bus has limitations on how big messages are allowed to be, compressing the message body is actually something that can be really helpful. Not that I think sending massive messages is the best thing in all cases, the 256kb limit can be a little low some times.

Anyhow… The basic idea is exactly the same as last time, no news there…but to be honest, I think this type of compressions should be there by default, or at least be available as a feature of BrokeredMessage by default… However, as it isn’t I will just make do with extension methods…

And if you haven’t read the previous post, here is a quick recap. THere is no way to inherit from BrokeredMessage as it is sealed. Instead, I have decided to create extension methods, which makes it really easy to use them. I have also decided to do two versions. one that relies on reflection, which might be considered bad practice by some, and one that creates a new BrokeredMessage with the compressed version of the body.

So, let’s get started. The extension methods I want to create look like this

public static void Compress(this BrokeredMessage msg)
public static void Decompress(this BrokeredMessage msg)
 
public static BrokeredMessage Compress<T>(this BrokeredMessage msg)
public static BrokeredMessage Decompress<T>(this BrokeredMessage msg)

Let’s start with the reflection based ones, which means the non-generic ones…

The first thing I need to do is get hold of the internal Stream that holds the serialized object used for the body. This is done through reflection as follows

var member = typeof(BrokeredMessage)
    .GetProperty("BodyStream", BindingFlags.NonPublic | BindingFlags.Instance);
var dataStream = (Stream)member.GetValue(msg)

Next, I need to compress the serialized data, which I have decided to do using the GZipStream class from the framework.

This is really not rocket science, but it does include a little quirk. First you create a new Stream to hold the result, that is the compressed data. In my case, that is a MemoryStream, which is the reason for the quirk. If you write to disk, this isn’t a problem, but for MemoryStream it is… Anyhow, once I have a target Stream, I create a new GZipStream that wraps the target Stream.

The GZipStream behaves like a Stream, but when you read/write to it, it uses the underlying Stream for the data, and compresses/decompresses the data on the way in and out… Makes sense? I hope so… Whether it compresses or decompresses, which basically means whether you write or read from it, is defined by the second parameter to the constructor. That parameter is of type CompressionMode, which is an enum with 2 values, Compress and Decompress.

Once I have my GZipStream, I basically just copy my data from the source Stream into it, and then close it. And this is where the quirk I talked about before comes into play. The GZipStream won\t finish writing everything until it is closed. Flush does not help. So we need to close the GZipStream, which then also closes the underlying Stream. In most cases, this might nor be a problem, but for a MemoryStream, it actually is. Luckily, the MemoryStream will still allow me to read the data in it by using the ToArray() method. Using the returned byte[], I can create a new MemoryStream, which I can use to re-set the body of the BrokeredMessage.

And after all that talk, the actual code looks like this

var member = typeof(BrokeredMessage).GetProperty("BodyStream", BindingFlags.NonPublic | BindingFlags.Instance);
using (var dataStream = (Stream)member.GetValue(msg))
{
    var compressedStream = new MemoryStream();
    using (var compressionStream = new GZipStream(compressedStream, CompressionMode.Compress))
    {
        dataStream.CopyTo(compressionStream);
    }
    compressedStream = new MemoryStream(compressedStream.ToArray());
    member.SetValue(msg, compressedStream);
}

Ok, so going in the other direction and decompressing the data is not much harder…

Once again, I pull out the Stream for the body using reflection. I then create a Stream to hold the decompressed data. After that, I wrap the body-stream in a GZipStream set to Decompress, and copy the contents of it to the MemoryStream. After closing the GZipStream, I Seek() the beginning of the MemoryStream before re-setting the BrokeredMessage’s Stream.

Like this…

var member = typeof(BrokeredMessage).GetProperty("BodyStream", BindingFlags.NonPublic | BindingFlags.Instance);
using (var dataStream = (Stream)member.GetValue(msg))
{
    var decompressedStream = new MemoryStream();
    using (var compressionStream = new GZipStream(dataStream, CompressionMode.Decompress))
    {
        compressionStream.CopyTo(decompressedStream);
    }
    decompressedStream.Seek(0, SeekOrigin.Begin);
    member.SetValue(msg, decompressedStream);
}

Ok, that’s it! At least for the reflection based methods. Let’s have a look at the ones that don’t use reflection…

Just as in the previous post, I will be extracting the body as the type defined. I then use Json.NET to serialize the object. I then use GZipStream to compress the string.

So let’s take it step by step… First I read the body based on the genericly defined type. I then serialize it using Json.NET. Like this

var bodyObject = msg.GetBody<T>();
var json = JsonConvert.SerializeObject(bodyObject);

Once I have the Json, I create a MemoryStream to hold the data, wnd then use the same method as shown before to compress it. The main difference is that I don’t re-set the Stream on the BrokeredMessage, instead I convert the compressed data to a Base64 encoded string and use that as the body for a new message. Finally, I copy across all the properties for the message.

There is a tiny issue here in my download, which is also present in the download for the previous blog post. It only copies the custom properties, it does not include the built in ones… But hey, it is demo code…

Ok, so it looks like this

BrokeredMessage returnMessage;
 
var bodyObject = msg.GetBody<T>();
var json = JsonConvert.SerializeObject(bodyObject);
using (var dataStream = new MemoryStream(Encoding.UTF8.GetBytes(json)))
{
    var compressedStream = new MemoryStream();
    using (var compressionStream = new GZipStream(compressedStream, CompressionMode.Compress))
    {
        dataStream.CopyTo(compressionStream);
    }
    returnMessage = new BrokeredMessage(Convert.ToBase64String(compressedStream.ToArray()));
}

CopyProperties(msg, returnMessage);

And the decompression is not much more complicated. It reads the body of the message as a string. It then gets the byte[] of the string by using the Convert.FromBase64String() method. Those bytes are then wrapped in a MemoryStream and Decompressed using GZipStream. The resulting byte[] is converted back to a string using Encoding.UTF8.GetString(), and then deserialized using Json.NET. The resulting object is set as the body for a new BrokeredMessage right before the rest of the properties are copied across.

BrokeredMessage returnMessage;
 
var body = msg.GetBody<string>();
var data = Convert.FromBase64String(body);
using (var dataStream = new MemoryStream(data))
{
    var decompressedStream = new MemoryStream();
    using (var compressionStream = new GZipStream(dataStream, CompressionMode.Decompress))
    {
        compressionStream.CopyTo(decompressedStream);
    }
    var json = Encoding.UTF8.GetString(decompressedStream.ToArray());
    returnMessage = new BrokeredMessage(JsonConvert.DeserializeObject<T>(json));
}

CopyProperties(msg, returnMessage);

That’s it! That is all the code needed to compress and decompress BrokeredMessages.

To try it out, I created a little demo application. It uses a ridiculous class to break down text into paragraphs, sentences and words to generate a object to send across the wire.

I decided to create something quickly that would generate a largish object without too much work, and string manipulation seemed like a good idea, as I can just paste in lots of text to get a big object. It might not properly show the efficiency of the compression as text compresses very well, but it was easy to build. But do remember that different object will get different levels of compression…

The result of the compression is quite cool. Running it on a message that by default is 72,669 bytes, compresses it down to 3,359 bytes. Once again, it is a lot of text and so on, but to be fairs, the data before compression is binary XML, which is also text…

So the conclusion is that compressing the messages isn’t that hard, but you will potentially gain a lot form doing it. Not only for when your messages break the 256kb limit, but also for smaller messages as they will be even smaller and thus faster across the network…

As usual, there is source code for download. It is available here: DarksideCookie.Azure.Sb.Compression.zip (216.65 kb)

That’s it for this time… Cheers!

Encrypting messages for the Windows Azure Service Bus

chris@59north.com — Tue, 12 Mar 2013 15:09:50 +0200

A week ago I ran into Alan Smith at the Stockholm Cental Station on the way to the Scandinavian Developer Conference. We were both doing talks about Windows Azure, and we started talking about different Windows Azure features and thoughts. At some point, Alan mentioned that he had heard a few people say that they would like to have their BrokeredMessages encrypted. For some reason this stuck with me, and I decided to give it a try…

My first thought was to enherit the BrokeredMessage class, and introduce encryption like that. Basically pass in an encryption startegy in the constructor, and handle all encryption and decryption inside this subclass. However, about 2 seconds in to my attempt, I realized that the BrokeredMessage class was sealed. An annoying, but somewhat understandable decision made by Microsoft. Ok, so I couldn’t inherit the class, what can you do then? Well, there is no way to stop me from creating a couple of extension methods…

Ok, so extension methods would have to be my plan of attack, and as such, the goal would be to create 2 methods that look something like this

public static void Encrypt(this BrokeredMessage msg, IEncryptor encryptor)
public static void Decrypt(this BrokeredMessage msg, IDecryptor decryptor)

where IEncryptor and IDecryptor would be a couple of really simple interfaces like this

public interface IEncryptor
{
    byte[] Encrypt(byte[] data);
}
 
public interface IDecryptor
{
    byte[] Decrypt(byte[] data);
}

So the plan would be that the user created a new BrokeredMessage and set the body and the properties needed, and then he would call Encrypt() on it, and all the information would get encrypted. And when it was received, he would call Decrypt, and the body and the properties would be decrypted and ready for use. And with the interfaces abstracting the actual encryption and decryption, any type of algorithm would be possible to use.

I decided to start by encrypting the body, that is the object passed into the constructor, which is then serialized and passed as the body of the message. So I started looking at ways to access the serialized data…hmm…that seemed harder than expected. The only way to access the body is through the generic GetBody<T>() method. Unfortunately, that requires me to know the type of the body to get hold of it, and on top of that, I would get an object, not the serialized form…hmm…

I also figured out that once you have set the message’s body using the constructor, there is no real way of changing it…

I found 2 ways to get around this. Either I would have to modify the extension methods, or I would have to do some funky stuff. I will start by showing how to do it by changing my extension methods slightly, and then later on, I will show how to do it using reflection.

So to go forward, I had to change my extension methods a little… They ended up looking like this instead

public static BrokeredMessage Encrypt<T>(this BrokeredMessage msg, IEncryptor encryptor)
public static BrokeredMessage Decrypt<T>(this BrokeredMessage msg, IDecryptor decryptor)

As you can see, I am now forced to define the type of the body, as well as return a new BroekeredMessage instead of updating the original…but it will still work…

I will ignore the implementation of the IEncryptor and IDecryptor interfaces for now. The whole idea is that the implementation of this should not matter. They should take a byte array, and encrypt or decrypt it for me….that’s it…

The first order of business is to implement the Encrypt<T>() method. I need to have an encrypted message to be able to try my decryption, so I found that to be a good place to start…

First thing to do is to get hold of the body object, and serialize it. I decided to serialize it using JSON as it has nice and compact syntax…

var body = msg.GetBody<T>();
var json = JsonConvert.SerializeObject(body);

Now that I have the serialized object in string form, I can easily turn that into a byte array using the UTF8 encoding, and pass that to the encryptor. Once that is done, I can convert the byte array into a Base64 encoded string using the Convert class.

var bytes = encryptor.Encrypt(Encoding.UTF8.GetBytes(json));
var encryptedObject = Convert.ToBase64String(bytes, 0, bytes.Length);

Once the encryption of the serialized object is done, and converted to a Base64 encoded string, I can just creat a new BrokeredMessage, using that string as the actual body.

var encryptedMessage = new BrokeredMessage(encryptedObject);

All that is left now is to encrypt the properties, set them on the new BrokeredMessage, and return it…

Unfortunately, the BrokeredMessage’s properties are of type object. Not that they can take actual objects, but because that they can take any simple type. So to handle this, I decided to wrap the property value in a class that would contain the property value as a string, as well as a definition of what type it was. The wrapper looks like this

public class BrokeredMessagePropertyWrapper
{
    public string Type { get; set; }
    public string Value { get; set; }
 
    public object GetValue()
    {
        switch (Type)
        {
            case "Int32":
                return int.Parse(Value);
            case "Double":
                return double.Parse(Value);
            case "Decimal":
                return decimal.Parse(Value);
            default:
                return Value;
        }
    }
}

As you can see, I also include a simple method for deserializing the value.

Now that I have a way of wrapping the property values, all I need to do is to go through the properties and create new wrappers. Then I need to serialize the wrapper into JSON, encrypt it, turn into a Base64 encoded string, and set the property on the encrypted message.

foreach (var property in sourceMessage.Properties.ToArray())
{
    var wrapper = new BrokeredMessagePropertyWrapper
    {
        Type = property.Value.GetType().Name,
        Value = property.Value.ToString()
    };
    var bytes = encryptor.Encrypt(Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(wrapper)));
    targetMessage.Properties[property.Key] = Convert.ToBase64String(bytes, 0, bytes.Length);
}

In the above code, the sourceMessage points towards the original message, and the targetMessage points to the newly created, and encrypted message.

That is actually it… An encrypted message ready to be sent to the Service Bus…

The decryption is pretty much the same thing in reverse for obvious reasons…

Get the body as a string, which is really is. Get a byte array from the Base64 encoded string. Decrypt it. Convert it to a string. Deserialize the JSON and create a new BrokeredMessage with the deserialized object as the body. Like this

var encryptedObject = msg.GetBody<string>();

var json = Encoding.UTF8.GetString(decryptor.Decrypt(Convert.FromBase64String(encryptedObject)));
var body = JsonConvert.DeserializeObject<T>(json);

var decryptedMessage = new BrokeredMessage(body);

And the properties are the same thing. Pull the Base64 encoded string from the message’s properties, get the bytes, decrypt them, turn it into a string, deserialize to the wrapper type, and then set the decrypted message’s property using the GetValue() method of the wrapper.

foreach (var property in sourceMessage.Properties.ToArray())
{
    var decryptedBytes = decryptor.Decrypt(Convert.FromBase64String(property.Value.ToString()));
    var serializedWrapper = Encoding.UTF8.GetString(decryptedBytes);
    var wrapper = JsonConvert.DeserializeObject<BrokeredMessagePropertyWrapper>(serializedWrapper);
    targetMessage.Properties[property.Key] = wrapper.GetValue();
}

And voila! A very simple way to encrypt and decrypt BrokeredMessages. Using the extension methods when sending a message looks something like this

var client = GetQueueClient();
 
var obj = new MessageObject { Id = 1, Name = "Chris" };
var msg = new BrokeredMessage(obj);
msg.Properties.Add("MyProp", "MyValue");
msg.Properties.Add("MyProp2", 1);
 
msg = msg.Encrypt<MessageObject>(GetEncryption());
client.Send(msg);

And the receiving end like this

var client = GetQueueClient();
var message = client.Receive(TimeSpan.FromSeconds(5));
message = message.Decrypt<MessageObject>(GetEncryption());
var body = message.GetBody<MessageObject>();

That’s it! About a simple as can be. But I do say “about” as simple as can be. I still do not like the generic syntax being used. And I don’t like a new message being created. I want to change the existing message… And that can be done using reflection…

I know that there are a lot of people out there that doesn’t like reflection, and I am not convinced it is a great way to solve things. But I still want to show the difference, and how cool it can be…

Using reflection, I can go back and use the original extension method signatures

public static void Encrypt(this BrokeredMessage msg, IEncryptor encryptor)
public static void Decrypt(this BrokeredMessage msg, IDecryptor decryptor)

They will mofidy the object instead of actually creating a new one.

They way it works is by pulling out the private property called BodyStream on the BrokeredMessage instance. This contains a Stream that contains the serialized version of the body object.

The reflection part looks like this

var member = typeof(BrokeredMessage).GetProperty("BodyStream", BindingFlags.NonPublic | BindingFlags.Instance);
var data = (Stream)member.GetValue(msg);

where msg is the BrokeredMessage…

Encypting the data in the stream requires me to read the content of the stream as a byte array, send it to the IEncryptor instance, and then create a new Stream with the encrypted data. This newly created stream is then used to set the BodyStream property.

var bytes = new byte[data.Length];
data.Read(bytes, 0, (int)data.Length);
var handledBytes = encryptor.Encrypt(bytes);
var encryptedStream = new MemoryStream(handledBytes);
 
member.SetValue(msg, encryptedStream);

Once that is done, the encryption of the properties is exactly the same. It is only the body that is the issue…

Decrypting the body is once again pretty much the same… Get the Stream from the BodyStream. Decrypt the bytes. Turn them into a Stream, and set the BodyStream.

var member = typeof(BrokeredMessage).GetProperty("BodyStream", BindingFlags.NonPublic | BindingFlags.Instance);
var data = (Stream)member.GetValue(msg);
 
var bytes = new byte[data .Length];
data .Read(bytes, 0, (int)data .Length);
var handledBytes = decryptor.Decrypt(bytes);
var decryptedStream = new MemoryStream(handledBytes);
member.SetValue(msg, decryptedStream);

Ok, so the reflection part is not that great. It requires the BrokeredMessage’s implementation to not change, or at least not change by removing the BodyStream property. And some people say it might be slow, but hey, I am not running this a million times in a row… However, it does remove the Json.Net dependency, and relieves us of having to serialize and deserailize the object… So there is both good and bad parts involved in going down this route instead of the first one.

And jst for the sake of completeness, I want to show an implementation of the IEncryptor and IDecryptor. In this case using TripleDES (the download contains both TripleDes and Aes, as well as a base class that will make it VERY easy to implement new ones as long as you use a symmetric algorithm).

Actually, the code below is a previous implementation before the base class was introduced, but it will show the idea…

I have implemented both of the interfaces using the same class, called TripleDesEncryption. It takes 2 parameters in the constructor, the key and the initialization vector (2 strings).

It starts out by making sure that the key and IV is the correct length. The TripleDESCryptoServiceProvider requires the key to be 16 bytes (128 bits), and the IV to be 8 bytes (64 bits). It actually might support more key lengths, but the important thing is that they are fixed. So the constructor makes sure that they are the correct length before storing them.

public class TripleDesEncryption : EncryptionBase
{
    private readonly string _key;
    private readonly string _iv;

    public TripleDesEncryption(string key, string iv) : base(16, key, 8, iv)
    {
        if (key.Length > 16)
            key = key.Substring(0, 16);
        else if (key.Length < 16)
            key = key.PadRight(16, '*');
        _key = key;

        if (iv.Length > 8)
            iv = iv.Substring(0, 8);
        else if (iv.Length < 8)
            iv = iv.PadRight(8, '*');
        _iv = iv;
    }
 
    ...
}

As you can see, it either cuts the string if it is too long, or pads it if it is too short… Not the fanciest way of doing things, but it will work…

The Encrypt() method is implemented like this

public byte[] Encrypt(byte[] data)
{
    byte[] encryptedBytes;
    using (var algorithm = GetProvider())
    {
        algorithm.Key = Encoding.UTF8.GetBytes(_key);
        algorithm.IV = Encoding.UTF8.GetBytes(_iv);
        using (var encryptor = algorithm.CreateEncryptor())
        using (var ms = new MemoryStream())
        using (var cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write))
        {
            cs.Write(data, 0, data.Length);
            cs.FlushFinalBlock();
            encryptedBytes = ms.ToArray();
        }
    }
    return encryptedBytes;
}

and the Decrypt() method like this

public byte[] Decrypt(byte[] data)
{
    byte[] decryptedBytes;
    using (var algorithm = GetProvider())
    {
        algorithm.Key = Encoding.UTF8.GetBytes(_key);
        algorithm.IV = Encoding.UTF8.GetBytes(_iv);
        using (var decryptor = algorithm.CreateDecryptor())
        using (var ms = new MemoryStream())
        using (var cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Write))
        {
            cs.Write(data, 0, data.Length);
            cs.FlushFinalBlock();
            decryptedBytes = ms.ToArray();
            algorithm.Clear();
        }
    }
    return decryptedBytes;
}

and for the curious person, the GetProvider method is actually just a one-liner

protected override SymmetricAlgorithm GetProvider()
{
    return new TripleDESCryptoServiceProvider();
}

That’s all there is to it! That will encrypt and decrypt the BrokeredMessages using TripleDES…making sending messages through the Service Bus even safer.

There is obviously downlaodable code for this. It is a little hefty at 2,7 Mb…sorry about that… NuGetting (new word?) Json.Net adds a bit to the download…

It will require you to have the Azure SDK installed to work, as well as a Service Bus service set up in Windows Azure. Other than that, you have to configure it by setting the appSetting values in the App.config file. They should be pretty self-explanatory though…

Code available here: DarksideCookie.Azure.Sb.Encryption.zip (2.72 mb)

I hope that this helps out! If there are any problems or comments, just add a comment, or even better, drop me an e-mail at chris(a)59north.com. I have a tendency to miss comments on the blog, even if I do try to monitor them.

SDC 2013 Service Bus Talk Demo Code

chris@59north.com — Wed, 06 Mar 2013 15:21:19 +0200

Yesterday I did a talk about the Widnows Azure Service Bus at the Scandinavian Developer Coneference in Gotheburg. As a part of that, I promised to make all the code I demoed available here on my blog, so here it is. The only thing you need to do to be able to run it is to set up a new Service Bus service in the Azure portal, and the copy the namespace and key into the App.config file available in the “Shared” folder.

The App.config in the “Shared” folder is shared throughout all the projects in the solution, so you only need to change it in that single file. The code will however default to use the “owner” account, which I made pretty clear during the talk that you shouldn’t use. But for a demo like this, it will have to do.

Code: GetOnTheBus - Demo Code.zip (314.08 kb)

Tech-knowledge in approximately 100 pages

chris@59north.com — Thu, 07 Feb 2013 19:58:47 +0200

A while back a company called Syncfusion contacted me and asked me if I would be interested in trying out one of their Metro Studio, which is a brilliant tool for anyone doing “Modern UI” development (WP7/8 or Windows 8 Store applications). It is basically a massive icon library that fit straight into the Modern UI look and feel, and offers some cool abilities to resize them and so on. And to be completely honest, if I did a bit more WP dev than I am at the moment, I would not want to spend a day with out it. As soon as I do any WP8 development, I keep starting it up to quickly get some icons for my app.

However, that is NOT the reason I am doing this blog post… While browsing around their website looking for a simple way to download Metro Studio after a re-install of my machine, I stumbled upon a “Resources” section of their web, which is great. It includes a bunch of free whitepapers about different things, as well as a bunch of free e-books.

The cool thing about their e-books series called “Succinctly” is that they are really small. They cover a topic in approximately 100 pages, which is perfect. I love picking up new things, but I rarely have time to read a 500 page book. So getting an introduction in 100 pages is awesome.

The topics are very varied, so most develppers will probably find something to read in there. So far I have downloaded the JavaScript one and the Git one and put them on my Kindle.

I must admit I wasn’t TOO impressed by the JavaScript one, but that is probably because I had quite a good grasp on the subject before I started to read it. And on top of that, I have tought software development full time for 2 years, so I have a pretty good grasp on the ins and outs of coding. However, I still enjoyed reading it, and even if I didn’t pick up too many new things, it didn’t matter too much. It was only around 100 pages, so it only took a couple of evenings to read through (I’m a slow reader that reads very little normally). So even if I hadn’t picked up a single thing, it wouldn’t have been too much of a waste.

The Git one on the other hand, I have high hopes for. I have a fairly good grasp of that subject as well, but I’m pretty sure I will pick up a tip or two from that. And as soon as that is done, Knockout.js and F# is heading to my Kindle…

The series is constantly growing, allthough to me it can’t grow fast enough. I whish more companies would release short e-books like this. Like little nuggets of information that can teach you a thing or two, or at least open your eyes to something new, without me having to commit to it too much.

I don’t quite know the difference between their e-books and whitepapers, but it might have to do with the length of them, but the important part is that there are some good things to pick up there as well. Their “Just Enough TypeScript in 30 Minutes or Less” gave me a really good introduction to TypeScript. Just enough to get me going and pique my interest, and more importantly enough to be able to make a slightly more informed choice about whether or not to use it if I ever got into a project that needed a lot of JavaScript.

Well, that was another short post that turned way too long. But I hope that it got you curious enough to go and check out if there is something for you in that library…

Cheers!

Fileuploads through Windows Azure Mobile Services - take 2

chris@59north.com — Tue, 08 Jan 2013 14:47:08 +0200

So a couple of weeks ago I posted this blog post on how to upload files to blob storage through Mobile Services. In it, I described how one could do a Base64 encoded string upload of the file, and then let the mobile service endpoint convert it and send it to blob storage.

The upsides to this is that the client doesn’t have to know anything about where the files are actually stored, and it doesn’t need to have blob storage specific code. Instead, it can go on happily knowing nothing about Azure except Mobile Services. It also means that you don’t have to distribute the access keys to your storage together with the application.

I did however mention that there was another way, using shared access signatures (SAS). Unfortunately, these have to be generated by some form of service that has knowledge of the storage keys. Something like a Azure compute instance. However, paying for a compute instance just to generate SASes (plural of SAS…?) seems unnecessary, which is why I opted to go with the other solution.

However, Ryan CrawCour, a dear friend of mine, just had to say that he wasn’t convinced, which has now been nagging me for a while. So to solve that, I have deviced another way to use SAS while using only Mobile Services. And even though he is likely to have some opinion about this as well, it at least made the nagging feeling go away for a while.

DISCLAIMER: This is somewhat of a hack. I assume that there will be better ways to do this in the future, but for now it works even if it might not be my finest solution to date. My biggest issue with it is a part of the JavaScript that I will point out later, but it works. But don’t blame me when it causes Azure to explode and tear down the internet when you use it…

Ok, let’s go! Like everything else in the current version of Mobile Services, we need a table to create an endpoint to play with. In this case, I have created a table called “sas”. The table itself will not be used, it is only there to enable me to execute my serverside scripts… Because of this, I have restricted access to everything but “read”, as that is the only thing that will be used…

The next part is to create an entity to be used to send and receive data from the service. I called it SAS and it looks like this

[DataTable(Name = "sas")]
public class SAS
{
    public int Id { get; set; }
    [DataMember(Name = "container")]
    public string Container { get; set; }
    [DataMember(Name = "filename")]
    public string FileName { get; set; }
    [DataMember(Name = "url")]
    public string Url { get; set; }
}

As you can see, it includes a Name and a FileName property as well as the mandatory Id property. These properties will be used to pass the requred information to the endpoint. The Url property will be used for returning the signed Url.

(You could get away with removing the SAS entity and writing an OData query instead, but I prefer LINQ…)

Using it looks like this

var sas = (await App.MobileService.GetTable<SAS>().Where(x => x.FileName == "myfile.txt" && x.Container == "mycontainer").ToEnumerableAsync()).Single();
var url = sas.Url;

The real functionality is obvously in the other end, at the server. Here, I have created a “read script” for the table. This script will take the query and use the information in it to create a signed url.

The read() method looks like this

function read(query, user, request) {

    var filename = query._parsed.filter.left.right.value;
    var containername = query._parsed.filter.right.right.value;
        
    var url = getSignedBlobUrl(60, "teched", containername, filename);
    console.log('Created new SAS: ' + url);
    
    request.respond(statusCodes.OK, [{ url: url }]);

}

As you can see, it populates the filename and containername variables using the query’s _parsed member. I know that JavaScript members starting with an underscore are supposed to be private, and using the _parsed member is really not a good practice, but it was the only way I could find to easily get hold of the data sent to the server. There might be better ways to solve this, and I will look into it, but for now, this works…

Next it uses a method called getSignedBlobUrl(), which I will talk about in just a minute. Once the signed url has been generated, it is returned to the client using request.respond() instead of actually executing the query.

Ok, so what does the getSignedBlobUrl() do? Well, it just creates a well-formed signed url to the specified blob. Like this

function getSignedBlobUrl(expiryTimeout, accountName, containerName, blobName)
{
    var start = new Date();
    var end = new Date(start.getTime() + (1000 * 60 * expiryTimeout));

    var signature = generateSignature(start, end, accountName, containerName, blobName);
    var queryString = "?st=" + encodeURIComponent(start.toIsoString()) + "&se=" + 
                        encodeURIComponent(end.toIsoString()) + "&sr=b&sp=w&sig=" + 
                        encodeURIComponent(signature);
    return "http://" + accountName + ".blob.core.windows.net/" + containerName + "/" + blobName + queryString;
}

First it creates a timespan, within which the signature is valid, by using 2 Date objects. Azure limits this to 60 minutes or something, but that should be more than enough.

As you can see, it uses a method called generateSignature() to generate the actual signature. This method generates a HMAC-SHA256 signature generated using the blob storage key and a predefined string presentation of the parameters used in the querystring that is passed to the blob storage.

The actual Uri is then created by combining the path to the blob and a very funky querystring. The querystring includes a bunch of parameters such as start och end time for the access, what type of access (blob or container) it should have, what access rights it needs (read or write), and finally it includes the newly generated signature.

The signature generation looks like this

var crypto = require('crypto')
var key = new Buffer('XXXXX', 'base64')

function generateSignature(startTime, endTime, account, container, blobName) {
    var stringToSign = "w\n" + 
                        startTime.toIsoString() + "\n" + 
                        endTime.toIsoString() + "\n/" + 
                        account + "/" + container + "/" + blobName + "\n"
   var hash =  crypto.createHmac('sha256', key).update(stringToSign).digest('base64')
   return hash; 
}

It isn’t very complicated. It concatenates a string using a predefined format and then uses the crypto package to create the signature.

The “w” at the start of the stringToSign string defines the access, in this case write access, then it is the start time and end time of the SAS in the correct format, and finally it is the path to the blob to access.

Ok, that’s about it! The only thing that the very focused people will have noticed is that JavaScript does not include a toIsoString() method on the Date object. That is a separate method I have declared on the Date object’s prototype as follows

Date.prototype.toIsoString = function() {  
   var d = this;  
   function p(i) { return ("0"  + i).slice(-2); }  
   return "yyyy-MM-ddTHH:mm:ssZ"  
      .replace("yyyy", d.getFullYear())  
      .replace("MM", p(d.getUTCMonth() + 1))  
      .replace("dd", p(d.getUTCDate()))  
      .replace("HH", p(d.getUTCHours()))  
      .replace("mm", p(d.getUTCMinutes()))  
      .replace("ss", p(d.getUTCSeconds()));  
};

It is just a helper to get the date string in a format that works for the call…

Ok, that’s it! For real this time!

Except for the somewhat annoying use of the _parsed member in the JavaScript and the slightly odd way to execute the query on the client, it is actually quite a neat solution. Being able to generate SAS urls without a compute instance is actually quite useful in some cases. And even though I prefer uploading files the other way, this could still be really useful. And cheaper… Incoming data is free in Azure, so uploading the file is free either way, but if your storage is not in the same datacenter as the Mobile Service instance, then doing it the other way would incur charges when passing the file from the Mobile Service to the blob storage. Something that this solution does not.

Well, I guess it is better that I end this post before I get into talking about all the pros and cons of the 2 different solutions. They both do the job, so it is up to you to decide…

And no…there is no code for download this time. I have already shown it all, and it wasn’t that much…

A way to upload files to Windows Azure Mobile Services

chris@59north.com — Thu, 13 Dec 2012 11:49:55 +0200

Ok, so it is time for another Mobile Services post I believe. My previous posts about the subject has covered the basics as well as authentication when it comes to Mobile Service. But so far, I have only been doing the most simple tasks, such as added and read data from a SQL Database. However, I have mentioned that Mobile Services is supposed to be sort of a layer on top of more of Microsoft’s cloud offering like for example the Service Bus, storage etc. So in this post, I want to demo how you can utilize Mobile Services to upload files to blob storage.

There are probably a lot of different ways to do this, but 2 stood out for me. The one I am about to describe, using public containers, as well as using shared access signatures (SAS). So before going about it “my way”, I am going to explain SAS, and why I don’t like it even though it might be a “cleaner” way to do it.

Blob storage access is limited by default, something that I like, which is why I won’t even bother talking about public containers. But if uploading files to a public location works for you, then that is easier than what I am about to talk about…

So…private containers… To be able to access private containers, you need to sign your requests to Azure. This signature requires a key, which should be kept private for obvious reasons. So including it in a client application like the ones using Mobile Services would be a massive security issue. The solution to this is that you can create a special key (SAS) that will make it possible to access blob storage for a limited time. The SAS is generated serverside and can then be handed to the client to give him/her access to upload files. More information can be found online at places like this.

Ok, so why don’t I like this? Well, I just find that it means that I have to task the client application with doing the actual upload. This means that if I ever change storage, or even the storage structure, I will have to update the client. Besides, in Win8 and WP8, the client is supposed to do one thing great, and not 100 things “so so”. So tasking my recipe app with communicating with blob storage just because I want a picture of the user for personalization seems a bit off. (No I am not building a recipe app, it was just an example…)

And besides, I would still need some form of serverside code to get me the SAS. It would have been a completely different thing if including blob access code in the client meant not needing serverside code, and thus saving money, but I still need it. SO even if it is a “nicer” solution, it gives me no real added benefit more than adding stuff to the client that I don’t believe should be there.

Anyhow, time to move forward with the solution instead of talking about why I don’t like the other solution.

So… I already have a Mobile Service up and running since before, so I will just skip that. I also have a Windows 8 App Store client since before, so I will keep using that. All I need to do is to add the code needed to select an image and then post it to my Mobile Service.

I decided to do this quick and dirty in code behind of my application, but that’s just to keep it simple… So I added the following XAML

<StackPanel>
    <TextBlock x:Name="txtFileName" />
    <Button Content="Select File" Click="SelectFile" />
    <Button Content="Send File" Click="SendFile" />
</StackPanel>

And the following C#

private async void SelectFile(object sender, RoutedEventArgs e)
{
    var dlg = new FileOpenPicker();
    dlg.ViewMode = PickerViewMode.Thumbnail;
    dlg.FileTypeFilter.Add(".jpg");
    var file = await dlg.PickSingleFileAsync();

    if (file == null)
        return;

    _file = file;
    txtFileName.Text = _file.DisplayName;
}

private async void SendFile(object sender, RoutedEventArgs e)
{
    var msg = new ImageUpload { fileName = "Microsoft.jpg" };
    await msg.SetImageData(_file);
    await App.MobileService.GetTable<ImageUpload>().InsertAsync(msg);
    new MessageDialog("Done").ShowAsync();
}

As you can see, there are 2 event handlers. The first one does the file selection using a FileOpenPicker, which is basic stuff. The second one creates a new ImageUpload object, which I will cover in a little bit, and then uses the Mobile Services proxy to send it to the cloud. The real stuff is going on in the ImageUpload class though…

[DataTable(Name = "images")]
public class ImageUpload
{
    public async Task SetImageData(StorageFile file)
    {
        var content = await FileIO.ReadBufferAsync(file);
        var bytes = content.ToArray();
        image = Convert.ToBase64String(bytes);
    }

    public int id { get; set; }
    public string fileName { get; set; }
    public string image { get; set; }
}

Ok, so the “real stuff” is still pretty simple. All the ImageUpload class does, besides hold the values that are to be sent to the cloud, is to take the contents of the file and convert it to a Base64 encoded string. That way, I can push my file to the cloud as just a string, which Mobile Services already supports.

So now that the ImageUpload class has been created and pushed to the cloud, what happens there? Well, there are a couple of things that have to happen. First of all, the image I am uploaded has to be converted from a Base64 encoded string to my actual image, and then that image has to be sent to blob storage. But let’s just take it one step at the time.

The first thing is to create a new table in my Mobile Service called “images”. Next I need to create an insert script, which is where all the stuff will be hapening.

The first part of the script looks like this

function insert(item, user, request) {
    var azure = require('azure');
    var blobService = azure.createBlobService('DefaultEndpointsProtocol=https;AccountName=XXXXX;AccountKey=YYYYY');
    
    createContainerIfNotExists(blobService, function(error) {
        if (error) {
            request.respond(500);
            return;
        }
        uploadFile(blobService, item.image, item.fileName, function(error) {
            if (error) {
                request.respond(500);
                return;
            }
            delete item.image;
            request.execute();
        });
    });
}

Ok, so what is happening in there? Well, the first thing that happens is that the script gets a reference to the Node.js module called “azure”. This is used for accessing Azure resources…duh… Next that module is used to create a proxy client for my blob storage.

This proxy is then used to create the container if it doesn’t exist. If that method fails, the script returns an HTTP 500. If not, it uploads the file using another helper method. And once again, if that fails, it return an HTTP 500. Otherwise, it removes the Image property so that it isn’t stored in the table, and then executes the request, inserting the rest of the entity properties into the table.

That part isn’t very complicated…so let’s look at the helper methods. First up is the createContainerIfNotExists.

It takes a blob storage proxy as a parameter and uses it to ensure that the target container exists using a publicAccessLevel of “blob”.

function createContainerIfNotExists(blobService, callback) {
    console.log('creating container if needed')
    blobService.createContainerIfNotExists('democontainer', {publicAccessLevel : 'blob'}, function(error) {
        if(error){
            console.log(error);
            callback(error);
            return;
        }
        console.log('container created')
        callback();
    });
}

As you can see, I am doing quite a bit of logging as well. This helps when something goes wrong…

The next helper is the uploadFile method. It looks like this

function uploadFile(blobService, file, filename, callback) {
    console.log('uploading file');
    var fileBuffer = new Buffer(file, 'base64');
    blobService.createBlockBlobFromStream('democontainer'
            , filename
            , new ReadableStreamBuffer(fileBuffer)
            , fileBuffer.length
            , { contentTypeHeader:'image/jpg' }
            , function(error){
                if(error){
                    console.log(error);
                    callback(error);
                    return;
                }
                console.log('file uploaded')
                callback();
            });
}

It basically just forwards the file information to the blob storage proxy’s createBlockBlobFromStream method. However, there are a few interesting bits in here. First of all, it takes the “file”, which is really the Base64 encoded string, and puts it inside a Buffer, which is told that the content is Base64 encoded. So now I have my file content as a Buffer instead of a string, which is a good start. However, the method I am calling is called createBlockBlobFromStream. This means that it requires a Stream object, not a Buffer. Unfortunately, this is not .NET, so there isn’t just some neat implicit cast or extension method that solves this. And I couldn’t even find an implementation of Stream, which is an abstract base class, that wraps a Buffer. So after collecting some tips and code snippets from around the web, I built my own. It isn’t actually that complicated, but it becomes a lot of rows of code…

var ReadableStreamBuffer = function(fileBuffer) {
    var that = this;
    stream.Stream.call(this);
    this.readable = true;
    this.writable = false;
 
    var frequency = 50;
    var chunkSize = 1024;
    var size = fileBuffer.length;
    var position = 0;
 
    var buffer = new Buffer(fileBuffer.length);
    fileBuffer.copy(buffer);
 
    var sendData = function() {
        if(size === 0) {
            that.emit("end");
            return;
        }

        var amount = Math.min(chunkSize, size);
        var chunk = null;
        chunk = new Buffer(amount);
        buffer.copy(chunk, 0, position, position + amount);
            position += amount;
        size -= amount;
        
        that.emit("data", chunk);
    };
 
    this.size = function() {
        return size; 
    };
 
    this.maxSize = function() {
        return buffer.length;
    };
 
    this.pause = function() {
        if(sendData) {
            clearInterval(sendData.interval);
            delete sendData.interval;
        }
    };
 
    this.resume = function() {
        if(sendData && !sendData.interval) {
            sendData.interval = setInterval(sendData, frequency);
        }
    };
 
    this.destroy = function() {
        that.emit("end");
        clearTimeout(sendData.interval);
        sendData = null;
        that.readable = false;
        that.emit("close");
    };
 
    this.setEncoding = function(_encoding) {
    };
 
    this.resume();
};
util.inherits(ReadableStreamBuffer, stream.Stream);

Ok, if you are interested, I suggest you look through that piece of code. If not, I will give you a quick rundown of what it does.

It basically takes a Buffer, which is pretty much like an byte[]. It wraps that, and keeps track of the current position inside it. It then uses a timer to push a chunk of bytes to baseclass ever so often as long as there is data to push.

That’s actually all there is to it!

Authenticating users in Windows Azure Mobile Services

chris@59north.com — Tue, 04 Dec 2012 07:34:45 +0200

In my previous post about Mobile Services, I talked about how to get started with the service. I also promised that I would follow up with a post about how to authenticate the users, so that is what this post is going to be about.

You currently have 4 different options when it comes to authentication, Microsoft ID (previously Live ID), Facebook, Twitter and Google. They are all 3rd party services, and requires your users to have accounts with one of the providers. Luckily, most users already do. And the neat thing about using 3rd party authentication is that you don’t have to care about handling sensitive data such as usernames and passwords. And leaving that to someone else is making your life a lot less complicated. Not to mention that having Mobile Services handle all of the actual interaction with them makes your life ridiculously simple, as you will see.

I must admit that I would have loved to see the Mobile Services authentication run through ACS instead. That way, it would have been easy for us to set up authentication through ADFS and other identity providers, but I guess we can’t have it all…at least not at once…

Ok, so how do you set up your Mobile Service to support authentication? Well, it is actually a piece of cake… First you have to decide what identity provider to use, or if you want to support several of them. In this post, I will focus on using Facebook.

Once you have decided what identity provider to use, you have to configure the identity provider for you application. As mentioned, I will use Facebook, so I browse to http://developer.facebook.com/ and click the “Apps” menu item. If you have never used the developer part of Facebook, it is not that complicated to get started. Next, I click “Create New App” at the top right corner, which pops-up the following “window”

All you need to do here is to add a unique “App Name” and press continue. And after you have figured out the captcha that you are faced with, you get the following view

The last thing you need to do in here is to click the “Website with Facebook Login” link and fill in the url to the Mobile Services endpoint you are going to use. In my case, that will be https://darksidecookie.azure-mobile.net/, so I will it out like this

Ok…that’s pretty much all you need to do to configure Facebook. Just press “Save Changes” and you are done. The next step is to set up the Mobile Services integration, which is actually just as easy. Just go to the top of the Facebook app page, and locate the “App ID” and “App Secret”, these need to added to the Mobile Services settings in the Azure Portal. So, just browse to the settings page for the Mobile Service you want to work with, and click the “IDENTITY” link.

If you then look just below the settings for microsoft accounts, you will find “facebook settings”, and 2 textboxes with very familiar labels. Just copy your App ID and App Secret from the Facebook developer portal into these, press “SAVE” and confirm that you want to update the settings.

That’s it! Authentication configured…now all there is left to do, is to get the actual application to use it, which once again is a walk in the park.

In my case, I have added a Login button to my application, and hooked up a handler for the click event.

<Button Content="Login" Click="LoginLogoutClick" />

In the click handler, I verify whether or not the current user is logged in or not by checking if the CurrentUser property is null. If it is, it is time to log in, if not, it is time to logout.

private async void LoginLogoutClick(object sender, RoutedEventArgs e)
{
    if (App.MobileService.CurrentUser == null)
    {
        await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.Facebook);
        if (App.MobileService.CurrentUser != null)
        {
            ((Button) sender).Content = "Logout";
            new MessageDialog("You are now logged in [" + App.MobileService.CurrentUser.UserId + "]").ShowAsync();
        }
    }
    else
    {
        App.MobileService.Logout();
        ((Button)sender).Content = "Login";
        new MessageDialog("You are now logged out").ShowAsync();
    }
}

As you can see, the Mobile Services proxy handles all of it for us. All that is needed is to call LoginAsync(), passing in the identity provider to use, and it does the rest. Remember that logging in is async though, so it need to be “awaited”. Logging out however is synchronous, so we don’t need to “await” it. The result of calling LoginAsync() in an App Store application looks like this

And after entering my credentials, I am requested to authorize the Facebook application to get basic information from Facebook.

And I am then finally greeted by a MessageDialog like this

As you can see, the user id is just a string, which consists of the identity provider, a colon and a unique id given to the service by the identity provider. In the case of Facebook, it is the user id of my Facebook account, but you should not assume that it will always be that…

Ok, so what now? What can we do now? Well, you now have a user identity to use when you save data in your service, which is really useful. And the cool thing is that this is a one-time thing. The user doesn’t need to sign in everytime the application starts, the Mobile Services proxy handles all of that for us…

So say that I wanted to store a name and e-mail address for my user. This is really simple. All you need to do is give the user a UI to insert the information, and then use a little bit of code like this

private void SaveUserDetailsClick(object sender, RoutedEventArgs e)
{
    var msg = new JsonObject {{"name", GetName()}, {"email", GetEmail()}};
    App.MobileService.GetTable("userdetails").InsertAsync(msg);
}

As you can see, I do not pass the user id with my entity. I do not trust passing it as part of the message, as the user could easily modify the data being sent to the server and set other users information. Instead, the best practice in this case is to use an insert script and set the user id on the server instead.

To do this, I go to the scripts section for my table, and modify the insert script as follows

function insert(item, user, request) {
    item.userId = user.userId;
    request.execute();
}

Thus making sure that the user id is added to the table…but also making sure that it is the correct user id.

Now, to secure the table, I also make sure that only authenticated users can perform operations on the table by setting the permissions as follows

That’s it! A few settings, some copy pasting and a line of two of code, and you have authentication and authorization built in to your application back end. Very simple if you ask me…