none
FIM Portal Permissions to View Manager

    Question

  • Hi All,

    I've got this requirement that when I first heard it thought would be quite simple but it's turned out not so easy. I'm trying to set up configuration so that a user in the FIM Portal when viewing their own details can click on the hyperlink in the Manager attribute and see their Managers details. This is simple if you just allow all users to read all attributes of all users but the requirement states that users should not be able to read all others, just themselves and their Manager. The problem is that there is no way to target relative to the requestor.

    I've thought about adding a new attribute on user called something like "Manages" that would contain users the user manages and use a WF to populate this attribute from Managed By effectively reversing the reference then it's possible to use a relative requestor MPR that points at the new Manages attribute. But this seems like waaay too much overhead for something that seems so simple. Are there any other approaches I could take here?

    dimanche 24 mars 2013 08:51

Réponses

  • I've thought about adding a new attribute on user called something like "Manages" that would contain users the user manages and use a WF to populate this attribute from Managed By effectively reversing the reference then it's possible to use a relative requestor MPR that points at the new Manages attribute. But this seems like waaay too much overhead for something that seems so simple. Are there any other approaches I could take here?

    I agree that this seems like too much overhead, but that's probably how I'd do it, to be honest.

    Just to add some extra overhead, keep in mind that if you have a WF which populates the attribute, you'll also have to have one which de-populates it as well. I generally tie this into a single workflow.

    Having a quick think about it, this is probably the most straight-forward way of doing it. Perhaps someone else can come up with something.

    - Ross Currie



    FIMSpecialist.com | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services

    • Marqué comme réponse Dan_Walters lundi 18 août 2014 14:00
    lundi 25 mars 2013 02:24
  • I concur with Ross - if you want to use the relative to resource MPR idea then you have no option but to have the ManagerOf property set - and I have done this myself in 2 ways:

    1. using a custom workflow which picks up changes to Person.Manager and completely recalculates the Person.ManagerOf property of the manager - the downside of this approach is that workflows can and usually do fail every now and then (even if it's less than 0.01% of the time), and when they do you will need some sort of housekeeping process to keep tabs on the integrity;
    2. using the sync engine with some other authoritative source of the Person.Manager inverse - I used a variation on the Replay MA to construct Person.ManagerOf and then flow this back into the FIM Portal via the standard FIM MA.  The benefit of this is that there are no workflows that can fail, and the sync engine ensures consistency for you.  The downside is the extra sync cycles required (and the delay this can cause).

    You will have to choose which one suits you best.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Marqué comme réponse Dan_Walters lundi 18 août 2014 14:00
    mercredi 27 mars 2013 02:50

Toutes les réponses

  • I've thought about adding a new attribute on user called something like "Manages" that would contain users the user manages and use a WF to populate this attribute from Managed By effectively reversing the reference then it's possible to use a relative requestor MPR that points at the new Manages attribute. But this seems like waaay too much overhead for something that seems so simple. Are there any other approaches I could take here?

    I agree that this seems like too much overhead, but that's probably how I'd do it, to be honest.

    Just to add some extra overhead, keep in mind that if you have a WF which populates the attribute, you'll also have to have one which de-populates it as well. I generally tie this into a single workflow.

    Having a quick think about it, this is probably the most straight-forward way of doing it. Perhaps someone else can come up with something.

    - Ross Currie



    FIMSpecialist.com | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services

    • Marqué comme réponse Dan_Walters lundi 18 août 2014 14:00
    lundi 25 mars 2013 02:24
  • I concur with Ross - if you want to use the relative to resource MPR idea then you have no option but to have the ManagerOf property set - and I have done this myself in 2 ways:

    1. using a custom workflow which picks up changes to Person.Manager and completely recalculates the Person.ManagerOf property of the manager - the downside of this approach is that workflows can and usually do fail every now and then (even if it's less than 0.01% of the time), and when they do you will need some sort of housekeeping process to keep tabs on the integrity;
    2. using the sync engine with some other authoritative source of the Person.Manager inverse - I used a variation on the Replay MA to construct Person.ManagerOf and then flow this back into the FIM Portal via the standard FIM MA.  The benefit of this is that there are no workflows that can fail, and the sync engine ensures consistency for you.  The downside is the extra sync cycles required (and the delay this can cause).

    You will have to choose which one suits you best.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Marqué comme réponse Dan_Walters lundi 18 août 2014 14:00
    mercredi 27 mars 2013 02:50
  • Any step-by-step instructions how to achieve the 1st option mentioned above?

    lundi 18 août 2014 13:00
  • You'll need to create a new WorkFlow, MPR, Set triple. The set would be all users who you want to have this functionality so you could use All Users, however, you might run into some queuing difficulty if you have a large number of users and you apply it to all of them at once - that's up to you.

    The MPR should be request based and set to the ManagedBy attribute so that when one of the users in the above set have their manager changed the workflow is fired.

    The workflow will need to be a custom workflow. You can write these yourself - Ross has written some tutorials on how to do that at his website FIMSpecialist.com or you can get pre-written ones. Soren Grandfeldt has released his as open source. There's custom workflows that let you read attributes from objects and update attributes of objects. You can read the ManagedBy attribute then chain it to the next workflow and target the Person object that is the manager and then update the managerOf attribute field to add the new Person that triggered the workflow.

    It sounds complicated but really it just goes "Oh here is a new person, Jess. Oh I see John is Jesses manager. I'm going to add Jess to Johns list of people he manages".

    (Whoah I just realised I'm the OP)

    btw there's a FIM User Group where Soren is demoing his open source custom workflows on 20/08/14 https://thefimteam.com/fim-team-user-group/

    lundi 18 août 2014 13:59
  • I was thinking that someone already has a solution for this issue... I was thinking of using powershell workflow addon with custom ps script, the problem comes when I need to first evaluate the multivalued refrence attribute (Manager Of) to see is the user in case already there. One solution might be to clear the value everytime and populate every user to that the manager manages to that attribute when the workflow is fired. This way it would always contain the right members... any examples of clearing all the values for multivalued attribute in ps would be helpful..
    mardi 19 août 2014 10:33
  • Yeah, I remember running into that. The problem is that PowerShell isn't strongly typed and if you try to set a mutlivalued attribute to $null or "" or something like that it will throw an error.

    So you need to find out what the data type of the attribute is, as PowerShell is aware of it. To do that, if I'm remembering correctly, I pulled an empty multi-valued attribute and called GetType() on it in PowerShell and wrote that to a file so I could see the output.

    Once you know the type, you can strongly type an empty variable and assign that to clear the multi-valued attribute. I don't remember the datatype but i think it was something like [System.Collections.List].

    mardi 19 août 2014 10:45