Evolutionary scientists find it useful to contemplate the set of all creatures past, present, and future as part of an infinite design space (referred to by the natural philospher Daniel Dennett as the "Library of Mendel" in his book Darwin's Dangerous Idea - this a tribute to Gregor Mendel and his pea pods).
The idea is that particular species occupy (or occupied) specific positions in this design space, characterized by their values along an infinite set of axes (e.g. leg length, number of digits, etc). Evolution is then seen as movement through this space, the set of ooordinates for a species changing (smoothly or more jerkily depending on your theory) as time goes by.
Within this vast space there are some points (or more accurately lines) that have been occupied more times than mere chance would suggest is appropriate. Some features of living creatures are 'forced moves', i.e. things so obvious that we aren't surprised to see them repeated across many different animals and so repeatedly hit upon in design space. Examples include bilateral body symmetry, two eyes for stereo vision, mouth at the front of the body, etc.
When we see such forced moves in different creatures, we don't have to assume any special relationship betwen those animals, it's enough to know that the animals deal or dealt with similar environments and constraints and have independently come across the unavoidable wisdom of the forced move. For instance, otters and dolphins both have body shapes that are suited for moving around underwater but we don't have to believe that one evolved from the other (or from some recent shared ancestor) because of this similarity. Streamlining just makes sense when you spend alot of time underwater.
Some features of SSO suites are forced moves, e.g. things so obvious that we aren't surprised when multiple suites take advantage of them. Examples include HTTP redirects, URL parameters, HTML Form POSTS, SOAP-messaging, claiming to be user-centric, etc. Taking advantage of that which the common infrastructure provides just makes sense.
If however, we saw very similar features in different SSO suites for which it could not be claimed that both protocols were forced to that choice, then we would be justified in assuming that there was some sort of relationship between them, most likely through descent (acknowledged or otherwise).
For instance, Liberty defined the Authentication Context mechanism in itsID-FF. There is very similar functionality in SAML 2.0. Consequently, it's not surprising that the functionality in SAML 2.0 is directly descendant from that in ID-FF 1.2 (through Liberty's contribution of ID-FF 1.2 as input to SAML 2.0). It would be surprising (even suspicious) to see two so similar mechanisms in different SSO suites without such a relationship because authentication context doesn't feel like a forced move.
Why does this matter? The more forced moves there are, the greater will be the similarities between the different SSO suites (e.g. SAML 1.1, ID-FF 1.2, SAML 2.0, WS-Federation, SxiP, LID, etc) and the less fundamental the differences. The more trivial the differences, the greater the chances of interoperability between them.
Sunday, May 22, 2005
Saturday, May 21, 2005
Another use for Java?
Ben Hyde (Ben, we miss you in TEG) drew my attention to a VI reference coffee mug.
As user-centric identity management seems hot these days, perhaps we should expect to soon see something similar for SAML.
Interesting scenarios emerge.
Ok, let's see, I am a 'Senior Manager', I guess I'm supposed to use the <AttributeStatement> for that. Namespace? What the &&#$@*%$^# is a namespace. Oh jeez, I have to sign this thing, where did I put my private key? I just had it this morning.
A WS-Federation reference would be simpler. Perhaps a shot glass would suffice?
As user-centric identity management seems hot these days, perhaps we should expect to soon see something similar for SAML.
Interesting scenarios emerge.
Ok, let's see, I am a 'Senior Manager', I guess I'm supposed to use the <AttributeStatement> for that. Namespace? What the &&#$@*%$^# is a namespace. Oh jeez, I have to sign this thing, where did I put my private key? I just had it this morning.
A WS-Federation reference would be simpler. Perhaps a shot glass would suffice?
Lamarck Lives!
Jean-Baptiste Lamarck was the 19th century natural philosopher who is now best known for his much derided theory of evolution.
Lamarck postulated that animals acquire characteristics through their experiences and, importantly, these characteristics can be passed onto their offspring. The archetypical example is that the giraffe developed such a long neck through successive generations of animals extending their necks to get to the tender leaves on the higher branches of trees. Each generation saw the necks get a little bit longer as the animals continued to stretch out. The efforts of one generation were manifested in the next, the offspring benefited from what their parents had attempted.
Lamerck's theory - this inheritance of acquired characteristics is now widely refuted (including through experiments that had the tails of mice cut off for generations and yet they continued to be present on babies). Darwin's theory of natural selection is now accepted as the true driver of evolution.
.NET Passport is Microsoft's now much derided web-based identity management scheme that never really reached the potential that Microsoft seemed to imagine for it. .NET Passport spent its life in an environment of mistrust (e.g. why would I share my credit card with Microsoft) and privacy concerns (e.g. no one provider, even/especially Microsoft should have alll a user's identity info). While the SSO aspect of .NET Passport was apparently very successful amongst other Microsoft sites (e.g. MSN), other aspects (like the wallet) were not taken advantage of.
Like a giraffe's neck being lengthened through the exercises of its ancestors reaching for sweet acacia leaves, or like a mole rat losing its vision through successive generations of living in the dark, Microsoft is positioning .NET Passport's offspring as benefiting from the experiences of its ancestor. We have learned! What wasn't used is gone! We are now in context!
Lamarck would love it. Darwin not so much.
Strictly speaking, this would appear to be an example of the Baldwin Effect rather than a true Lamarckism.
Lamarck postulated that animals acquire characteristics through their experiences and, importantly, these characteristics can be passed onto their offspring. The archetypical example is that the giraffe developed such a long neck through successive generations of animals extending their necks to get to the tender leaves on the higher branches of trees. Each generation saw the necks get a little bit longer as the animals continued to stretch out. The efforts of one generation were manifested in the next, the offspring benefited from what their parents had attempted.
Lamerck's theory - this inheritance of acquired characteristics is now widely refuted (including through experiments that had the tails of mice cut off for generations and yet they continued to be present on babies). Darwin's theory of natural selection is now accepted as the true driver of evolution.
.NET Passport is Microsoft's now much derided web-based identity management scheme that never really reached the potential that Microsoft seemed to imagine for it. .NET Passport spent its life in an environment of mistrust (e.g. why would I share my credit card with Microsoft) and privacy concerns (e.g. no one provider, even/especially Microsoft should have alll a user's identity info). While the SSO aspect of .NET Passport was apparently very successful amongst other Microsoft sites (e.g. MSN), other aspects (like the wallet) were not taken advantage of.
Like a giraffe's neck being lengthened through the exercises of its ancestors reaching for sweet acacia leaves, or like a mole rat losing its vision through successive generations of living in the dark, Microsoft is positioning .NET Passport's offspring as benefiting from the experiences of its ancestor. We have learned! What wasn't used is gone! We are now in context!
Lamarck would love it. Darwin not so much.
Strictly speaking, this would appear to be an example of the Baldwin Effect rather than a true Lamarckism.
Friday, May 20, 2005
Meta-Interoperability
Sun and Microsoft's recently announced Web Single Sign On Interoperability Profile defines both how the Web Single Sign On Metadata Exchange Protocol can be used by providers to determine what SSO protocol suites another uses (e.g. Liberty ID-FF 1.2 or something else) and some slim profiles of those other protocol suites.
The profile specifies that, to be compliant, you MUST only use the Liberty ID-FF Browser POST Profile - the other profiles (e.g. artifact based) are excluded. WS-Federation is similarly constrained (although WS-Federation doesn't have anything comparable to an artifactt so there is no need to exclude it).
Although not stated in the document, the presumed goal of constraining both ID-FF and WS-Federation in this manner is to align the two of them into the same message exchange pattern (MEP), specifically one in which service provider and identity provider communicate with each other 'through' the browser using HTML form posts. I guess the thought is that by converging on this MEP, either provider can easily swap in or out either protocol, differing as they are only by XML syntax.
This seems a new twist on enabling interopability through constraint as practised by WS-I.org (perhaps why this work was not done within that organization?). In WS-I, groups of complementary standards are constrained as a group so that the end result is a consistent and interoperable combination.
The 'interoperability profile' of Sun and Microsoft seems a different beast. In it, two equivalent SSO suites (varying along the standards body ratification scale) are individually constrained to bring each into alignment with a common pattern. This is a different type of interopability, in no sense could it be said that ID-FF and WS-Federation 'work together' as do SOAP and WSDL in the WS-I Basic profile. Rather, by aligning with this common pattern, what is being enabled is the ability for providers to easily switch (even at run time) between both suites.
As 'meta' seems to be enjoying a resurgence in popularity lately, let's call this type of interoperability 'meta-interoperability'.
Maybe the 'interoperability profile' will even eventually be submitted to MWS-I.org?
The profile specifies that, to be compliant, you MUST only use the Liberty ID-FF Browser POST Profile - the other profiles (e.g. artifact based) are excluded. WS-Federation is similarly constrained (although WS-Federation doesn't have anything comparable to an artifactt so there is no need to exclude it).
Although not stated in the document, the presumed goal of constraining both ID-FF and WS-Federation in this manner is to align the two of them into the same message exchange pattern (MEP), specifically one in which service provider and identity provider communicate with each other 'through' the browser using HTML form posts. I guess the thought is that by converging on this MEP, either provider can easily swap in or out either protocol, differing as they are only by XML syntax.
This seems a new twist on enabling interopability through constraint as practised by WS-I.org (perhaps why this work was not done within that organization?). In WS-I, groups of complementary standards are constrained as a group so that the end result is a consistent and interoperable combination.
The 'interoperability profile' of Sun and Microsoft seems a different beast. In it, two equivalent SSO suites (varying along the standards body ratification scale) are individually constrained to bring each into alignment with a common pattern. This is a different type of interopability, in no sense could it be said that ID-FF and WS-Federation 'work together' as do SOAP and WSDL in the WS-I Basic profile. Rather, by aligning with this common pattern, what is being enabled is the ability for providers to easily switch (even at run time) between both suites.
As 'meta' seems to be enjoying a resurgence in popularity lately, let's call this type of interoperability 'meta-interoperability'.
Maybe the 'interoperability profile' will even eventually be submitted to MWS-I.org?
Thursday, May 19, 2005
WS-KindofInteresting
Sun and Microsoft recently announced some fruits of their relationship in the identity management and web services space, the wonderfully named WSSOMEP (I think they missed out on the chance to call it SOME (Sign On Metadata Exchange))
WSSOMEP defines how WS-MetadataExchange can be used to determine which Single Sign-On protocol suites (SAML 1.1, ID-FF 1.2, SAML 2.0, WS-Federation, etc) your partner is capable of supporting so that the two of you can actually do something interesting (like enabling SSO for your customers, employees, etc).
WS-MetadataExchange defines a SOAP-based request/response protocol. Fundamentally, one provider says to the other 'tell me what you can do'. If the returned list includes something that the asking provider can also 'so', then we have an intersection of capabilities and we're off to the races. If no intersection, no way forward.
Once you work out the intersection, obviously you don't forget it the next time you want to do SSO so this mechanism is a one time deal between provider pairs (maybe you'd ask for an update occasionally to make sure you aren't falling behind the technology curve)
So this is one way to address the 'what can the other guy do' issue. There are others. Here is my list:
ask the other guy (WSSOMEP model)
look it up (metadata file at well-known location)
ask somebody else (UDDI)
trial and error, e.g. use one of the suites and, if it works, fine. If not, glean something from the error message
What others are there?
For Liberty's ID-Web Services Framework, the Web Services Consumer (WSC) is able to discover versioning support of its eventual partner Web Services Provider (WSP) by interacting with the Discovery Service. The knowledge it gains about the capabilities of the WSP is implicit however, it never explicitly asks the question 'what can the other guy do' but rather 'give me everything I need in order to talk to the other guy'. The 'everything I need' includes the required versioning info.
WSSOMEP defines how WS-MetadataExchange can be used to determine which Single Sign-On protocol suites (SAML 1.1, ID-FF 1.2, SAML 2.0, WS-Federation, etc) your partner is capable of supporting so that the two of you can actually do something interesting (like enabling SSO for your customers, employees, etc).
WS-MetadataExchange defines a SOAP-based request/response protocol. Fundamentally, one provider says to the other 'tell me what you can do'. If the returned list includes something that the asking provider can also 'so', then we have an intersection of capabilities and we're off to the races. If no intersection, no way forward.
Once you work out the intersection, obviously you don't forget it the next time you want to do SSO so this mechanism is a one time deal between provider pairs (maybe you'd ask for an update occasionally to make sure you aren't falling behind the technology curve)
So this is one way to address the 'what can the other guy do' issue. There are others. Here is my list:
What others are there?
For Liberty's ID-Web Services Framework, the Web Services Consumer (WSC) is able to discover versioning support of its eventual partner Web Services Provider (WSP) by interacting with the Discovery Service. The knowledge it gains about the capabilities of the WSP is implicit however, it never explicitly asks the question 'what can the other guy do' but rather 'give me everything I need in order to talk to the other guy'. The 'everything I need' includes the required versioning info.
Monday, May 02, 2005
All roads lead to Rome
The Romans built a large network of roads in Britain. These roads, as in other parts of the Empire, were very important in maintaining both its stability and expansion.
The roads were built to a standard pattern that ensured they were sturdy and stable - able to withstand the pounding of the feet of the centurions that used them.
When building for military use, the roads were typically built as straight as possible to connect the garrisons and towns, sometimes resulting in grades that were impractical for mercantile use. Civil routes tended more to follow the contours of the land in order to link farms and estates to their markets - thereby ensuring more manageable grades that carts and wagons could deal with.
I can imagine the military engineers sitting in a dark, smoke-filled tent, laying out the route for their roads. There is a hill in the way, no problem, we'll go straight over it, our soliders can handle it. There is already a road there, doesn't matter, we need a new one. Once they came up with a plan (sometimes this took much longer than you might have expected), they presented it to the community for feedback (as the farmers wold use the road as well). The community's thoughts on brick colour, flower planting, etc would have been listened to closely.
The civil engineers on the other hand, would have met in bright sunny open town squares to do their designing. They talked to the townspeople about what features (e.g. maximum grade, curbs, extra width, etc) were needed for the road and where it would be best laid out. Only after this did they then look at the map and work out how to meet this requirements given the restrictions of the terrain and map. If there were existing roads that could be leveraged, do so. Why build another?
I don't really believe either of these two extremes happened (or happens) but the analogy just seemed to perfect to pass up. :-)
The roads were built to a standard pattern that ensured they were sturdy and stable - able to withstand the pounding of the feet of the centurions that used them.
When building for military use, the roads were typically built as straight as possible to connect the garrisons and towns, sometimes resulting in grades that were impractical for mercantile use. Civil routes tended more to follow the contours of the land in order to link farms and estates to their markets - thereby ensuring more manageable grades that carts and wagons could deal with.
I can imagine the military engineers sitting in a dark, smoke-filled tent, laying out the route for their roads. There is a hill in the way, no problem, we'll go straight over it, our soliders can handle it. There is already a road there, doesn't matter, we need a new one. Once they came up with a plan (sometimes this took much longer than you might have expected), they presented it to the community for feedback (as the farmers wold use the road as well). The community's thoughts on brick colour, flower planting, etc would have been listened to closely.
The civil engineers on the other hand, would have met in bright sunny open town squares to do their designing. They talked to the townspeople about what features (e.g. maximum grade, curbs, extra width, etc) were needed for the road and where it would be best laid out. Only after this did they then look at the map and work out how to meet this requirements given the restrictions of the terrain and map. If there were existing roads that could be leveraged, do so. Why build another?
I don't really believe either of these two extremes happened (or happens) but the analogy just seemed to perfect to pass up. :-)
Subscribe to:
Posts (Atom)