Interoperability between A and B is simplest when there exists only a single mechanism by which the two can achieve X.
In the SSO world, that ship has sailed. There are multiple technologies that 'do' SSO.
Next in line in complexity would be a world where multiple mechanisms for X exist, but A or B (or C etc) will only ever use a particular choice. So A only ever uses X', B uses X'' and so forth. In such a world, you end up with distinct islands - constituents of each can talk amongst each other but not with anybody from 'across the water'.
That this is no longer (if it ever was) the case for SSO is hilited by Sun's announcement yesterday of support for OpenID. Sun will use OpenID's protocols for employee SSO to some relying parties, and will use SAML for enabling SSO to other relying parties.
The Sun scenario is one in which, while a particular entity A may use either X' or X'', they'll only ever use X' (or X'') with particular partners. So, A uses X' with B and uses X'' with C, etc.
In this scenario providers have to remember which SSO protocol to use with each possible partner - the 'right' one likely previously agreed upon between the two.
More complex yet is where some entity A uses either X' or X'' based on the application context, and not on the identity of the other provider. So, A might use SAML for SSO with B for app 1, and use OpenID with B for app 2.
Most complex is a situation in which the choice of a SSO protocol is not pre-determined by either provider identity or particular application context, but dynamically established by the two providers at run-time. This would imply that the two parters had means to
- determine the SSO protocol capabilities of the other
- indicate their own SSO protocol preferences
- negotiate/select within the available mechanisms
- fault out in case of failure
How will this work in the SSO world? What combination of Yadis, SAML Metadata, etc would enable this?
Tags:
No comments:
Post a Comment