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.

Havde i dag mulighed for at præsentere OIO-udviklerforum i Videnskabsministeriet for udfordringer og koncepter i forbindelse med autorisation og rettighedsstyring i en service orienteret infrastruktur. 

Præsentationen kan hentes her (553,5 KB).

Didn't think this blog would be political, but whatever.

Check this piece of news from the Electronic Frontier Foundation.  Appearently many printers will print little invisible yellow dots, so that any document you have printed may be tracked back to your printer at any later time.   The article also references a list of printers that are known do the little Secret Service trick.

Who said types like John Le Carre and Michael Moore were ever paranoid?

Mark Fussel, (program?) manager of the WSE team, tells us that WSE 3.0 (find more here) will ship at the same time as as Visual Studio 2005 in November.  No "time frame" stuff here, just a time.

This should be good news to you too, if you are in any way serious about "industrial strength" Web Services.  As soon as you get it, you must apply the parts of the security stuff relevant to your service or app.  And consider all the other good things too - but security first!

If you happen to be trying out Team System with all its bells and whistles you really should apply a modified version of "Develop with Least Privilege" or whatever it is called.  Only, with Team System you should use a "Least License" approach if you want to be kept aware of the licenses you'll actually need.

I'm writing this, as I just became aware that in order to run your unit tests as part of a Team Build you must first set up a Build Verification Test (BVT) list.  Setting up a BVT requires that you have VSTS for Testers (or the full suite).  So at the end of the day you will never be able to do much quality software development (never mind architecture) without both the Developers and Testers editions.  And the latter you may need only to set up the BVT.  (The other functionalities of Tester we don't need as Mercury TestDirector is already in place and doing fine.)

So, Microsoft, maybe this packaging should be up for reconsideration?