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: HenrikNilsson [email removed]
Sent: December-14-10 10:51 PM
To: David Adshade
Subject: Re: Please! Give us feedback! [FIMAttributeStore:237487]
From: HenrikNilsson
Hi David!
I guess you think this idea could come handy if you have a ticket coming from a partner claims provider and there's some kind of user profile requirement that needs to be provisioned into one or more connected directories. I guess this simply could be solved by sending a "provision if missing" flag into the attribute store and a lot more parameters than the single one we use for finding the person resource in FIM. It will also require a bunch of rules in FIM like for example an approval for allowing the creation of a person resource and a notification to the user when the resource have been created and provisioned to the target(s).
Brilliant idea but I would like to know a bit more about your use case?
Read the full discussion online<http://fimattributestore.codeplex.com/Thread/View.aspx?ThreadId=237487&ANCHOR#Post535947>.
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
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: HenrikNilsson [email removed]
Sent: December-14-10 10:51 PM
To: David Adshade
Subject: Re: Please! Give us feedback! [FIMAttributeStore:237487]
From: HenrikNilsson
Hi David!
I guess you think this idea could come handy if you have a ticket coming from a partner claims provider and there's some kind of user profile requirement that needs to be provisioned into one or more connected directories. I guess this simply could be solved by sending a "provision if missing" flag into the attribute store and a lot more parameters than the single one we use for finding the person resource in FIM. It will also require a bunch of rules in FIM like for example an approval for allowing the creation of a person resource and a notification to the user when the resource have been created and provisioned to the target(s).
Brilliant idea but I would like to know a bit more about your use case?
Read the full discussion online<http://fimattributestore.codeplex.com/Thread/View.aspx?ThreadId=237487&ANCHOR#Post535947>.
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