Just to satisfy myself that the Solaris 10 U4 iSCSI target is working well, I fired up a few file system stress test processes to see if the Solaris machine (and the iSCSI initiator) hold up.

For the test itself, I took an old but reasonably reliable SQL Server hard drive test (can be downloaded e.g. from here). I took the default parameters with medium workload (100MB files), especially since my test drive was a virtual machine on my laptop. Write caching was off. The purpose of this test was not to create a performance evaluation or a real stress test, but much more a proof-of-concept that the two systems would work together.

Here is the final result:

The next step would be a full stress test, preferably with at least 3 or 4 high-powered drivers. That might take some time, though. Meanwhile: happy SAN building.

tag: windows, iSCSI, Solaris

... but it seems that the marketeers at Microsoft are finally getting interoperability: Dino Chiesa blogs about how SCA is an endorsement for WCF. That in itself might be a questionable statement, but he makes a very good point about what makes interoperability a reality:

"The WS-* work the industry has pursued since 1999 shows that we (vendors, customers, developers, pretty much everybody0 recognized that protocols were the sine-qua-non for interop. PROTOCOLS people, not programming models. Protocols, Protocols, Protocols, Protocols, Protocols, Protocols!

And let 1000 flowers bloom! Given a standard protocol, the world can support a myriad of programming models, and they can look like anything they want. As long as each implementation produces the same on-the-wire protocol, they can all intercommunicate. Glory be!"

One is tempted to say: "Finally!" or "Words of wisdom!" or even "Took 'em while, but they finally got there." Yes, Dino: I could not agree more. To enable full interoperability between particular software components running on different machines (and perhaps even operating system - and I mean to go beyond Windows 98, 2000, XP, 2003, Vista, CE, and mobile) you need full protocol disclosure. And just to clarify: this would mean syntax and semantics of all network communications between two systems that are meant to be interoperable.

So, if we are talking about OS level interoperability like "samba" or "PC NetLink" (yes, I've been that long at Sun) and "NT-SAM" or "Active Directory", this would also apply, correct? Can we expect a gesture towards the samba community in the near future?

Hoping for a positive answer on this one ...

tag: interoperability, interchangeability, WCF, J2EE

Here is a really nice add-on that got shipped with Solaris 10 update 4 (08/07): starting with this OS release, Solaris supports iSCSI targets. Together with the Microsoft iSCSI initiator for 2000/XP/2003, this allows building a very comprehensive and compelling SAN (Storage Area Network). Here is a screenshot:

Now, in order to get this to work, you need to do the following things:

1. Install Solaris 10 08/07 (update 4)

2. Install Windows and the Microsoft iSCSI initiator 2.05 build 3392

3. Follows these guidelines to configure a target

4. Read up on the MS initiator on how to discover and mount an iSCSI target

Overall, this procedure is not very difficult and you will have a system running within a few minutes. 

Please note that I did not (yet) test CHAP authentication or Vista compatibility, but - given some time - I will try this later.

tag: windows, iSCSI, Solaris

Yesterday, Kim Cameron picked up on a recent article Bob Blakley. The central theme is about Stefan Brands' criticism of OpenID. While Bob sets out to ask the OpenID 2.0 folks some hard questions about what kind of problem they are actually trying to solve, Kim opines that some of the criticism brought forward by Stefan (and Bob) is unfair, since it is out of the scope of what the original intent for OpenID was.

Instead, Kim suggests that there is a spectrum of identity systems which address different needs. Thus, all such systems including SAML 2, WS-Federation and - by extension - the WS-Trust based InfoCard identity system^[1] should answer the questions posed by Bob to OpenID 2.0:

"[Bob] argues that the OpenID specification should include an articulation of the constraints on what it is attempting to achieve.

I agree, with the proviso that other protocols, like SAML 2.0 and WS-Federation, should do the same."

A lofty goal, who could not agree to that: it is most crucial that software architects and designers spend time on defining the boundaries of a given solution. However, prior to limiting and classifying solutions, it would also be neat to actually identify (sic!) the problem/use-case of the solution under examination.

Although I try not to sound like a broken record, I do have to come back to a favorite theme song of mine: Liberty Alliance has done all these nasty and boring use-case evaluations, requirements, and scope definition like privacy and trust evaluations. Interestingly enough, a lot of these often fairly generic assessments is indirectly offered to other identity systems through Project Concordia.

tag: identity, OpenID, Liberty Alliance, meta-system, InfoCard

[1] Kim writes: "Popping up a level, we need a spectrum of solutions to identity problems.  Ergo, the identity metasystem." This is - in my opinion - an obvious example of why the term identity meta-system is very misleading: here it does not necessarily refer to the 'meta'-system defined by the InfoCard architecture, but rather to what I jokingly referred to as the "Aleph 0 Identity System" - a 'true' meta-system of protocols, deployments, etc.
But such a 'true' meta-system is not exclusively a WS-Trust based replacement for HTTP Redirect (WSTBRFHR), like the InfoCard identity system .

Here is an interesting article from SPIEGEL ONLINE (unfortunately in German only). It describes how one of their journalists  - Franz Walter - ended up in Spock.com as being related to the National Socialist Walter Gross. This caused another newspaper to contact Mr. Walter and ask him where he stood politically.

To understand the significance of this event, you should know that for all even half-way decent Germans any association with the former National Socialists is abhorrent. On top of this, the SPIEGEL ONLINE and its journalists are well known for their left-leaning political alignment, making such an association professionally untenable.

The root cause for this event seemed to have been a particular image on the web. That image had the file name "walter_gross.jpg", which would translate into English as "walter_big.jpg", referencing a large image of Mr. Walter. The algorithms of Spock were tuned to English key words, but associated a file called "walter_gross.jpg" to the former head of the national socialist racial policy office.

This episode is quite telling: when architecting complex identity system, we must be very careful with the semantic significance of attributes of a given digital identity. In this example, the linguistic limitations of the algorithm caused a false identification of a living person with a dead criminal.

This time it did not cause any harm, mostly because it was extreme and found very early. But what if a similar incident happens to fresh college graduate looking for a job? In this day, it not too uncommon for managers and HR departments to take a quick look at what Google, LinkedIn, or other search engines or social networks turn up on a given name. It is bad enough, when people ruin their reputation by publishing inappropriate photos of themselves. Worse, if someone impersonates an adversary and tries to ruin his or her online reputation. But having an "Identity System" or social network do this automatically makes me very afraid.

tag: identity, identity theft

There has been quite a bit of discussion about SXIP's recent OpenID Infocard token profile: Johnny Bufu, Peter Williams, and I had some email exchanges, Eve commented on Eric's blog, and Dick made some comments about his view on the IPR status.

All this is great, exciting, or anything else you might want to use for describing conditions of euphoria. And I do acknowledge the work that Dick, Johnny, and Mike put into this effort. However, the big questions that are still unanswered (at least for me) is: who cares? And: are we hurting ourselves?

The Bigger Picture

If I take a look at the deployment rate of new-identity-protocol relying parties, i.e. mostly OpenID and Infocard, the picture is rather sobering: there is little activity^[1] and currently also few signs that this might change. One of the interesting results of the recent OpenID project at Sun was that successful web property owners have little or no interest in outsourcing their identity system, or even only the authentication part of it (which is the only established role of OpenID or Infocards at this time).

The same kind of behavior can also be seen on a larger scale where the big application and service providers like Google, Facebook, or Yahoo! have little or no real interest in a truly federated/distributed internet-wide identity system, since it is not compatible with their respective business models^[2].

So overall, it seems safe to assume that any effort directed at convincing web property owners to adopt a particular identity system is an uphill battle. Especially, if they have to invest time and money into equipping their web server with a compatible relying party.

OpenID Tokens, Anyone?

Now, what would be required to use the OpenID Infocard token profile? In addition to the entire OpenID infrastructure (OpenID Auth 2.0 et al.), you would also need a - more or less - complete Infocard infrastructure. In addition, you would need to make sure that the respective parts are tightly synchronized ^[3].

In addition, none of the OpenID specifications have passed extensive peer review in an open standards process, have IPR issues plastered all over them, and are - pretty much - all in beta (or pre-alpha) at this time.While these issues have been discussed in the past, it still seems reasonable to point out in this context.

Rolling out a complete and fully supported Infocard infrastructure is somewhat easier, since Microsoft is providing de facto reference implementations for the card selector and the relying party. Also, the IPR situation is less confusing, since the OSP covers - as far as I can see at this time - a pretty large chunk of the complete Infocard identity system.

Who cares now?

For a potential deployer, the question is now: "If I have an (almost) shrink-wrap identity called Windows CardSpace, why should I start to dabble with the deployment and replace the built-in SAML tokens with OpenID tokens?" Besides the technical difficulties, there is also the issue that an OpenID token based Infocard deployment only allow what is called "auditing mode". Add to that, that most clients will probaby not have Infocards with the OpenID tokens installed, my initial questions come up again: who cares? And: are we hurting ourselves?

Most end-users do not care at all. In an Infocard-world, they just want to use the Windows CardSpace selector to login. If a given site does not support self-signed cards or a managed card they already have, chances are that they will simply go away.

The relying parties do not care either: most of them want to attract users to their sites. If there is a simple SSO/identity system they can deploy and buy support for, they probably will as long as it fits their business model. Many successful Liberty deployments attest to that. If it involves unreleased or unsupportable technology, potential patent disputes, or simply a lot of additional work, they will likely shy away from such a solution.

There are also no benefits to the IdPs: having to run a combined OpenID/Infocard infrastructure might attribute only to a little administrative overhead, but it does not really add a lot of additional benefits either.

Are We Hurting Ourselves?

My answer to this would be a decisive: "yes". While the OpenID Infocard token replaces the HTTP redirect with the much more phishing resistant Infocard scheme, it will lead to some significant confusion in the marketplace. Educating customers and end-users might help to some extent, but explaining the differences between auditing and non-auditing mode is going to be very difficult. This is why Kim is rather careful about not advocating it: it breaks his own 7 laws.

At the end of the day, relying parties will have to decide what they want to do - and it seems to me that the decision for or against a particular identity system (such as Liberty, Infocard, or OpenID) will not be based on tokens, but rather on the entire package, including vendor support, reachable customers, and overall acceptance.

tag: identity, OpenID, Liberty Alliance, SSO, InfoCard

[1] Especially when comparing this with the rate of IdP rollouts for these protocols.

[2] In fact, I would argue that the interoperability debates of the 90s - WindowsNT/Active Directory, eDirectory, LDAP, etc. - were focused on the same issue of identity. At that time, it was the software suppliers fighting over identity WITHIN the enterprise, since control over the user database was the key to influence a lot of strategic decisions.

[3] To be fair, this is true for all complex interoperability scenarios.

Just some Friday humor:

tag: facebook, identity, humor

Just a quick update: OpenSSO is now using the WSIT/Metro STS for WS-Trust protocol transactions. Congratulations to the team (and especially Mrudul) for getting this done!

tag: identity, opensource, opensso, ws-trust

During last week's Project Concordia call, we had an interesting discussion about cross-protocol identity use cases and scenarios. Ashish made a very good observation during this call: many times when we are discussing identity protocol transitions or cross-protocol use cases, we are not so much dealing with protocol interoperability, but rather with a protocol mashup.

Proper interoperability - in this definition - requires the ability to interpret foreign protocols and have full access to the semantical content. I have sometime referred to this level of interoperability as interchangeability. An example of such high level of interoperability would be the ability to extract authorization data from a Microsoft Kerberos ticket and use the NT-PAC data to create a SAML attribute statement.

A protocol mashup on the other hand would only require very limited knowledge about the semantics of another protocol, but instead it simply profiles the use of one protocol (or in this case: identity system) with another. A simple example would be the use of self-signed InfoCards to authenticate to an OpenID Provider.

tag: interoperability, identity, Liberty Alliance, OpenID, InfoCard

Tatsuo Kudo wrote an article in Japanese on how to configure the OpenID Extension for OpenSSO. As far as I could see (http://tinyurl.com/35gfuh), this is a great article.

tag: openid, sunopenid, opensso