http://blog.talkingidentity.com/2009/02/more_things_about_federated_pr.html An Architect's Quest to make sense of the world of Identity and Access Management Thu, 01 Sep 2011 20:45:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 http://blog.talkingidentity.com/2009/02/more_things_about_federated_pr.html/comment-page-1#comment-225 My GlueCon Talk on “Federated Provisioning and the Cloud” – Talking Identity | Nishant Kaushik's Look at the World of Identity Management Tue, 01 Jun 2010 20:43:04 +0000 http://talkingidentity.com/blog/?p=140#comment-225 [...] be light-touch and loosely coupled, and it has to just work (at scale). In a previous set of blog posts, triggered by Ian’s famous “There is no such thing as Federated Provisioning” [...] [...] be light-touch and loosely coupled, and it has to just work (at scale). In a previous set of blog posts, triggered by Ian’s famous “There is no such thing as Federated Provisioning” [...]

]]> http://blog.talkingidentity.com/2009/02/more_things_about_federated_pr.html/comment-page-1#comment-205 warwickmetcalfe Fri, 19 Mar 2010 15:05:19 +0000 http://talkingidentity.com/blog/?p=140#comment-205 I have been working since 1998 on "agreement driven provisioning" models that have been around in the telco space for a long time, this is to say that agreement lifecycles - the legal binding of relationships for a finite period of time make a good common agreed place for federation systems to sync - especialy in terms of de-provisioning / re-provisioning in sync with the agreement lifecycle I have been working since 1998 on “agreement driven provisioning” models that have been around in the telco space for a long time, this is to say that agreement lifecycles – the legal binding of relationships for a finite period of time make a good common agreed place for federation systems to sync – especialy in terms of de-provisioning / re-provisioning in sync with the agreement lifecycle

]]> http://blog.talkingidentity.com/2009/02/more_things_about_federated_pr.html/comment-page-1#comment-119 Frank Villavicencio Tue, 14 Apr 2009 22:28:42 +0000 http://talkingidentity.com/blog/?p=140#comment-119 Nishant: A comment on the federated provisioning discussion that might be relevant... beyond the technical approach is also de SLA, and come to think about it, the liability implications. As you rightfully stated, for the most part federation hinges, in a practical way in local accounts at the RP being created and linked to the federated identity, which, if left dormant might create a potential thread. In my view this has a few implications, such as 1) the obvious one that you pointed out: dormant accounts can be exploited albeit through backdoor channels -- that's a strong reason to deal with them; 2) they used up digital space in systems and also in themselves, they represent a potential asset that could be exploited/abused, thus opening up potential privacy issues, simply on the data that the record itself is made up; 3) As someone pointed out, in SaaS environments, organizations are often charged based on the number of users from their end that are registered for the application, so there is a cost implication (not to say that simply keeping data around wouldn't in itself represent a cost), but this may also have liability implications to either the RP or the IdP, in the event that any of the above situations occurred, who is responsible for the potential damage caused? Is there an SLA or a clause somewhere that specifies how this is to be dealt with when things do go wrong? I propose that these elements, which are part of a federated identity network be addressed up front as the federation itself is being established, such that parties know what their responsibilities and liabilities are in the exchanges. It is appropriate to refer to Bob Blakley?s work on relationships at this point, which to me is the basis for how trustworthy federation will take place. If you come to think about it, an effective way to ensure that accounts are terminated in a relatively timely fashion is to see that one of the parties, RP or IdP see an incentive in keeping the relationship up-to-date, and provided that they have the practical means to do so, there is a much higher chance that they will. Another relevant observation comes from the world of identity assurance ? if identity assurance is a continuum, a watermark so to say, over time, and particularly in a federated network, it will tend to decay over time unless it is refreshed and updated. This is why in many federated networks (particularly those that have a heavy heritage from PKI), the elements of expiration and renewal are so critical. This is a mechanism by which parties have a worst case metric for containing the level of decay (smells funny, doesn?t it?) of federated identities. Nishant:
A comment on the federated provisioning discussion that might be relevant… beyond the technical approach is also de SLA, and come to think about it, the liability implications. As you rightfully stated, for the most part federation hinges, in a practical way in local accounts at the RP being created and linked to the federated identity, which, if left dormant might create a potential thread. In my view this has a few implications, such as 1) the obvious one that you pointed out: dormant accounts can be exploited albeit through backdoor channels — that’s a strong reason to deal with them; 2) they used up digital space in systems and also in themselves, they represent a potential asset that could be exploited/abused, thus opening up potential privacy issues, simply on the data that the record itself is made up; 3) As someone pointed out, in SaaS environments, organizations are often charged based on the number of users from their end that are registered for the application, so there is a cost implication (not to say that simply keeping data around wouldn’t in itself represent a cost), but this may also have liability implications to either the RP or the IdP, in the event that any of the above situations occurred, who is responsible for the potential damage caused? Is there an SLA or a clause somewhere that specifies how this is to be dealt with when things do go wrong? I propose that these elements, which are part of a federated identity network be addressed up front as the federation itself is being established, such that parties know what their responsibilities and liabilities are in the exchanges.
It is appropriate to refer to Bob Blakley?s work on relationships at this point, which to me is the basis for how trustworthy federation will take place. If you come to think about it, an effective way to ensure that accounts are terminated in a relatively timely fashion is to see that one of the parties, RP or IdP see an incentive in keeping the relationship up-to-date, and provided that they have the practical means to do so, there is a much higher chance that they will.
Another relevant observation comes from the world of identity assurance ?
if identity assurance is a continuum, a watermark so to say, over time, and particularly in a federated network, it will tend to decay over time unless it is refreshed and updated. This is why in many federated networks (particularly those that have a heavy heritage from PKI), the elements of expiration and renewal are so critical. This is a mechanism by which parties have a worst case metric for containing the level of decay (smells funny, doesn?t it?) of federated identities.

]]> http://blog.talkingidentity.com/2009/02/more_things_about_federated_pr.html/comment-page-1#comment-115 Deborah Volk Fri, 13 Mar 2009 20:56:10 +0000 http://talkingidentity.com/blog/?p=140#comment-115 Hi Nishant, I was wondering about the business side of this equation, namely how many companies provision to SaaS apps today. Granted, not all SaaS apps are created equal and some don't even have a interface for provisioning but... I created a poll on LinkedIn at <a href="http://polls.linkedin.com/p/26723/ojkhm" rel="nofollow">http://polls.linkedin.com/p/26723/ojkhm</a> to capture results. We've got a blog now but it doesn't have RSS just yet. Stop by and say hello! Hi Nishant,
I was wondering about the business side of this equation, namely how many companies provision to SaaS apps today. Granted, not all SaaS apps are created equal and some don’t even have a interface for provisioning but… I created a poll on LinkedIn at http://polls.linkedin.com/p/26723/ojkhm to capture results.
We’ve got a blog now but it doesn’t have RSS just yet. Stop by and say hello!

]]>