none
RCDC - Always show attribute empty RRS feed

  • Question

  • I have a custom resource with multi-valued reference attributes "addMembers","removeMembers". These attributes will be only used for kicking off custom workflow and should never "store" the values the user entered (only temporary or on the request).

    I want to craft the RCDC in such a way that the user will always see these attributes empty even if another user already added references to the attribute. Is it possible to always show the two reference attributes empty (even if they contain values from a previous request or pending workflow)?

    Essentially, I wanted the RCDC config to act as the following:

    <my:Property my:Name="Value" my:Value="" />

    But this doesn't actually post anything in the result request

     

    I'm thinking my other option is to use:

    <my:Property my:Name="Value" my:Value="{Binding Source=schema, Mode=TwoWay}" />
    And have the custom workflow be used in the "Authorization / Action" state, then have the workflow designed remove the existing values in these attributes after being completed?
    Friday, September 21, 2012 4:50 PM

Answers

  • If you're working in the authZ phase, nobody else will see anything in the UI because the request hasn't been commited to the FIM Service DB - so the problem doesn't exist.

    If you're working post-update in an action workflow - you can clear the value at the end of the custom workflow. There will be a short period between the update being the commited and the workflow removing the value. May or may not be a concern.

    Another option is to remove read access to the attribute.


    Frank C. Drewes III - Architect - Oxford Computer Group

    Friday, September 21, 2012 8:18 PM

All replies

  • I expect you need an action workflow to come behind and clean up when it suceeds.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, September 21, 2012 5:58 PM
    Moderator
  • If you're working in the authZ phase, nobody else will see anything in the UI because the request hasn't been commited to the FIM Service DB - so the problem doesn't exist.

    If you're working post-update in an action workflow - you can clear the value at the end of the custom workflow. There will be a short period between the update being the commited and the workflow removing the value. May or may not be a concern.

    Another option is to remove read access to the attribute.


    Frank C. Drewes III - Architect - Oxford Computer Group

    Friday, September 21, 2012 8:18 PM
  • If guessing from the attribute names that you're trying to add or remove users from groups in the User RCDC? If you get stuck, let me know, I ended up doing this a few projects back. Its a custom activity but not too bad. I'd be interested in seeing how you solve it and compare to what I did.

    Frank C. Drewes III - Architect - Oxford Computer Group

    Friday, September 21, 2012 8:34 PM
  • If guessing from the attribute names that you're trying to add or remove users from groups in the User RCDC? If you get stuck, let me know, I ended up doing this a few projects back. Its a custom activity but not too bad. I'd be interested in seeing how you solve it and compare to what I did.

    Frank C. Drewes III - Architect - Oxford Computer Group

    Close :) We have custom resource type, setup very similar to groups; however the reference to this new resource is actually stored on the user themselves in a multi-valued reference attribute. What i'm tryin to do is build a proof of concept approach where specific people can go to this new resource type list (instead of modyfing the reference on the user) and bulk update / remove users via the multiple result IdentityPicker.

    The actual validation will be performed in custom workflow (checking to see if the target user has the reference and add if they don't and vice-versa).

    I haven't done any custom activities in authZ, is it possible to define this workflow as authZ and perform updates to other resource types in this workflow (with them being committed), or does it have to be done as part of an action workflow

    Friday, September 21, 2012 8:47 PM
  • Actually this is exactly what I did in one of our solutions for customer. An attribute was exposed for editing, which then was used to update another attribute containing resultant list of assigned resources. Attribute was read for updating another attribute and then cleared automatically in action workflow. 
    Saturday, September 22, 2012 10:59 AM
  • Tomasz,

    If you don't mind me asking, were you able to handle multiple requests within a short time frame with that solution? For instance, did you run into issues with people seeing each others request due to workflow still being executed?

    Did you create the workflow as an action workflow or authoriztion workflow?

    It almost seems that placing this workflow in the Authorization state would work best (changes to the "addMembers" attribute not committed, while workflow modifies target references), however Microsoft specifically calls this out as a no-no:

    Authorization Workflows Should Not Create, Modify, or Delete Resources

    Monday, September 24, 2012 3:36 PM
  • I've seen the same. I think it may be because if the authZ workflow does not get a success - the original request doesn't get commited - so what happens to the 'other' changes? Do they get discarded as well?

    I did mine in an action workflow. There is the potential for someone to see (or even modify) the value between the time it's written to the database and the time the action workflow does its work and then clears the value, but it's a very small (second or less) window. Since the solution was limited to access by a small set of admins, we documented the potential and left it that way. If you have lots of changes and lots of users, the chance for conflict goes up.


    Frank C. Drewes III - Architect - Oxford Computer Group

    Monday, September 24, 2012 4:36 PM
  • Well, I just finished creating the custom workflow (as an action workflow) and it works pretty well.

    It's very fast in DEV due to the lack of load. I want to test the scenario I outlined above (a user modifies the values of a previous users request while workflow is still processing the initial request). The workflow is set to clear the attributes only after all members have been added / removed.

    I am assuming that workflow takes the request parameters of the initial request as a "snapshot" in time while workflow runs, if that's the case then I don't have to worry about this.

    Sorry to keep posting to this answered thread, just find it difficult to perform a test case where requests happen simultaneously. I might have to resort to using powershell.

    Wednesday, September 26, 2012 8:20 PM