I just sent this to Hendrik:
Hendrik,
From your response I see that you can envision some of the use cases.
We are building a 20,000+ user (300 partner organizations) Extranet with AD FS 2.0, FIM, SharePoint 2010, and UAG (federated logon and claims to Kerberos). We have many legacy applications (IIS and Tomcat) that we will protect using the Shibboleth SAML 2.0 SP agents (relying parties to ADFS). Some of these legacy applications query databases and LDAP stores for user roles and entitlements. We require this "user profile" due to the large number of applications we provide and the resulting permutations and combinations of entitlements that are too difficult to map to roles at this time.
It would be great if your FIM AD FS 2.0 Attribute Store could be called in the claims language to check for a matching identity, and if not existent, to create the base identity. This identity could include identity attributes from inbound claims and could even use roles and groups from those claims for Role Based provisioning. The web services call would create the user and then the FIM MPRs, workflows and synchronization rules would take care of the rest. You could then set a claim to indicate that the user was just provisioned.
From here you could then:
* Access legacy apps that require the backend identities.
* Access FIM (via the portal or a custom UI) and request access to other resources.
* An administrator could access FIM and add entitlements without having to create the base identity.
* Access a Citrix App that requires a Windows identity.
I see many SaaS applications/providers that support federation, but still require directory exports or LDAP access to provision identities in their systems. This would address that and negate that requirement.
I look forward to seeing where you go with this. I like what you have done, but for read access we will probably continue to use an LDS attribute store (provisioned from FIM), due to high-availability, DR, and geographic redundancy.
BTW, Ping Federate includes a function to provision users (shadow accounts) in an LDAP store during federate logon (if they don't already exist).
Thanks,
David
________________________________
From: tomaszon [email removed]
Sent: December-15-10 11:56 AM
To: David Adshade
Subject: Re: Please! Give us feedback! [FIMAttributeStore:237487]
From: tomaszon
Hi,
Henrik asked me about opinion on this one on private e-mail thread, and then asked me to post my answer here :) ... so here it is, just for your discussion.
(...)
So we are coming to a topic of dynamic provisioning of information required to access a service. This is of course something you want to resolve in one way or another when you are using for example services hosted in a cloud (whatever this cloud thing is ;)). I will think a bit longer what do I think about it :) ).
From systems architecture perspective I don't know if this is a right place to implement such process. If I would think about what to give a people in this area from such provider, I'm thinking more about asynchronous exit module, where at the end of claims processing information about the user is passed and one can handle this with its own library - something like extensibility model in your provider :). There one would be able to implement whatever they will want to ... even such form of dynamic provisioning. Or start a request in FIM for some resource access ... or ... just think about scenario.
Of course this rises some issues;
- if this box will be under heavy load such exit module method may not scale very well or at least give this box an additional load
- to make it safe for main module as I wrote above it should be executed asynchronously and probably out of main process, so there is no guarantee that this profile will be there anyway when user will arrive
- few more I can think of :).
In general I believe that if application requires some form of profile, and is being adjusted or written to handle claims based authentication it should implement such process like initial, dynamic profile population on its own. It gets claims for the first time and bum ... profile is being provisioned. Separating this to mechanism like this means that if profile definition will change you have to change also external code (to application) which creates such profiles.
So best solution is to have it in an application. If it isn't there - such exit module for your attribute store might be some sort of solution, but it looks more like a patch to a plumbing than a solid architecture solution. If I would think about something like this I would think about issuing FIM request to assign such resource \ profile to this person and at application side, until this won't be provisioned, handling user with some sort of temporary profile.
Just quick thoughts over morning coffee - maybe I'm wrong on this. I will read it again in the evening and maybe I will have some other ideas :)
But good that the discussion is going on :), it means that this is being used or people see use for it.
(...)
--
Tomasz Onyszko | Connected Dots
[email removed] | http://www.cdots.pl
Blog (EN): http://blogs.dirteam.com/blogs/tomek/
Blog (PL): http://www.w2k.pl
Read the full discussion online<http://fimattributestore.codeplex.com/Thread/View.aspx?ThreadId=237487&ANCHOR#Post536314>.
To add a post to this discussion, reply to this email ([email removed]<mailto:[email removed]?subject=[FIMAttributeStore:237487]>)
To start a new discussion for this project, email [email removed]<mailto:[email removed]>
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe<https://fimattributestore.codeplex.com/discussions/237487/unsubscribe/> on CodePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com
Hendrik,
From your response I see that you can envision some of the use cases.
We are building a 20,000+ user (300 partner organizations) Extranet with AD FS 2.0, FIM, SharePoint 2010, and UAG (federated logon and claims to Kerberos). We have many legacy applications (IIS and Tomcat) that we will protect using the Shibboleth SAML 2.0 SP agents (relying parties to ADFS). Some of these legacy applications query databases and LDAP stores for user roles and entitlements. We require this "user profile" due to the large number of applications we provide and the resulting permutations and combinations of entitlements that are too difficult to map to roles at this time.
It would be great if your FIM AD FS 2.0 Attribute Store could be called in the claims language to check for a matching identity, and if not existent, to create the base identity. This identity could include identity attributes from inbound claims and could even use roles and groups from those claims for Role Based provisioning. The web services call would create the user and then the FIM MPRs, workflows and synchronization rules would take care of the rest. You could then set a claim to indicate that the user was just provisioned.
From here you could then:
* Access legacy apps that require the backend identities.
* Access FIM (via the portal or a custom UI) and request access to other resources.
* An administrator could access FIM and add entitlements without having to create the base identity.
* Access a Citrix App that requires a Windows identity.
I see many SaaS applications/providers that support federation, but still require directory exports or LDAP access to provision identities in their systems. This would address that and negate that requirement.
I look forward to seeing where you go with this. I like what you have done, but for read access we will probably continue to use an LDS attribute store (provisioned from FIM), due to high-availability, DR, and geographic redundancy.
BTW, Ping Federate includes a function to provision users (shadow accounts) in an LDAP store during federate logon (if they don't already exist).
Thanks,
David
________________________________
From: tomaszon [email removed]
Sent: December-15-10 11:56 AM
To: David Adshade
Subject: Re: Please! Give us feedback! [FIMAttributeStore:237487]
From: tomaszon
Hi,
Henrik asked me about opinion on this one on private e-mail thread, and then asked me to post my answer here :) ... so here it is, just for your discussion.
(...)
So we are coming to a topic of dynamic provisioning of information required to access a service. This is of course something you want to resolve in one way or another when you are using for example services hosted in a cloud (whatever this cloud thing is ;)). I will think a bit longer what do I think about it :) ).
From systems architecture perspective I don't know if this is a right place to implement such process. If I would think about what to give a people in this area from such provider, I'm thinking more about asynchronous exit module, where at the end of claims processing information about the user is passed and one can handle this with its own library - something like extensibility model in your provider :). There one would be able to implement whatever they will want to ... even such form of dynamic provisioning. Or start a request in FIM for some resource access ... or ... just think about scenario.
Of course this rises some issues;
- if this box will be under heavy load such exit module method may not scale very well or at least give this box an additional load
- to make it safe for main module as I wrote above it should be executed asynchronously and probably out of main process, so there is no guarantee that this profile will be there anyway when user will arrive
- few more I can think of :).
In general I believe that if application requires some form of profile, and is being adjusted or written to handle claims based authentication it should implement such process like initial, dynamic profile population on its own. It gets claims for the first time and bum ... profile is being provisioned. Separating this to mechanism like this means that if profile definition will change you have to change also external code (to application) which creates such profiles.
So best solution is to have it in an application. If it isn't there - such exit module for your attribute store might be some sort of solution, but it looks more like a patch to a plumbing than a solid architecture solution. If I would think about something like this I would think about issuing FIM request to assign such resource \ profile to this person and at application side, until this won't be provisioned, handling user with some sort of temporary profile.
Just quick thoughts over morning coffee - maybe I'm wrong on this. I will read it again in the evening and maybe I will have some other ideas :)
But good that the discussion is going on :), it means that this is being used or people see use for it.
(...)
--
Tomasz Onyszko | Connected Dots
[email removed] | http://www.cdots.pl
Blog (EN): http://blogs.dirteam.com/blogs/tomek/
Blog (PL): http://www.w2k.pl
Read the full discussion online<http://fimattributestore.codeplex.com/Thread/View.aspx?ThreadId=237487&ANCHOR#Post536314>.
To add a post to this discussion, reply to this email ([email removed]<mailto:[email removed]?subject=[FIMAttributeStore:237487]>)
To start a new discussion for this project, email [email removed]<mailto:[email removed]>
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe<https://fimattributestore.codeplex.com/discussions/237487/unsubscribe/> on CodePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com