157 posts categorized "Distributed Applications"

11/07/2014

Running Thinktecture Identity Server v3 with ASP.NET vNext on Ubuntu

Thinktecture was at the MVP Summit 2014 ASP.NET Hackathon: after Dominick and Brock had Identity Server running on ASP.NET vNext, I took a stab at getting that code working on Linux/Ubuntu.

For this I needed to clone and build Mono as there are a couple of necessary patches which are not yet in any released Mono build (see this blog post for details).

This is a very easy thing to do on Ubuntu:

git clone git://github.com/mono/mono.git
cd mono
./autogen.sh --prefix=/usr/local
make
sudo make install


After this executed successfully – bring … some… time! – we have the latest Mono version:

image

Next thing to do is bringing Kestrel as the HTTP server into the picture:

{
    "webroot": "wwwroot",
    "version": "1.0.0-*",
    "exclude": [
        "wwwroot"
    ],
    "packExclude": [
        "**.kproj",
        "**.user",
        "**.vspscc"
    ],
    "dependencies": {
       "Kestrel": "1.0.0-*",
        "Microsoft.AspNet.Server.IIS": "1.0.0-beta1",
        "Microsoft.AspNet.Owin": "1.0.0-beta1",
        "Microsoft.AspNet.Diagnostics": "1.0.0-beta1",
        "Microsoft.AspNet.WebApi.Owin": "5.2.2",
        "Microsoft.Owin": "3.0.0",
        "Thinktecture.IdentityServer.v3": "1.0.0-beta3-1",
        "Thinktecture.IdentityModel.Core": "1.2.0",
        "Microsoft.Owin.Security": "3.0.0",
        "Microsoft.Owin.Security.Google": "3.0.0",
        "Microsoft.Owin.Security.OpenIdConnect": "3.0.0"
    },
    "commands": {
        "Kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5005",
    },
    "frameworks" : {
        "aspnet50" : { }
    }
}


As Identity Server comes with its own Test X509 certificate it is necessary to import this cert into the Mono certificate store – like this:

certmgr -add -c -p idsrv3test -m My idsrv3test.pfx

One thing that was left to get IdSrv finally running successfully was working around a bug in the ASP.NET vNext HTTP abstractions (GitHub issue – it has already been fixed Smile).


Once that was sorted out – tadaa!

image

Hope that helps.

10/05/2014

Installing & Running ASP.NET vNext (Alpha 3) on Ubuntu Linux with Mono 3.8–for real

Yesterday I thought I would try and prove Microsoft’s promise that the new and overall cool ASP.NET vNext would run on many platforms, including Windows, MacOS X, and Linux.

My target platform for this experiment was Linux. First thing to do in this case is check out of of the myriads of Linux distros. After a bit of investigating I chose the Ubuntu-based Xubuntu. Very slick!

After installing Xubunutu (it took only a few minutes, literally) in a Parallels VM on my MacBook Pro, I went ahead to get Mono running. Turns out the the most reliable way to get recent versions of Mono running on stable Linux distros these days is to suck down the source code and compile it.
So here we go with some simple steps (may take a couple of minutes to get through, though):

sudo apt-get install build-essential
wget http://download.mono-project.com/sources/mono/mono-3.8.0.tar.bz2
tar -xvf mono-3.8.0.tar.bz2
cd mono-3.8.0/
./configure --prefix=/usr/local
make
sudo make install


This gives us the Mono 3.8.0 CLI:

mono_cli


According to the ASP.NET vNext Home repo on GitHub this should be all we need to get started with the samples. NOT. When we build the source of the samples we get a network-related exception showing up.

The issue is the certificates used for the package sources. The .NET Framework on Windows uses the Windows Certificates store to check whether to accept an SSL certificate from a remote site. In Mono, there is no Windows Certificate store, it has its own store. By default, it is empty and we need to manage the entries ourselves.

CERTMGR=/usr/local/bin/certmgr
sudo $CERTMGR -ssl -m https://go.microsoft.com
sudo $CERTMGR -ssl -m https://nugetgallery.blob.core.windows.net
sudo $CERTMGR -ssl -m https://nuget.org
sudo $CERTMGR -ssl -m https://www.myget.org/F/aspnetvnext/

mozroots --import --sync

After these steps we should be able to build the samples from the ASP.NET vNext Home repo successfully, e.g. the HelloMvc sample.

Running kpm restore looks promising, at least:

kpm_restore

When we then try to run the sample with k kestrel (Kestrel is the current dev web server in vNext) we get a wonderfully familiar error:

Object reference not set to an instance of an object.

Hooray!!! Sad smile

After some Googling I found out that the underlying libuv (yes, that same libuv used in node.js) seems to be the problem here. A quick chat with the ASP.NET vNext team reveals it seems like this will be fixed in the future, but there are some more important things to get done by now.

Anyway, I got it finally to work by replacing libuv as suggested here:

ln -sf /usr/lib/libuv.so.11 native/darwin/universal/libuv.dylib

 

When I now run k kestrel again everything is fine:

k_kestrel_running

By default, Kestrel runs on port 5004 – thus opening our browser of choice with http://localhost:5004 gives us the desired result:

running

Mission accomplished.
Thanks for listening.

03/03/2014

BASTA! Spring 2014: Unterlagen

Die BASTA! Spring ist rum, und wieder einmal war es super. Danke an die Organisierer und natürlich an die Teilnehmer!

Hier sind die Folien zu meinen Vorträgen:


Zu den Ganztages-Workshops am Montag und Freitag gibt es naturgemäß keine Folien Winking smile

Für den Freitags-Workshop “End-to-End-Implementierung einer Cross-Platform Modern Business Application” gibt es hier das “laufende” GitHub-Repository, in das Ingo Rammer und ich während des Tages immer hinein ge-psuhed haben.

https://github.com/thinktecture/basta-endtoend

 

Viel Spaß!

05/24/2013

Hands-On Course: "ASP.NET Web API & SignalR: lightweight web-based architectures for you!"

Come and join me Oct 30-31, 2013 in Oslo for a two days hands-on course organized by ProgramUtvikling.

ASP.NET Web API & SignalR: lightweight web-based architectures for you!"

Time for change: whether it is a classic desktop application, a public or internal web site or a variety of mobile apps - customers and end-users long for multiple ways to access and work with data and processes. Web-based architectures, patterns and techniques can make the life of software architects and developers considerably easier in the face of these requirements.

Description:
Let's face it! The current trends and developments especially in the area of mobile platforms & devices and cloud computing will cause a re-thinking in architectural aspects for many software projects and products. If you ignore this today you may be in big trouble tomorrow. How can I reach a plethora of users and client devices? How can I integrate my systems and application parts in a lightweight and interoperable manner? How am I able to push data in near-real-time fashion from my services to my clients?
This course tries to answer these and more questions. Christian Weyer will show you in a pragmatic way how to face the new challenges. See all of this coming to life by using technologies and frameworks like ASP.NET Web API, SignalR, .NET- and HTML5/JavaScript-based clients - mobile or not.

 

More information at the ProgramUtvikling web site.
See you there!

 

04/30/2013

New ebook chapter published: Properly integrating SignalR hubs with your AngularJS applications

Ingo and I just published a new book chapter of our henriquat.re online (continuously deployed) ebook.
The topic this time is about properly integrating SignalR hubs with your AngularJS applications to realize near realtime push communication. For web browser, desktop or mobile apps.

"Pushing Data: Integrating With ASP.NET SignalR Hubs"

In modern applications the end users want to get their data. They want it now, they want it up-to date. In fact it does not matter whether these are pure web application, native desktop installations or mobile apps: everybody wants his data now!

For .NET-minded developers there are a numbers of options to implement near-real-time push style communication from the server/the services to the clients/consumers. You can choose plain HTTP or the super-new WebSockets features available in .NET 4.5 together with Windows 8 and Windows Server 2012. But the coolest and increasingly popular approach is to use a new framework: ASP.NET SignalR.

While it is not intended- and surely beyond the scope of this ebook - to give an introduction or even deep dive into SignalR, we need to have a look at some concepts and code in order to realize a smooth integration of SignalR and AngularJS.

The final goal of this chapter is to have an AngularJS-style integration of calling and listening to server-side SignalR push services.

 

Enjoy!

03/04/2013

Infos zu meinen Sessions & dem Workshop auf der BASTA! Spring 2013

Erst einmal nochmals vielen lieben Dank an alle, die in meine beiden Breakout Sessions und meinen Ganztages-Workshop in Darmstadt gekommen sind!

Da ich ja in meinen beiden Sessions keine "wirklichen" Foliensätze verwendet hatte sondern Demos und Code gezeigt habe, gibt es dieses Mal nix zum Downloaden ;) Beim Workshop war es ja genauso - interaktiv!

Hier aber die versprochenen Links zum Code & den Demos:

Danke und bis bald.

 

01/29/2013

Ain’t no IIS: Self-hosting thinktecture IdentityServer v2 – a simple proof-of-concept

There have been a couple of people asking for a sample how to host the ‚non-visual' parts of thinktecture IdentityServer v2 outside of IIS & ASP.NET. E.g. in a Windows or a Console (no, not really…) application.

Here on GitHub you will find a very simple simple PoC which hosts the OAuth2 token endpoint. That said, it is obviously by no means feature complete.
This endpoint uses ASP.NET Web API and thus self-hosting is kinda piece of cake.

namespace SelfHostConsoleHost
{
    internal class SelfHostServer
    {
        private HttpSelfHostServer selfHost;

        [Import]
        public IConfigurationRepository ConfigurationRepository { get; set; }

        public async void Start(string baseAddress)
        {
            var httpConfig = new HttpSelfHostConfiguration(baseAddress);

            Database.SetInitializer(new ConfigurationDatabaseInitializer());

            Container.Current = new CompositionContainer(new RepositoryExportProvider());
            Container.Current.SatisfyImportsOnce(this);

            ProtocolConfig.RegisterProtocols(httpConfig, ConfigurationRepository);

            selfHost = new HttpSelfHostServer(httpConfig);

            await selfHost.OpenAsync();
        }

        public async void Stop()
        {
            if (selfHost != null)
            {
                await selfHost.CloseAsync();
            }
        }
    }
}

As said, it just offers one endpoint:

namespace SelfHostConsoleHost
{
    public class ProtocolConfig
    {
        public static void RegisterProtocols(HttpConfiguration httpConfiguration, IConfigurationRepository configuration)
        {
            // necessary hack for now - until the DI implementation has been changed
            var a = Assembly.Load("Thinktecture.IdentityServer.Protocols");
 
            var clientAuthConfig = CreateClientAuthConfig();

            httpConfiguration.MessageHandlers.Add(new RequireHttpsHandler());

            if (configuration.OAuth2.Enabled)
            {        
                httpConfiguration.Routes.MapHttpRoute(
                    name: "oauth2token",
                    routeTemplate: Thinktecture.IdentityServer.Endpoints.Paths.OAuth2Token,
                    defaults: new { controller = "OAuth2Token" },
                    constraints: null,
                    handler: new AuthenticationHandler(clientAuthConfig, httpConfiguration)
                );
            }
        }
 
        public static AuthenticationConfiguration CreateClientAuthConfig()
        {
            var authConfig = new AuthenticationConfiguration
            {
                InheritHostClientIdentity = false,
                DefaultAuthenticationScheme = "Basic",
            };

            // accept arbitrary credentials on basic auth header,
            // validation will be done in the protocol endpoint
            authConfig.AddBasicAuthentication((id, secret) => true, retainPassword: true);
 
            return authConfig;
        }
    }
}

Again: the code is here: Self-Hosted IdentityServer v2 PoC

Hope this helps.

Running thinktecture IdentityServer v2 in a Windows Azure Web Role – from zero to hero (a walkthrough)

OK, I think a couple of you guys already did it successfully – others just look for something written. Here we go.

Let's start right away by browsing to GitHub and clone the IdentityServer.v2 repo:

After cloning we have the following code structure in Windows Explorer:

Open Thinktecture.identityServer.sln as an elevated admin (for the Windows Azure Compute Emulator to work correctly). Build the entire solution.

No, choose Add… New project… and add a new Cloud project to the solution.

In the Cloud Service dialog do not choose any new project, just hit OK.

We now add the existing IdSrv WebSite project as a Web Role to the Windows Azure project, just like so:…

For now, the solution should look something like this:

Alright. On to some essential Cloud stuff now.

We need an SSL certificate. I am going to use an existing self-issued cert from my local machine. This of course needs to be a 'real' certificate if you deploy IdSrv as a production STS to Windows Azure – of course

Please head over to WebSite role configuration and the Certificates tab. Specify your desired certificate:

Based on this certificate we now create an SSL endpoint:

OK, this should be it for now.

Let's attack the database side of things. We need a SQL database for our identity configuration and data. I am going to create a new one via the Windows Azure management portal:

Please make a note of the connection string for your SQL database as we still need to change the connection strings inside IdentityServer's configuration files.

Then open up connectionString.config in the Configuration folder inside the WebSite project and adjust the connection strings to point to your SQL database in the Cloud:

 

<connectionStrings>
    <add name="IdentityServerConfiguration"
    connectionString="Server=tcp:….database.windows.net,1433;
    Database=idsrvcloud;User ID=christian@…;Password=...;
    Trusted_Connection=False;Encrypt=True;Connection Timeout=30;"
    providerName="System.Data.SqlClient" />

    <add name="ProviderDB"
    connectionString="Server=tcp:….database.windows.net,1433;
    Database=idsrvcloud;User ID=christian@…;Password=...;
    Trusted_Connection=False;Encrypt=True;Connection Timeout=30;"
    providerName="System.Data.SqlClient" />
</connectionStrings>

… drum roll …

F5 (with the Cloud project as the startup project) and pray …

Enter the basic setup information you need to enter and you should be good to go. This locally running instance inside Windows Azure Compute Emulator already uses the Cloud SQL database – just for the records.

Done… well almost … I am spilling the beans already now so that we can save some cycles.

There is an issue with the Membership hash algorithm type on Cloud VMs.

  • Locally: HMACSHA256
  • Azure Cloud Emulator: HMACSHA256
  • Published to Cloud Service: SHA1

So it looks like there must some machine.config setting in Cloud Service images – Microsoft is investigating this.

For us it means we need to set the keys explicitly in web.config (you can use a tool like this):

<system.web>
    <machineKey
        decryptionKey="46CD6B691..."
        validationKey="EC4752081..."
        decryption="AES"
        validation="HMACSHA256" />
...

OK.

After that we need to export the SSL cert, anyways, so that we can upload it to the Cloud Service , e.g. via the management portal.

And then, we finally can publish & deploy to Windows Azure:

After approx. 8 to 10 minutes we have our thinktecture IdentityServer v2 running up in the Cloud.

Hope this helps.

11/05/2012

OAuth2 in thinktecture IdentityServer v2: Implicit Grant Flow with JavaScript

Our thinktecture IdentityServer version 2 will be a very different and very powerful identity beast!

Dominick already talked quite a bit about the features and how to use them. And Brock is surely at it as well.

Today I will show how to use IdentityServerv2 to implement the OAuth2.0 implicit grant flow as outlined in the official OAuth2 spec – and we are going to use a JavaScript client for that.

For the sake of a little bit of mobile-ness I am going to use KendoUI Mobile to have a native looking mobile UI (which you could then combine e.g. with Cordova/PhoneGap to create a native app).

We are going to look to secure a super novel and world overtaking… TODO app Smile

1


Admittedly, this is only the basic gist of what an app should look like and feature-wise we will focus on the OAuth part today.
First let’s head to IdentityServer an create a new OAuth Client like this:

idsrv1


One important part of the configuration is the callback/redirect URI. This is where the IdP sends us the token to.

In addition, we need a relying party/resource we can use to create tokens for and which will accept these tokens coming from our JavaScript clients.

idsrv2


Alright, time to jump on to the client side.
I try to encapsulate my JS code as much as possible. One nice pattern to get a basic structure is MVVM and KendoUI has good support for that.

The page above for the Start tab has a viewmodel which does just fire up the OAuth process (in this case the authentication):

   1:  var startViewModel = kendo.observable({
   2:      openLoginView: function () {
   3:          oauth2ViewModel.openAuthWindow(
   4:             endpoints.IdpOauthEndpointUrl);
   5:      }
   6:  });


The OAuth viewmodel holds the token and offer methods to kick off the login process and parse the token from the return URL.

   1:  var oauth2ViewModel = kendo.observable({
   2:      token: "",
   3:      
   4:      openAuthWindow: function () {
   5:          var url = endpoints.IdpOauthEndpointUrl + "?" 
   6:             + $.param(oAuthConfig);
   7:          window.open(url, "Login", "height=500,width=350");
   8:      },
   9:      
  10:      loginCallback: function (params) {
  11:          this.token = params["access_token"];
  12:          window.kendoMobileApplication.navigate("#todosPage");
  13:      }
  14:  });


In order to craft the correct URL for IdentityServer we need a couple of parameters which need to correspond to what we previously set up in IdSrv for the OAuth client and the RP (see the IdSrv screenshots above):

   1:  var endpoints = {
   2:      IdpOauthEndpointUrl: "https://localhost/idsrv/issue/
   3:         oauth2/authorize"
   4:  };
   5:   
   6:  var oAuthConfig = {
   7:      client_id: "tt_tudus",
   8:      scope: "http://tt.com/mobile/todos",
   9:      response_type: "token",
  10:      redirect_uri: "http://localhost/simpletudus/
  11:         oauthcallback.html"
  12:  }


Alright. Let’s look at the flow now.
Once we clicked on Login a new window pops up which loads the IdentityServer login page:

2


After loging into IdSrv we get the resource consent page and choose to allow access:

3


IdSrv will now send the token to callback URL specified earlier in the IdSrv config.

This URL looks something like this:

http://localhost/simpletudus/oauthcallback.html#access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI…
&token_type=urn:ietf:params:oauth:token-type:jwt&expires_in=35999


The code of the oauthcallback.html page is pretty simple. It parses the token from the hash (#) part of the URL and fires an event on the calling page to pass over the token (see the Google OAuth developers page for more details on the process):

   1:  <script src="js/libs/jquery-1.7.1.min.js" type="text/javascript"></script>
   2:  <script src="js/libs/jquery.ba-bbq.min.js" type="text/javascript"></script>
   3:   
   4:  <script type="text/javascript">
   5:      //var params = {}, queryString = location.hash.substring(1),
   6:      //    regex = /([^&=]+)=([^&]*)/g, m;
   7:   
   8:      //while (m = regex.exec(queryString)) {
   9:      //    params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
  10:      //}
  11:      
  12:      var params = $.deparam.fragment(
  13:         location.hash.substring(1));
  14:      
  15:      window.opener.oAuthCallback(params);
  16:      window.close();    
  17:  </script>


Note
: I am using jQuery BBQ in the above code to parse the URL, the commented code shows how to do it without any external library.

In the main page we have some kind of a proxy event handler which just passes the token on to the above shown OAuth viewmodel:

   1:  <script>
   2:      function oAuthCallback(params) {
   3:          oauth2ViewModel.loginCallback(params);
   4:      }
   5:  </script>


In the OAuth viewmodel login callback method we then simply set the token and trigger navigation to the TODO items page.

When hitting the refresh button in the upper left side of the Items view the actual call to the resource is made with standard jQuery. This happens in the loadTodos call:

   1:  var todosViewModel = kendo.observable({
   2:      todosSource: new kendo.data.DataSource(
   3:         { sort: { field: "title", dir: "asc" } }),
   4:      
   5:      loadTodos: function () {
   6:          var self = this;
   7:   
   8:          dataservices.getTodos(oauth2ViewModel.token)
   9:              .done(function (data) {
  10:                  self.todosSource.data(data);
  11:              });
  12:      }
  13:  });


The data services logic is embedded in its own ‘class’ and simply uses the token acquired before to set the appropriate Bearer Authorization header before making the jQuery GET request against the TODO items resource (which is implemented with ASP.NET Web API, BTW):…

   1:  var dataservices = (function () {
   2:      function beforeSend(xhr, token) {
   3:          xhr.setRequestHeader("Authorization", 
   4:             createBearerHeader(token));
   5:      }
   6:   
   7:      function createBearerHeader(token) {
   8:          var header = "Bearer " + token;
   9:          return header;
  10:      }
  11:   
  12:      return {
  13:          getTodos: function (token) {
  14:              return $.ajax({
  15:                  url: endpoints.ServiceEndpointUrl,
  16:                  type: "get",
  17:                  dataType: "json",
  18:                  beforeSend: function (xhr) { beforeSend(xhr, token); }
  19:              });
  20:          }
  21:      };
  22:  }());


And voila…:

4


So please head to GitHub and get the IdSrv bits and give us feedback – thanks!


The entire code for this complete end-to-end sample can be found on GitHub.

Hope this helps.

10/12/2012

You thought identity management is ‘done’? Think twice: thinktecture IdentityServer v2 Beta is here

The Beta version of our open source IdentityServer STS has been released today:

http://leastprivilege.com/2012/10/12/thinktecture-identityserver-v2-beta/

 

Check out the short intro video to get a quick start:

http://leastprivilege.com/2012/10/12/setup-thinktecture-identityserver-v2-in-7-minutes/

 

Any feedback is always welcome and highly appreciated! Dominick and Brock (and a little bit of myself will hang out there…)
https://github.com/thinktecture/Thinktecture.IdentityServer.v2/issues

 

Thanks.