I stumbled across a post by Brian Burke from Gartner called US Federal CIO Faces a Daunting Challenge, in which he points out that many government-wide enterprise architecture programs have failed because underestimated political, cultural, and financial challenges.

Though not stated in the post, one can then assume this is the challenge facing the US federal CIO, and the post then states the classical argument that they are given the responsibility to optimise ... without the authority to get it done.

Most anyone who's had to implement change in a big organisation, have at some point wished they had the authority to just command what needed getting done, and sure, given a stick big enough, change can be forced upon an organisation - but the end result is not very good and it causes as lot of dissatisfaction. If empowerment was the universal solution to the challenges facing the US CIO, then it would be an easy fix.

True, if you harmonise enterprise architecture in a loosely bound group of organisations or even just within a single organisation, this impact will affect some more than others, but that does not imply that there must be winners and losers. Taking a note from economics, a Pareto efficient solution can be sought so that no one party will worse of after the change.

This can also be viewed as addressing the political challenges of a project: Say to someone that you're going to change their life, and that they're going to be worse off afterwards, and they won't like it. On the other hand, if they're going to be better of afterwards, they are much more likely to agree.

In a Pareto efficient solution, the end result only needs to be on par, but because people are predictably irrational, it often needs to be better. Specifically, people tend to value higher what they have, which is also referred to as the The High Price of Ownership or endowment effect, and so to make people agree to an alternate solution, they have to value that solution as high as the inflated value of the solution they currently have.

So, instead of forcing an organisation to accept a specific solution, the chances that a solution will succeed, can be greatly improved by understanding the values of the recipient, and making sure that the recipient is not any worse off.

I spend most of my time building federated security solutions, and Brian is the unofficial author of the definition federated architecture, so I would have en enjoyed a perspective from him on how instead to pull together the values of technical infrastructures in different organisations using federated architectures - rather than dreaming of unity. But that's a topic for another post.

A long time ago I wrote an authentication module allowing users to login to phpBB3 with a SAML2 token. The authentication module wraps SimpleSamlPhP in a phpBB authentication module and integrates with the phpBB user and group management system.

I finally found the time to remove the client specific configurations from the source, and publish it in full on Github:

https://github.com/strandbygaard/phpbb-saml2

The authentication module was written for phpBB v3.x (current version as of this post), and has the following features:

• Federated user authentication with SAML2
• Automatic user profile creation on phpBB
• Automatic management of user group-memberships on phpBB

The authentication module wraps SimpleSamlPhP in a phpBB authentication module and integrates with the phpBB user and group management system, so that a profile is automatically created for new users, and new users are made members of relevant groups in phpBB based on attributes in their SAML2 token.

The module is quite rudimentary, as it was developed in a very short timeframe for a one-off project with somewhat specific requirements. It has, however, been used on a medium traffic production phpBB site for the past year and a half without any issues to date.

Limitations

This module is merely the plumbing between SimpleSamlPhP and phpBB. It does not deal the configuration of SimpleSamlPhP, and it requires some knowledge of phpBB to install and enable the authentication module.

SimpleSamlPhP is a very mature framework that is successfully used in large production environments with thousands of simultaneous users, and multiple logins (issued tokens) per second. It does require some knowledge about things like certificates, SSL, and SAML2 federation to configure it, but their website provides a great starting point for howtos.

I highly recommend that a basic SimpleSamlPhP is successfully tested with the identity provider before the module is enabled in phpBB. Different identity providers have different default settings, and it can take some tweaking of configurations for SimpleSamlPhP to make it work.

I have successfully tested with module with several different identity providers including SimpleSamlPhP itself, Safewhere*Identify, and Microsoft AD FS2.0.

There can be many reasons, and the following solution is rarely it, but when the following error does occur in the eventlog:

A timeout was reached (30000 milliseconds) while waiting for the AD FS 2.0 Windows Service service to connect.

It can be difficult to troubleshoot, and Google fails to turn up a solution. Usually, the solution is to increase the service start timeout value. Just do this:

http://support.microsoft.com/kb/922918

On the internal AD FS2.0 server, the problem usually occurs, when it takes more than 30 seconds to connect to the database server, and is mostly seen after the AD FS2.0 server has been restarted.

On an AD FS2.0 proxy, the problem usually occurs because the service takes more than 30 seconds to connect to the internal AD FS2.0 server, and is mostly seen in the last step of the AD FS2.0 proxy configuration wizard.

The error can occur on both internal servers and proxies.

About a month ago, a Danish tech news outlet published an article based on public access to a report I wrote about the code quality in POLSAG.

Not to be outdone, Computerworld.dk has now posted the full report (local copy).

The Danish press has been writing a lot about the troubled POLSAG project.

Apparently, one news outlet managed to obtain public access to a report I wrote about the code quality in POLSAG, and published a story about it.

They actually managed to read and report the contents fairly accurately :-)

Original link

Ever tried getting OpenCV running in Mac OS X 10.8 (Mountain Lion)?

Plowing through all the documentation and guides can be a pretty daunting task (well, at least they exist). These simple steps will get you up and running with OpenCV 2.4.2 in XCode 4.5:

First compile, build, and install OpenCV from sources:

1. Install Homebrew. Open Terminal, and run this command ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"
2. Run brew install with all of {svn, cmake, ffmpeg, libjpeg, libpng }
3. Get the latest sources for OpenCV (currently OpenCV 2.4.2) here
4. Unpack somewhere and cd into the folder in Terminal
5. Run cmake .
6. Run make && make install

Next step is to create an XCode project that uses OpenCV. This is as simple as creating a new C/C++ project and specifying search path for the OpenCV headers and libraries:

1. Open XCode and choose File > New > Project > Command Line Tool
2. For the target select Build Settings
3. For Header Search Paths, specify /usr/local/include
4. For Library Search Paths, specify /usr/local/lib

In main.cpp, add something like this to test it out:

#include <opencv2/opencv.hpp>

int main(int argc, char *argv[])
{
    IplImage *img = cvCreateImage( cvSize(100,200), IPL_DEPTH_8U, 3);
    cvNamedWindow("Hello World!", CV_WINDOW_AUTOSIZE);
    cvShowImage("Hello World!", img);
    cvWaitKey(0);
    cvDestroyWindow("Hello World!");
    cvReleaseImage(&img);

    return 0;
}

An alternative method is to install OpenCV with Homebrew, brew install opencv (not tested), but the dependencies requires amongst other things a fortran compiler, which I didn't want on my system, so I took the slightly more elaborate approach of manually installing dependencies and building OpenCV from source.

Edit:

See also this guide.

The spring cleaning that has been going on at Google is more thorough than I had anticipated. They are passing on Sketchup. Official announcement is here.

Unlike the other services Google has been shuttering, Sketchup has been a very popular product (though probably not commercially succesfull), and consquently is not being closed. Rather Google is passing on the baton to Trimble. In fact, Sketchup was so succesfull with the average user, that e.g. AutoDesk have created their own version of a free 3D modeller.

This move is quite surprising to me, because of the strategic importance Sketchup appeared to have, until now at least. Sketchup has so far been the way to create structured content for Google Earth and thereby Google Maps. With the handoff of Sketchup, Google is relinquishing total control of this content creation value chain, which suggests that they're no longer aiming for at full 3D model of our physical world.

With the development Google Maps has seen, at the comparable standstill of Google Earth, it seems reasonable that Google Earth will eventually go away, when Google Maps reaches feature- and performance parity.

If you use Google Calendar, have multiple calendars, and want to show them on an iOS device using an "Exchange" connection to GMail (provides better push support than IMAP), to use the page http://m.google.com/sync, you must be (1) logged in with your Google account in Safari, and (2) show the page in English.

I just got a new Ipad, and had to go through the usual hoops to setup mail, contacts, calendars, etc. I use multiple calendars in Google Calendar extensively, and if you connect the iPad to GMail using "Exchange" in iPad, getting to the "extra" calendars on iOS isn't as straight forward as it could be. Some googling eventually always brings up the link to choose which calendars to sync - currently, it's on http://m.google.com/sync, but for some reason I kept getting the error "Your device isn't supported" when visiting the link on my new iPad.

In this post, I'll go over the required steps on AD FS2.0 to successfully set up an OIOSAML.net based relying party. The key to success are three specific claim rules, and a single change to the default configuration.

OIOSAML.Net provides a mature framework for creating SAML2.0 based federations between an ASP.Net based relying party, and an identity provider such as Microsoft AD FS2.0, and it only requires minimal configuration on AD FS2.0 to set up an OIOSAML.net based relying party.

Unfortunately, when the configuration isn't just right, the errors provided by OIOSAML.net can be very arcane and cryptic leading to countless hours spent troubleshooting a seemingly very simple task. The reason being, that the OIOSAML.Net framework performs strict checking of the OIO Web SSO Profile.

Claim Rules

Three claim rules are a precondition to federating OIOSAML.net with AD FS2.0:

1. Issue the specification version claim
2. Issue the assurance level claim
3. Correctly set NameID

The first two are easily achieved with two simple custom claim rules:

First, add a rule that always issues a claim with type "dk:gov:saml:attribute:SpecVer" and the value "DK-SAML-2.0":

@RuleName="Issue Specification Version (required by OIO Web SSO Profile)"
=> issue(Type = "dk:gov:saml:attribute:SpecVer", Value = "DK-SAML-2.0"); 

Next, add a rule that issues a claim with type "dk:gov:saml:attribute:AssuranceLevel", and a value matching the assurance level of the chosen authentication method:

@RuleName="Issue Assurance Level (required by OIO Web SSO Profile)"
=> issue(Type = "dk:gov:saml:attribute:AssuranceLevel", Value = "3"); 

The last requirement, setting the NameID, can be achieved in a number of ways. A quick, initial, approach is to pass through a Name claim:

@RuleName="Pass through Name Claim"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"] => issue(claim = c);

And transform it to a persistent NameID:

@RuleName="Map Name Claim To NameID"
@RuleTemplate = "MapClaims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");

Changing Signature Algorithm

AD FS2.0 defaults to SHA-256 for signature algorithm, which is supported by the Windows Identity Foundation Framework (WIF), and not much else. If you're federating most anything not based on WIF with AD FS2.0, then you likely need to change the signature algorithm from SHA-256 to SHA-1. This is also the case with OIOSAML.net

This configuration hides under AD FS2.0 > Trust Relationships > Relying Party Trusts > [your RP] > Properties > Advanced

This is the best news I've had all week!

Microsoft and Joyent have announced that they will work towards making Windows a supported platform for Node.js

If you live in a Windows shop, it will no longer be political suicide to suggest a Node-solution. Well, at least less :-)

The event driven nature of Node.js, is just a much better solution to many problems, than the more traditional per-request threading model that many web servers employ. Handling 10.000 long running requests on IIS is no fun, but it's a breeze in Node.js

For some nails, Node.js is simply a much better hammer! That it also scales really well, is an added bonus.

At the moment Node.js solutions can really only be deployed on *nix platforms. Node.js does run on Windows, but everything about doing so is a hassle and it's Cygwin cage hampers performance. Unfortunately, most Windows shops are terrified of anything non-conformant, which often means solving problems with 'approved' tools, rather than the best tools, effectively ruling out Node-solutions deployed on anything non-Windows.

This news brought Node.js a little closer to becomming an approved tool, rather than just being the best :-)