Völlig korrekt: E-SSO ist zwar ein taktischer Lösungsansatz, aber man wird ihn auf absehbare Zeit als Ergänzung brauchen. Dazu gehört immer auch eine starke Authentifizierung - als "versatile" und kontext-abhängig implementiert. Konkret: Es geht nicht um einen mehr oder weniger starken Mechanismus, der immer genutzt wird, sondern um flexible Lösungsansätze, mit denen für unterschiedliche Nutzergruppen (man denke intern an den Bereich F+E oder das Top-Management, extern an Kunden, verschiedene Arten von Partnern mit unterschiedlichem "Integrationsgrad",...) und Nutzungssituationen (im Unternehmen, mobil, unterschiedliche Devices,...) die für die durchgeführte Interaktion respektive Transaktion jeweils angemessene Authentifizierung gefordert wird.
Nicht überschätzen sollte man den Implementierungsaufwand für Federation - das Thema lässt sich mit durchaus überschaubarem Aufwand umsetzen. Klar ist E-SSO einfacher zu implementieren, aber in seiner Reichweite auch begrenzt als interner Ansatz. Federation geht deutlich weiter. Deshalb sollte man immer auch hinterfragen, ob Federation als der strategisch wichtigste Ansatz nicht eine machbare Alternative ist, wenn man in andere der genannten Ansätze investieren will.

It is not about having multiple directories with different schemas and different hierarchies on one server. That is not the point, obviously. The point is that within one directory I have one schema. Within this schema, I have one hierarchy (which again is obvious when looking at the concepts of LDAP, the DNs, and so on). Thus based on the same set of data I end up with some inflexibility. I can for sure use Virtual Directory Services on top to create different hierarchical views but that is just a workaround.
Thus it is not about whether an RFC is implemented correctly (I assume that M$ is a biased abbreviation for Microsoft). It is also not about LDAP being broken, but LDAP being limited. By the way: For sure I know not only Microsoft Active Directory but many other directory services.
Aliases are not sufficient. That is again very obvious to any practicioner, because it is an inefficient workaround. Thus there is the obvious need to rethink this issue.
I\'m pretty sure that I\'ve got some of the points (which were examples). And just because the new concept has been developed by someone from Microsoft it is not necessarily bad. The real bad thing, from my perspective, is being narrowminded.

Hi Matt,
I don't think that we can limit PAM to routers, firewalls and other devices with frequently very weak security concepts. For sure, an advanced support for federation as well as for authorization standards (which are still immature) will help. But PAM as well addresses the operating system level, databases and other types of systems. I personally expect that PAM will become more and more part of core IAM solutions (e.g. Provisioning) and will be integrated in these lifecycle management approaches. But specific features for PAM will be required as well in the future - and even when ancient concepts like "root" are replaced by better approaches perhaps sometimes in the future. The question isn't whether we will need PAM features or not - we will, even while some threats (firewall admins,...) might disappear. The question is whether there will be a separate PAM market segment or an integration into other solutions. I think that there will be both - standalone, sometimes specialized (UNIX/Linux only,...) solutions and integrated approaches.
Martin