Please! Give us feedback!

Coordinator
Dec 7, 2010 at 5:54 PM
Edited Dec 7, 2010 at 5:54 PM

I'm starting this discussion for collecting input on what you think about ADFS 2.0 Attribute Store for FIM.
Good feedback won't hurt and bad would force us to make  it better!

//Henrik

Dec 14, 2010 at 11:07 PM

Any plans to extend this to do shadow account provisioning?  For example, when a user performs a federated logon from a trusted partner, you query FIM to see if their identity exists.  If the identity does not exist, you use the resource client and one or more attributes from their inbound claims to provision a shadow account in FIM.

I look forward to your reply,

David  

Coordinator
Dec 15, 2010 at 5:51 AM

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?

Dec 15, 2010 at 6:56 PM

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
t.onyszko@cdots.pl | http://www.cdots.pl
Blog (EN): http://blogs.dirteam.com/blogs/tomek/
Blog (PL): http://www.w2k.pl

Coordinator
Dec 15, 2010 at 7:17 PM

Thanks Tomek!

First of all the attribute store is all asynchronous as it's developed today and kicking of another process in a call and forget fashion is no problem at all and I don't think this will put a lot of pressure on the box unless you have thousands of provisioning requests a day.

I've had a strange gut feeling about this idea and I've been trying to find out why, that's why I asked for your opinion but unfortunately it didn't make it clearer for me instead I've only seen the possibilities. The main possibility I see is that involving FIM into the provisioning process instead of letting applications do it themselves gives us a way of handling deprovisioning - the well known problem with federated on demand profiles or whatever they might be called. If we also let the attribute store update FIM attributes it could update a LastLogon attribute on each logon and from that we're able to manage deprovisioning from within FIM based on this attribute.

But you are correct in that it's kind of patch to a plumbing and I guess we need some more requests and some more input on this before it could be implemented.

//Henrik

Dec 15, 2010 at 7:18 PM
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
Dec 15, 2010 at 7:24 PM
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
Dec 15, 2010 at 7:42 PM

Guys,

 

David - you have described what I was trying to put in my free thoughts flow in the morning (before the coffee so maybe it is not clear enough :) ). Functionality I could see here is that if identity is not found in a FIM store it could call FIM service with request to create person or other type of object, which will trigger MPRs to provision respective objects to repositories for applications to use. Right. Then it have to return a claim which will tell application that this user was just provisioned for this application, which will have to be handled in some way in application anyway. 

 

This is what Henrik's code could do in this area. Of course it has to take into consideration some general requirements - like FIM call to provision this profile can be different in every case, for some services you may want to do it, for other not, so you have to have some way of configuring it. I'm just not sure if ADFS service and this extensibility point was designed for this case - that's why I've called this a plumbing - which doesn't mean that it can't be done :).

Probably something simple can be done pretty quickly - but to make it really working feature it would require a bit of planning and work.

Definitely it would be useful but in perfect world I would like to see ADFS v2 exposing another extensibility point for this than hacking attribute store library.  But it isn't perfect world we live in ;)

 

My .02 PLN

Dec 15, 2010 at 7:58 PM
When I have discussed shadow account provisioning with Microsoft in the past, their guidance, right or wrong, has been to write a custom attribute store. They also indicated that others have done this already, but I suspect they have just done LDAP writes to AD DS or LDS.



This is a "function" you would likely call from the Claims Provider Trust claims rules as opposed to the Relying Party trusts claims rule (but it could be either).



Even if Microsoft were to include shadow account provisioning in ADFS in the future, it would likely be limited to AD DS.



David

________________________________
From: tomaszon [email removed]
Sent: December-15-10 12:42 PM
To: David Adshade
Subject: Re: Please! Give us feedback! [FIMAttributeStore:237487]


From: tomaszon

Guys,



David - you have described what I was trying to put in my free thoughts flow in the morning (before the coffee so maybe it is not clear enough :) ). Functionality I could see here is that if identity is not found in a FIM store it could call FIM service with request to create person or other type of object, which will trigger MPRs to provision respective objects to repositories for applications to use. Right. Then it have to return a claim which will tell application that this user was just provisioned for this application, which will have to be handled in some way in application anyway.



This is what Henrik's code could do in this area. Of course it has to take into consideration some general requirements - like FIM call to provision this profile can be different in every case, for some services you may want to do it, for other not, so you have to have some way of configuring it. I'm just not sure if ADFS service and this extensibility point was designed for this case - that's why I've called this a plumbing - which doesn't mean that it can't be done :).

Probably something simple can be done pretty quickly - but to make it really working feature it would require a bit of planning and work.

Definitely it would be useful but in perfect world I would like to see ADFS v2 exposing another extensibility point for this than hacking attribute store library. But it isn't perfect world we live in ;)



My .02 PLN

Read the full discussion online<http://fimattributestore.codeplex.com/Thread/View.aspx?ThreadId=237487&ANCHOR#Post536357>.

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
Coordinator
Dec 15, 2010 at 8:08 PM

I can't see a way of returning anything else than a confirmation a create resource request has been sent when the provision functionality has been called since there's no way of actually making sure the resource has been created due to an eventual approval interfering the request not to mention the provision to target directory will take time and the same goes with a request to update a resource that also has to be included if this kind of functionality should be implemented.

I definitely understand this functionality could be useful, I know how to implement but I can't get rid of my sour gut feeling and I'm not sure I'm willing to add this feature without more backup so I'll ask for some more advice on this before I make up my mind...

Dec 15, 2010 at 8:33 PM
Henrik,



No problem...this has been a healthy discussion and well worth thinking about.



Confirmation that the web services request had been accepted would be more than enough. Some people would want approval workflows and others would not. The claim returned would be less about confirming that the user was successfully created and more about knowing that the user did not previously exist. I would then use this to redirect them somewhere else or display some sort of notification.



David





________________________________
From: HenrikNilsson [email removed]
Sent: December-15-10 1:08 PM
To: David Adshade
Subject: Re: Please! Give us feedback! [FIMAttributeStore:237487]


From: HenrikNilsson

I can't see a way of returning anything else than a confirmation a create resource request has been sent when the provision functionality has been called since there's no way of actually making sure the resource has been created due to an eventual approval interfering the request not to mention the provision to target directory will take time and the same goes with a request to update a resource that also has to be included if this kind of functionality should be implemented.

I definitely understand this functionality could be useful, I know how to implement but I can't get rid of my sour gut feeling and I'm not sure I'm willing to add this feature without more backup so I'll ask for some more advice on this before I make up my mind...

Read the full discussion online<http://fimattributestore.codeplex.com/Thread/View.aspx?ThreadId=237487&ANCHOR#Post536376>.

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