Resources for IT Professionals >
Forums Home
>
Identity Management Forums
>
Identity Lifecycle Manager 2
>
New MV and FIM DB Object Type - Account
New MV and FIM DB Object Type - Account
- I think a lot of enterprise scenarios - especially provisioning/deprovisioning, would be a lot easier to implement if FIM handled the distinction between a person and an account better. One person may often have multiple accounts in a single system.
Actions related to individual systems should occur on an account object, but HR/address etc actions should generally occur on a person object - and ALL related accounts. Relevant workflows could then work on account objects or person objects (and recursively on all their accounts)
I'd like to see separate person and account objects with reference attributes which link the account(s) to the relevant person.
I realise this would require a complete redesign of the portal, so probably won't happen any time soon.- Edited byMarkus VilcinskasMSFT, ModeratorMonday, November 02, 2009 8:07 PMItem added to the catalog page
All Replies
- This is good feedback, Capriole, thanks for sharing.
All, what do you think about this?
Cheers,
Markus
Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation - I think this idea is just about words, in some systems it's called "account" and in others "user" and this is known by everyone that it means "User account" I don't have a problem with it and I see no reason to add a default "account" resource. What I on the other hand dislike is that the words "User" and "Person" are used for the same resource type in the portal and in web services. The name of the resource is "Person" but in the portal it's called "User", I would prefer "User" to distinguish between "User account" and the physical person.
//Henrik
Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se) - Henrik,
Could you share how you'd handle this scenario - if there's a better way to handle this with the existing classes/resources I'd like to use it.
Fred Smith joins the company as a systems administrator.
The company HR System contains employment status, address and manager attributes for Fred Smith
Fred needs 3 accounts in a single AD domain
fsmith01 for normal use
fsmith01test for testing purposes
fsmith01adm for administration purposes
(A "typical" AD MA would have connectors to 3 objects in the MV+FIM, A "typical" HR MA would have a connector to 1 objects in the MV+FIM)
When Fred changes role, his address or manager details change, or he leaves, ALL 3 AD accounts should be updated or disabled.
I have explored ways to achieve this with multiple MAs per external system, tricky lists or custom workflows, but it would nice for it to be "easier"... and I thought separating account and person objects with a mechanism to maintain the relationship might do this...
- I admit it's a tricky scenario and I get your point... :-)
But!.. The number of accounts affected by this is usually low and the cost/complicity in both development of the product to handle this and training/understanding for implementors would probably be too high and with just a couple of months left for release this is nothing we could even hope for.
As you said, this could be done using workflow (definitely the right place for implementing this) and instead of complicating the product even more I would appreciate a guide that helps solving this scenario instead.
//Henrik
Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se) This is a common issue, even if a person only has one account in each system, they need to be handled (add/removed/disabled etc.). It could be solved by having mutiple attributes on the person (one per system/application). But this is messy and difficult to extend.
One approach I am exploring for a project is to have two new object types:
- a system object that contains system information such as name and a list of people who can approve an account, escalators etc.
- an account object what conatins the account name in the target system, account status (enabled/disabled), a reference to the person and a reference to the system
A custom approval workflow is triggered on creation of a new account object and seeks approval from the person's manager and system approver.
A custom action workflow updates all acounts owned by a person - e.g. disable all, delete all etc.
Steve Mitchell Technical Director - Oxford Computer Group- Thanks Henrik/Steve
A really good guide would definitely go along way and might be better/easier than more product "features".
If either of you get something suitable working it work be great if you could share it.
For me it's on the backburner while i get the mundane parts working...
- Hi all,
this scenario is interesting for me as well. I want to allow users to have multiple accounts and get some information updated in all of them when the user's data changes in the Human Resources database.
I have tried this approach:
- add a "owner" property to Person objects in the metaverse and in FIM
- when I create a "secondary account" (i.e. a test or administrative account) for an existing user from FIM, I set the owner of the account to the EmployeeID of an existing user
- create a new inbound rule for the HR MA with relationship owner = EmployeeID
This, however, does not work as only the "primary" inbound synchronization rule (having a relationship EmployeeID = EmployeeID) is applied.
I tried another approach, defining a new MA, called "HR Secondary", and applying the inbound rule for secondary accounts to that MA.
This approach works if the user has only one secondary account; if he has more, only the first gets updated.
Is there a way to specify that a synchronization rule could be applied to more than one resource in the metaverse?
Capriole , you were mentioning a "multiple MAs per connected system" solution you tried, was it something similar? did you manage to get it work?
Steve , when you talk about "Custom action workflow" you mean a workflow that triggers a custom activity? A custom activity would of course solve all problems, but I was wondering if there's a way to obtain this without writing custom code.
Cheers,
Paolo
Paolo Tedesco - http://espace.cern.ch/idm - The multiple MAs per connected system was to get round the fact that you can only have a single connector. So if you need N-to-1 relationships then just create N MAs, and tweak the filtering. It certainly looked technically possible this way, but pretty sure it would be unusable in the real world unless you had a single experienced person looking after it.
I had other ideas involving provisioning accounts from AD and people from HR both into an intermediate SQL database and probisioning FIM from a join there - but it seems slightly crazy to set up another database to manage relationships between accounts and identities when FIM is supposed to do that....
Cheers. - Hi Capriole, thanks for your answer!
It looks like the N-MAs option is not really feasible, at least if one wants to grant the possibility to create an arbitrary number of secondary accounts. Moreover, it has the disadvantage that you have to maintain a referential integrity between primary and secondary accounts yourself (e.g. setting the "owner" attribute to an employeeID as in my previous example), since you cannot define a relationship criteria in a synchronization rule involving a reference attribute (obviously, since references make sense only inside a single connector space).
I too had thought about the join possibility and dismissed it as crazy :)
I'm now trying to investigate an alternative:
- when you create a secondary account, set the primary account as manager (now FIM guarantees referential integrity)
- define a workflow with a Function Evaluator Activity for each attribute you want to copy, e.g.
- Activity Display Name: Update First Name
- Destination: [//Target/FirstName]
- Value: Custom Expression -> [//Target/Manager/FirstName]
But I cannot understand how to define a rule to trigger the workflow properly, i.e. whenever the manager is modified.
Has someone tried something like this?
Cheers,
Paolo
Paolo Tedesco - http://espace.cern.ch/idm - Hi All,
I'm currently also investigtion into this issue, because I consider this as esentional to an Identity Management system.
My approach is to have two different object in the FIM database; user/person/people (also don't like this different names for the same resource) and accounts (where accounts could be AD, Notes or other target systems. This resouces has very few attributes, only the ones which are required to create and account and are acocunt specific, no person information.
There is a 1-n realationship between person and accounts. I already have an idea how this looks in the interface.
The account resources is which are provisioned/deprovisioned in AD and other systems. Through an additional MA, where the accounts in the connector space join to the metaverse person objects, the account person attributes (name, address, location and more) are flowing outbound from the MV person object to the CS objects. In this case you can have n CS object joined to 1 MV person object.
This is my plan, i'm not there yet. Currently I'm struggeling with figuring out how to add addtitional objects to the FIM Service MA. Anyone could give me a hin?
Regards,
Christian
IAM Consultant - Hi Christian!
I'm also working on a solution for this problem even thought I'm only going to add two attributes to the user object schema and my solution will either be a blog post or a short white paper bundled with a couple of workflow activities.
If you wish to add your costom objects to the FIM MA you must add it to the Synchronization Filter from the portal (/Administration/All Resources/Synchronization Filter) and then update you FIM MA schema.
Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)
