Web 2.0 has been all the rage for quite a while now. And concerns are being raised that this may be yet another bubble. But to me it makes no difference, as I probably wouldn’t know a web 2.0 if it grabbed me by the eyeballs (yes, I too remember the previous round of “stickiness” and “monetized eyeballs”).

I care mostly about hard technical problems with equally elegant technical solutions. Like the stuff we do at Safewhere. We are building an advanced and very cool suite of infrastructure products. We make a lot of hard, complex things simple, and we address problems that have not previously been addressed in a consistent and unified manner. Usability we don’t know enough about – and we will hire clever people to do this. But when it comes to hard computer science problems we employ the brightest comp sci graduates you can get.

Which brings me to the “and why in Denmark” part. If you ever want to put smart people to work on a hard problem, go with the Danes.  Danes may suck at doing marketing on a grand scale, but they excel at solving complex problems in small teams. Every person on the team will feel that he or she is as smart as the next guy, and they will all take responsibility for creating the best solution –as a team. Danes tend to accept only a very low power distance, and they are generally more anarchistic than many other nationalities.  When you build software this may be leveraged to create great results much more efficient, than would be the case in countries with higher power distance.

So why aren’t these fantastic Danes to be seen anywhere? Well, eh, the Danes have this other habit of being on vacation most of the time, getting off work early – and most importantly we have no confidence that we will ever be successful. And if you still manage to succeed on a grander scale, you better be prepared to be put down for it – badly and promptly.

At Safewhere we are betting, that we may leverage the collective intelligence and lack of power distance to become successful fast enough that nobody has the time to lose their nerve.

– And by the way, we do have one successful businessman from Denmark. He has big boats and sometimes uses them to transport guns to Iraq –for free and for love of USA and freedom.

Just finished the second week of exhibiting at Microsoft TechEd in Barcelona.  This week it was IT Forum which translates into an audience interested in how you actually run and manage an infrastructure based on products from Microsoft and its partners.  Not much to be said about the trade show as such – it was much like last week and we are happy.  The quality of the leads this week is probably a bit higher than those we got last week with the software developers.

But here is another perspective intentionally set up to provoke half the audience at IT Forum – only that they’ll never read this, as they are not interested. The half I’m talking about we may refer to as the scavengers of IT Forum.

It started when I flew back to Barcelona on Monday. The guy behind me was doing the best he could to make clear to all, that the personnel of the largest Scandinavian retailer get messed up and go to IT Forum only because their boss tells them to.  Was this a sign of what was to come? In a way yes, only the rest of the scavengers are probably not as bad as this guy from Coop.  Fortunately he was the first and in the end he still managed to take the price.

But indeed it is an indication of the difference between the two TechEd conferences. The audience of TechEd: Devleopers are software developers with an almost religious relationship to their computer, programming language, communication stack etc. These people go to TechEd because they wouldn’t miss it for anything, and they beg the bosses during the year to get a chance to go to the next TechEd. I like them for their genuine interest and oftentimes curious minds.

As for the audience of IT Forum it may be divided into two groups. One half tries to take what the developers came up with, and actually make it useful to users day in and day out.  These people buy, install, operate, and retire IT systems. They are focused on how to provide a smooth and robust infrastructure of value to their organizations. They may scavenge a bit, but not for a living.

The other half is the real scavengers.  And – inexperienced in a world of IT tradeshows as I am – this group turned out to be a crowd, you wouldn’t want to run into in a dark alley if carrying as much as a cheap pen with the logo of the local waste management company. Maybe they drink bloody marys like the guy from Coop or maybe they are just ordinary guys, but they share the common background of having no special interest in software and IT. They go to TechEd to rid Microsoft and the other exhibitors of free T-shirts, iPods, Frisbees, pens, flashlights, cookies, strange things with LED’s inside, etc. (But no chocolate fondue for these guys. Ha!) The bags they got when registering the first day were so loaded at the end of the week, that many gratefully picked up the extra bag offered by APC. 

And so I could go on – offended I am, and I know I’ll just have to get used to it.  But I am a developer at heart and I like people who show a genuine interest in what they do for a living.

 We just finished our first tradeshow, Microsoft TechEd in Barcelona. Next week we will do IT Forum as well.

TechEd: Developers, as it is officially called, was good for us, but not entirely the way I expected.  But first, here is why it was a success to our young company. We met with a lot of potential customers from our immediate vicinity, Denmark and Sweden. And several of those showed sincere interest and a couple even more than that. And to these people it is a comforting factor that Safewhere has actually started down the road to become an international software company. To them it means more customers to push Safewhere along the right path of continued innovation and development.

1. The Safewhere brand is unknown. Period.
2. Developers are not all that concerned about managing authorizations across deployed services and applications. They lean more towards computational and programming challenges.
3. Developers going to TechEd are pretty focused on what Microsoft will do to them and for them. Short of brand recognition, Xbox giveaways and chocolate fondue (no kidding, Compuware really did that - while at the same time employing a Formula 1 racing theme!), getting the attention of a developer takes our preparation of them even before they ever arrive at TechEd.

Now, that’s my analysis anyway. And our response is simple to identify and hard to execute: PR and Partners. PR generates recognition and partners generate interest in the concrete solution.
 
So in conclusion, I really had no idea on how it would go. It went very well – and next week at TechEd: IT Forum will most likely be even better.

Updated: Image removed

Safewhere is a young software products company with a lot of ground to cover on our ambitious journey to become a viable and profitable player in the international markets.

Viable in the sense that we succeed in creating and maintaining an organization of highly skilled people, who are motivated to make an outstanding effort to turn out products that people actually want.

Profitable in the sense that owners - which include many employees - may rest safely that our products are generating - constantly growing - revenues above our - constantly growing - spending.

As a frequent reader of Joel Spolsky's and Eric Sink's web logs on the various aspects of running a software company, I appricate their insightful posts. Joel's mostly for his views on recruiting and keeping good people. Eric's primarily for his views on how to market your wares in a world dominated by big guys.

But Safewhere is not an American company. Safewhere is located in the city of Copenhagen in Denmark. Denmark is almost socialist by American standards, but also consistently on top of the lists of global competitiveness such as the Global Competitiveness Report 2006-2007 by the World Economic Forum. This is primarily because of our liberal labor laws, which makes hiring and firing very straight forward, thus letting companies grow without running the risk of being caught with a huge salary burden in a down-turn. And the reason it is accepted by the labor force of Denmark is, of course, because of our well functioning public welfare system.

So, however Safewhere fares, I intend to document some of our experiences relevant in the context of building a company from the perspective of an entrepreneur - and sometimes also with a more political angle.  The latter because I genuinely think that politics and running a business obviously do go together, just as politics and being a citizen go together.

Updated: Image removed.

Safewhere, the company I work for and co-founded, is busy getting its first product, Safewhere Authorization Services, ready to show and deliver when we exhibit at the two Microsoft conferences, TechEd and IT Forum in Barcelona in November.

The product is already attracting a lot of attention and the first customers in our Danish vicinity, and we are looking forward to discussing and demonstrating the concepts and features with a wider audience.

Please come and see us at Booth C9 for TechEd and C17 for IT Forum.

After 10 years trying to pick up sales and management skills and developing software for Microsoft Windows, I finally got around to installing my first Linux variant, Ubuntu Desktop, version 6.06. Installing in a VMWare machine was faster and more elegant that any Windows install, and doesn’t look much like the clunky X11 Motif that we used the last time I wrote serious C++ code for Solaris and AIX. Very impressive. Whether it will be secure, stable and performant I have no idea, but the covers look great.

Sorry for the delay, but here is the source for the WSE 3.0 and Azman authorization sample that went with my MSDN Magazine article on service authorization using WSE 3.0 custom policy assertions and Microsoft Authorization Manager, Azman.

It has been updated to use the released versions of .Net 2.0, WSE 3.0 and Enterprise Library 2.0.

Please download from here, and follow the steps of the README file (40,1 KB, RTF). Note though, that the current sample runs on Windows 2003 only, as it is based on Kerberos which is much easier to make work on IIS 6. (Network Service is the default account for IIS 6.0 App pools, and has access to AD).  The README file has a comment on what it will take to make it work on XP with IIS 5.

The source may be downloaded from here (237,5 KB).

Disclaimer: This code has not been thoroughly tested and is meant as inspiration and illustration only.  Our company, Safewhere, makes the industrial scale version which includes a different modeling approach and support for multiple types of credentials - among other things.

Safewhere, located in Denmark, is looking for technical software devlopers. We are developing an advanced SOA security product, working title Safewhere Authorization Services, which requires deep knowledge of, and interest in, frameworks and platforms more than general application developer skills. Advanced use of many Microsoft technologies is part of the job, as is implementation of core WS-* specs.

Let med know (my three initials@safewhere.net) if you need more info, or, if you read Danish, read a bit more here.

Just came across Vibro's weblog which includes a post on an informal graphic notation for illustrating the concepts involved in WS-Security and a small part of WS-Trust (communicating with an Security Token Service). 

I might just pick up on his notation which should be useful, as he points out, for communicating the complexities of message security.  So thanks to Vibro.

This is the first post on what we are working on at Safewhere™, formerly CI Networks.  (And we're not working on our web site either - will just have to wait for the designers to start work in January.)

The problem is with authorizations in a world of autonomous and loosely coupled web services.  Autonomous in the sense that they live their own life and may contact any other service they see fit, although most likely constrained to some extent by the hosting environment. And loosely coupled in the sense that they participate in higher level processes, that may be reconfigured or extended - or new ones may be created and wired to use our service.

It used to be that users would be authenticated basically once and then the user interface would restrict what a given user was able to do.  And if things get a little more complicated, which they normally do, the backend will check again in more detail to see if a given request or transaction should be allowed to proceed.  Determining if a user is authorized to perform an action is mostly a matter of checking membership of a group, and more rarely also of checking e.g. if the amount requested is below the maximum allowance of a given user.

Enter SOA.  (And no matter what your more precise interpretation turns out to be, the above scenario of autonomy and loose coupling probably sounds familiar.)  How do you make sure that the entity or person sending you (as a service) a message is actually authorized to request you to carry out the implied actions?  Messages may arrive from any other service and user on the network. 

Two issues here: Unauthorized context or just plain unauthorized.  The latter we are used to dealing with at a basic level, whereas the former is a somewhat new experience.

The problems with just plain unauthorized are many, but as both the number and distribution of services increases so does the difficulty of defining, managing, and understanding access requirements.  And in a world of messages, the message must carry sufficient and credible proof of identity - or some other claim of right.  This is not to be left up to the transport (e.g. SSL), as there is no knowing where and how a message may travel on its way.

As illustrated here it seems the context issue is simply matter of asking "as part of which process are you trying to do this?", but it may really be broadened to include also situations where

• Authorization depends on contents of the message. This would be the case when the message holds a request to transfer a sum of money, which may or may not be too large relative to the allowance of the given user or service initiating the request.
• Authorization depends on something that really is not known until sometime after the internal service logic starts to do its work.  This would be the case when the request message simply says transfer the remaining sum for this customer, and the service logic would then dig out the amount and go to work. 

In the case of all but the last type of authorization, the actual authorization check may be moved into the infrastructure and out of the hands of the developer with two immediate benefits: No need to worry about or decide on this issue at development time.  And authorization may possibly be configured after service deployment, provided the infrastructure knows how.  (The latter is illustrated in a limited scope by my MSDN article on AzMan and WSE 3.0)

So if you think this is an issue worth dealing with, please let me know - or if you have opposing or clarifying views even more please let me know.

- and Merry Christmas, which around here is tomorrow night.