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