Flex … not that flexible it seems …

In the last few weeks I have come into contact with Adobe Flex to create a separate Flex front-end that talks to a back-end using web services. The advantage would be rapid development of a front-end that can use the tons of fancy UI features offered by Flex.

After a few proof of concepts I quickly ran into several issues. The most important being that Flex does not support WS-Security. Read that again: Flex does not support WS-Security. Note that Flex is positioned as something that prefers to use web services to talk to the back end. Also check this bug report. There are some tutorials that explain how you can cheat and add WS-Security headers yourself. This is obviously limited to simple headers and does not include signing or encryption.

I wonder how Adobe can keep on positioning Flex as a great enterprise capable way of creating portable rich front ends when they don’t support WS-Security. They don’t support any of the WS-* standards.

Not supporting WS-Security is one thing, it might be on the road map but not yet implemented. There is however something else in that bug report that caught my attention …

dashes (-) are not allowed while naming things like classes, variables, attribute, etc in AS3. The elements named with dashes, when mapped to AS3 objects will not compile.

Gasp. Not allowing dashes in naming is something that other languages also do but having a standard mapping (XML/SOAP to ActionScript 3) that does not take this into account is more severe. They obviously didn’t test the mapping extensively or they did and ignored the results.

For me, as a developer, this is also an indication that their underlying code that maps XML to ActionScript objects started as a quick & dirty implementation to support simple demonstrations and somehow grew into code that went into the production version. The fact that they don’t support any of the WS-* standards only supports this theory.

What about me !?

Paul Madsen got a Facebook invite from Ping’s Patrick Harding. It seems he was very proud of it until he discovered that, quoting Paul, “Patrick is making more friends then Britney backstage at a ‘Boyz II Men’ reunion tour.

I jumped over to Facebook to see if Patrick had already invited me and, if he did, rub it in Paul’s face that I was before him. Sadly, neither Paul nor Patrick are in my friends list. For now, there will be no joy in humiliating someone.

I send invites to both of them, let’s see what happens. I did meet Paul in person on two occasions: the Liberty meeting in Brussels and on the first European Identity Conference.

Ben Laurie’s Capabilities

The blog of Ben Laurie is on my blog roll since ages (well, Internet ages). He often has great and refreshing views on topics like identity, privacy or security. On top of that, the quality of the post has always been excellent. If you don’t have his feed in your reader, now would be a good time to include it.

One of the recent posts was about a paper he wrote on capability based security systems. I knew from university that depending on how you read a matrix mapping users, resources and access rights, it would be an access control list or a capability list. Therefore it looks at first sight as if access control lists and capability lists are semantically the same. You either store the rights on the resource itself and it becomes an access control list (most common example is a filesystem). You can store all the rights associated with a particular user and it becomes a capability list. Perhaps this was a simplification done in the textbook we had but it certainly has a degree of logic to it. As Ben explains there is a subtle difference between the two concepts and although they have a lot in common, they are not entirely identical in terms of protecting access to resources.

A good example of the difference between a system based on access control lists or a system based on capabilities is given by Ben in the paper. In a typical application, when a user needs to safe a file, the user is presented with a Select File dialog. Based on this selection the application will ask the operating system to open the file. Based on the access control list on that file, the operation will be allowed or not. In a capability based system, the Select File dialog could be a trusted component presented by the operating system, similar to the card selector of Infocards in Windows. The selection of a file would result in a capability to open that particular file. The application can then use the capability to access the file. In an access control list based system, the file selected by the user is not necessarily the file being accessed by the application. If the applications intentions are not good, it might decide to open a different file. In the capability based system, this would not be possible.

Ben also states that there is room for both systems: access control lists and capability based systems. Depending on the environment and the specific requirements, one system will be better suited then the other. In particular Ben sees capability based systems as very promising in the context of securing various (semi) executable content in web pages. Examples include HTML and scripted content from foreign sources in a web page. A technique more and more used in social networking sites or personal portals as iGoogle.

Although I agree with Ben’s reasoning (who am I to question his experience and knowledge) there are some points in the whitepaper that I don’t fully agree with. In some of the later examples of the whitepaper, Ben starts to play with capabilities. By wrapping them in security containers (for instance signing) they can be passed over untrusted third parties. Capabilities can also be wrapped inside other capabilities to accomplish further control over the right granted.

In most of the paper, the definition of a capability can be fairly strict: it’s represents a capability, something the bearer can do with a resources (or a set of resources, whatever the capability points at). In the examples later in the paper, this definition does not hold anymore and suddenly widens to mean a lot of things. In section 6.3 (“Proving User Choice”) of the white paper a trusted component needs to pass a user action to a second trusted component. It does however use an untrusted intermediate for this. In order to prevent the untrusted intermediate to play with this, the performed user action is represented as a capability. It depends on the definition of a capability of course, but I have a hard time thinking of “the user clicked on the second image” as being a capability. This is more like a claim issued by a trusted component (the trusted renderer in the example). To me a claim is not a capability.

It is probably a matter of defining “claim” and “capability” of course. Perhaps Ben can shed some light on this?