Comments on: The Thing about Federated Provisioning http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.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 By: My GlueCon Talk on “Federated Provisioning and the Cloud” – Talking Identity | Nishant Kaushik's Look at the World of Identity Management http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-226 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:44:08 +0000 http://talkingidentity.com/blog/?p=139#comment-226 [...] famous “There is no such thing as Federated Provisioning” post, I brought out that there are two kinds of federated provisioning – Advance Provisioning and Just-In-Time [...] [...] famous “There is no such thing as Federated Provisioning” post, I brought out that there are two kinds of federated provisioning – Advance Provisioning and Just-In-Time [...]

]]> By: NishantKaushik http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-215 NishantKaushik Tue, 11 May 2010 15:31:00 +0000 http://talkingidentity.com/blog/?p=139#comment-215 Nice looking demo there. Nice looking demo there.

]]> By: Bob http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-214 Bob Tue, 11 May 2010 14:11:12 +0000 http://talkingidentity.com/blog/?p=139#comment-214 Great minds think alike - <a href="http://www.bobbobel.com/just-in-time-access-provisioning/" rel="nofollow">http://www.bobbobel.com/just-in-time-access-pro...</a> Great minds think alike – http://www.bobbobel.com/just-in-time-access-pro…

]]> By: Clark Sanford http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-174 Clark Sanford Thu, 26 Nov 2009 02:45:14 +0000 http://talkingidentity.com/blog/?p=139#comment-174 This is an interesting topic and I can tell you I encountered this numerous times several years ago when I worked for Ping Identity. Its funny because I remember having conversations describing exactly these two "federated provisioning" scenarios, based on customer requests, the overwhelming majority of which wanted the lightweight Just-In-Time variant (I used the JIT terminology, too). We didn't resolve the issue completely while I was there but it was possible to configure a redirect to a URL for a registration page as a work around. I agree that a standardized "hook" - a SAML JIT provisioning profile, perhaps - would be welcome by many Service Providers.<br><br>I've actually wondered why the Assertion Query profile couldn't be implemented to satisfy the situation where the provisioning process requires more attributes/claims than the original SSO Assertion carries (I agree these assertions should contain a limited subset of attribute statements - you want to see a horrifically bloated SAML Assertion structure? Try implementing the US DoJ's GFIPM extension!)<br><br>The JIT concept isn't full-blown provisioning (i.e., no formal mechanism for de-provisioning, etc.) but that's kind of the idea. This is an interesting topic and I can tell you I encountered this numerous times several years ago when I worked for Ping Identity. Its funny because I remember having conversations describing exactly these two “federated provisioning” scenarios, based on customer requests, the overwhelming majority of which wanted the lightweight Just-In-Time variant (I used the JIT terminology, too). We didn't resolve the issue completely while I was there but it was possible to configure a redirect to a URL for a registration page as a work around. I agree that a standardized “hook” – a SAML JIT provisioning profile, perhaps – would be welcome by many Service Providers.

I've actually wondered why the Assertion Query profile couldn't be implemented to satisfy the situation where the provisioning process requires more attributes/claims than the original SSO Assertion carries (I agree these assertions should contain a limited subset of attribute statements – you want to see a horrifically bloated SAML Assertion structure? Try implementing the US DoJ's GFIPM extension!)

The JIT concept isn't full-blown provisioning (i.e., no formal mechanism for de-provisioning, etc.) but that's kind of the idea.

]]> By: Can OAuth do what SPML hasn’t? – Talking Identity http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-172 Can OAuth do what SPML hasn’t? – Talking Identity Tue, 24 Nov 2009 21:52:13 +0000 http://talkingidentity.com/blog/?p=139#comment-172 [...] in my post “The Thing About Federated Provisioning“, I pointed out that there are challenges in doing all of this just-in-time. Enterprises [...] [...] in my post “The Thing About Federated Provisioning“, I pointed out that there are challenges in doing all of this just-in-time. Enterprises [...]

]]> By: Pat Patterson http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-114 Pat Patterson Sat, 14 Feb 2009 18:20:28 +0000 http://talkingidentity.com/blog/?p=139#comment-114 Hi Nishant - <a href="http://blogs.sun.com/superpat/entry/federated_provisioning_liberty_to_the" rel="nofollow">here's one approach to scenario #2</a>. Hi Nishant – here’s one approach to scenario #2.

]]> By: Mat Hamlin http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-113 Mat Hamlin Wed, 04 Feb 2009 20:49:01 +0000 http://talkingidentity.com/blog/?p=139#comment-113 Nishant, I know of multiple instances similar to what you have described in scenario #1, and at least one where SPML is used to seed the identity information to the federated partner. (I'm sure there are more) I agree with some of the comments that the JIT scenario can be accomplished (and is on the Internet) with OpenID, but in most cases where I personally have used OpenID, the SP, directs me through a create process and gathers more information about me prior to final "provisioning." For the enterprise space, it is likely that the data and process for creating accounts at Omega will reside within the walls of Acme, and possibly additional processes (like approvals) reside within Omega. For these situations, I see two options: 1. As you presented, creating a "... standards-based interaction between the federation server and the provisioning server", thereby allowing Omega to initiate their provisioning process upon federation request. (assuming completed or non-existent provisioning processes at Acme) 2. Recognition of attempted access to Omega by Acme services followed by provisioning to Omega via the Acme provisioning server. This could be all programmatic, or manual where the user is redirected to the Acme provisioning server interface to complete the Acme to Omega provisioning process. ...and it could all be synchronous with final redirects to Omega, or asynchronous with a notification to the user when access is available. Nishant,
I know of multiple instances similar to what you have described in scenario #1, and at least one where SPML is used to seed the identity information to the federated partner. (I’m sure there are more)
I agree with some of the comments that the JIT scenario can be accomplished (and is on the Internet) with OpenID, but in most cases where I personally have used OpenID, the SP, directs me through a create process and gathers more information about me prior to final “provisioning.”
For the enterprise space, it is likely that the data and process for creating accounts at Omega will reside within the walls of Acme, and possibly additional processes (like approvals) reside within Omega.
For these situations, I see two options:
1. As you presented, creating a “… standards-based interaction between the federation server and the provisioning server”, thereby allowing Omega to initiate their provisioning process upon federation request. (assuming completed or non-existent provisioning processes at Acme)
2. Recognition of attempted access to Omega by Acme services followed by provisioning to Omega via the Acme provisioning server.
This could be all programmatic, or manual where the user is redirected to the Acme provisioning server interface to complete the Acme to Omega provisioning process. …and it could all be synchronous with final redirects to Omega, or asynchronous with a notification to the user when access is available.

]]> By: Nishant Kaushik http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-112 Nishant Kaushik Wed, 04 Feb 2009 19:36:08 +0000 http://talkingidentity.com/blog/?p=139#comment-112 Karl, Excellent dissection of scenario 2. Really expands on what I meant when I stated "the interaction between the federation server and the provisioning server has to be ... well-defined". It is because of all the reasons you have stated that I say scenario 2 is not like regular provisioning, in that it requires we enhance the SAML/SPML standards to accommodate the special needs you have defined, and also enhance the interaction between the federation servers and the provisioning engines. Karl,
Excellent dissection of scenario 2. Really expands on what I meant when I stated “the interaction between the federation server and the provisioning server has to be … well-defined”. It is because of all the reasons you have stated that I say scenario 2 is not like regular provisioning, in that it requires we enhance the SAML/SPML standards to accommodate the special needs you have defined, and also enhance the interaction between the federation servers and the provisioning engines.

]]> By: Nishant Kaushik http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-111 Nishant Kaushik Wed, 04 Feb 2009 19:30:53 +0000 http://talkingidentity.com/blog/?p=139#comment-111 Johannes, You are right in that scenario 2 is sort-of like the OpenID/CardSpace interactions. But my context is enterprise federations, where there are far more complicated datasets and business policies (like approvals) involved. The OpenID interaction is much simpler due to the nature of internet transactions. Johannes,
You are right in that scenario 2 is sort-of like the OpenID/CardSpace interactions. But my context is enterprise federations, where there are far more complicated datasets and business policies (like approvals) involved. The OpenID interaction is much simpler due to the nature of internet transactions.

]]> By: Karl Miller http://blog.talkingidentity.com/2009/02/the_thing_about_federated_prov.html/comment-page-1#comment-110 Karl Miller Wed, 04 Feb 2009 18:31:24 +0000 http://talkingidentity.com/blog/?p=139#comment-110 SAML-based federated SSO exists as an authentication token, not authorization, and not as a global record transmission and relay technology. The entire concept of federation is to pass enough information to create the new session in the service provider's environment. That may mean a 1:1 mapping or an N:1 mapping. If the mapping does not exist, this is where people have decided "well, if it doesn't exist, create it!" And this has some risks associated with it that should be carefully considered. If we want to engage in "Federated Provisioning", it becomes necessary to modify the basic exchanges of the SAML messages to trap a "user not found / failed user mapping" event to initiate some provisioning event. In environments that want to look at Federated Provisioning, I frequently hear "just pull the information you need to create the user from the SAML assertion and create them." Here's where we start to see the bad idea. The SAML assertion should contain the MINIMUM information for moving the session from the IdP to the SP. If we instead send a full payload of data needed by the SP, we're likely transmitting FAR more information that would be advisable (recall that the first steps taken by Liberty and embraced in SAML 2.0 are opaque identifiers to further remove personal information from the exchange in order to provide better security because of the risks of misuse and replay.) Also, this means that the SP would have to expose sufficient information about what their business requires to the IdP, or build the business logic and dependencies into the federation processing. Neither is a very good idea. Next, if we have opted to transmit the entire record payload from the IdP to the SP (and violated some very good security practices), modified the SAML exchange to add our provisioning process as an in-sequence requirement to federation, and created a new record with all the required data, we must now re-use the original assertion to create the user federation record. At worst, this means we're reusing what should be a short-lifetime SAML assertion to create a session. At best, we've degraded the performance of the federation exchange and mapping to add all the overhead for the provisioning process (including performance of all back-end servers in the provisioning process), and removed the value of any caching the provisioning server was using against the user repository (since we first looked and the record did not exist, so we created one, looked again and found the new record, we've got either a small or no cache.) If we instead extend the SAML exchange for federation as a standard to allow a hook for provisioning as an option, with methods to notify the providers, then it may make sense to create 'Federated Provisioning'. Without that type of alteration, injecting the provisioning process should be an option that is implemented cautiously on a case-by-case basis at deployments. If the organizations involved in a federated exchange have no prior negotiation for the user mappings, they probably should reconsider their federation agreement and examine their security practice for exchanging security for adminsitrative ease. SAML-based federated SSO exists as an authentication token, not authorization, and not as a global record transmission and relay technology. The entire concept of federation is to pass enough information to create the new session in the service provider’s environment. That may mean a 1:1 mapping or an N:1 mapping. If the mapping does not exist, this is where people have decided “well, if it doesn’t exist, create it!” And this has some risks associated with it that should be carefully considered.
If we want to engage in “Federated Provisioning”, it becomes necessary to modify the basic exchanges of the SAML messages to trap a “user not found / failed user mapping” event to initiate some provisioning event. In environments that want to look at Federated Provisioning, I frequently hear “just pull the information you need to create the user from the SAML assertion and create them.” Here’s where we start to see the bad idea. The SAML assertion should contain the MINIMUM information for moving the session from the IdP to the SP.
If we instead send a full payload of data needed by the SP, we’re likely transmitting FAR more information that would be advisable (recall that the first steps taken by Liberty and embraced in SAML 2.0 are opaque identifiers to further remove personal information from the exchange in order to provide better security because of the risks of misuse and replay.) Also, this means that the SP would have to expose sufficient information about what their business requires to the IdP, or build the business logic and dependencies into the federation processing. Neither is a very good idea.
Next, if we have opted to transmit the entire record payload from the IdP to the SP (and violated some very good security practices), modified the SAML exchange to add our provisioning process as an in-sequence requirement to federation, and created a new record with all the required data, we must now re-use the original assertion to create the user federation record. At worst, this means we’re reusing what should be a short-lifetime SAML assertion to create a session. At best, we’ve degraded the performance of the federation exchange and mapping to add all the overhead for the provisioning process (including performance of all back-end servers in the provisioning process), and removed the value of any caching the provisioning server was using against the user repository (since we first looked and the record did not exist, so we created one, looked again and found the new record, we’ve got either a small or no cache.)
If we instead extend the SAML exchange for federation as a standard to allow a hook for provisioning as an option, with methods to notify the providers, then it may make sense to create ‘Federated Provisioning’. Without that type of alteration, injecting the provisioning process should be an option that is implemented cautiously on a case-by-case basis at deployments.
If the organizations involved in a federated exchange have no prior negotiation for the user mappings, they probably should reconsider their federation agreement and examine their security practice for exchanging security for adminsitrative ease.

]]>