Comments on: Silo Sync vs. Service Sync http://eternallyoptimistic.com/2009/02/08/silo-sync-vs-service-sync/ Fri, 29 Jan 2010 22:51:53 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: bradturner32 http://eternallyoptimistic.com/2009/02/08/silo-sync-vs-service-sync/comment-page-1/#comment-501 bradturner32 Mon, 09 Feb 2009 15:06:49 +0000 http://eternallyoptimistic.com/?p=901#comment-501 Speaking from the view of one who deals with the replication of information between silo's I couldn't agree more. This is a legacy way of thinking based on current AuthN processes. There is no reason why the concept of AuthN/AuthZ will not/should not evolve such that valid identities are synchronized or provisioned on demand. However, this does bring up the subject of abuse as it would potentially expose a new attack surface if the appropriate controls are not in place. If I have the ability to flood the request channel with bad AuthN requests then I could compromise the channel between the RP and the IdP as the RP faithfully attempts to check for object that require on demand provisioning. Speaking from the view of one who deals with the replication of information between silo’s I couldn’t agree more. This is a legacy way of thinking based on current AuthN processes. There is no reason why the concept of AuthN/AuthZ will not/should not evolve such that valid identities are synchronized or provisioned on demand. However, this does bring up the subject of abuse as it would potentially expose a new attack surface if the appropriate controls are not in place. If I have the ability to flood the request channel with bad AuthN requests then I could compromise the channel between the RP and the IdP as the RP faithfully attempts to check for object that require on demand provisioning.

]]> By: Leon http://eternallyoptimistic.com/2009/02/08/silo-sync-vs-service-sync/comment-page-1/#comment-500 Leon Sun, 08 Feb 2009 22:41:56 +0000 http://eternallyoptimistic.com/?p=901#comment-500 The whole thing about federated identity: one should keep 'context' in mind. The user *doesn't authenticate* to the relaying party. The relying party get's proof of 'authenticated identity'. So in the context of the relying party there really never is a "first authentication". With that in mind your example works well. And is, afaik, in accordance with european privacy law. The whole thing about federated identity: one should keep ‘context’ in mind. The user *doesn’t authenticate* to the relaying party. The relying party get’s proof of ‘authenticated identity’. So in the context of the relying party there really never is a “first authentication”.

With that in mind your example works well. And is, afaik, in accordance with european privacy law.

]]>