다음을 통해 공유

RCDC - Session 4 - Dynamic RCDC

  • 아티클

Let’s first discuss the Idea of Dynamic RCDC and its limitations with the Default FIM Portal.

  1. What the Dynamic RCDC is
    1. Attributes or Tabs that are displayed for a Resource depending on the permissions granted by an MPR for the attribute that it is bound too {Binding Source=rights, Path=DetectedRulesList}
    2. Attributes or Tabs that are displayed for a Resource depending on the value of a specific attribute of the Target which is the object that is being managed.
  2. What the Dynamic RCDC is not (by default with standard FIM Portal)
    1. Drop down Menu values that are defined by a value that was set prior in the User Interface.

The Dynamic RCDC Solution is used in Conjunction with an Edit Configuration RCDC for your resource. Currently there is no easy way to implement this concept of Dynamic RCDC with the Create Configuration for a Resource, to understand this we need to review MPR's and how they work with RCDC's.

 

A.      What happens when you click on a Resource in the FIM Portal?

1.      A Window will open which is controlled by the Edit RCDC for the Resource type of the resource that you have clicked on.

2.      A Set that includes the user that needs to manage a resource in the FIM Portal is given Read permissions for all resources that are included in the Target Set in the Permissions Granting MPR.

    1. If a resource is not included in the Target Set that gives the user in the Portal permissions to manage a particular type of Resource than that user would not be able to see that resource.

Example: John Doe is a member of a Set that is given permissions to manage users of a different set users which includes all users with Department set with a value of HR. When John Doe navigates to the Users Page in the FIM Portal John Doe should only see users that have their Department set with a value of HR and no one else, additionally John Doe should only see attributes of the users that John Doe has permissions view, this is defined on the Target Tab of the Permissions Granting MPR with in the Resource Attributes Section. All Attributes will give John Doe Permissions to view all attributes of a user that John Doe manage but if you select the option for Select specific attributes and only add the attributes that you wish John Doe (or anyone else that was a member of the Set defined on the Requestors and Operations Tab in the Specific Set of Requestors Section) than only those attributes will be available to be viewed.

3.      By Creating multiple Criteria Based Sets that defines which users can be a member of that set which can be used with additional Permission Granting MPR's that give permissions to the users of one of the users that are a member of this other set to have either a greater scope of types of resources that they can manage or what attributes that they can manage hence given the illusion of a Dynamic RCDC. 

Example: John Doe is a member of Set A which gives members of that set the permissions to manage all users with Department set with a value of HR and has permissions to manage all attributes except EmployeeID. When John Doe logs into the Portal and clicks on a user that John Doe can manage the EmployeeID Attribute is not displayed. But if John Doe later falls into a new Criteria Set that would be used to give read permissions with another MPR than John Doe would suddenly be able to see the EmployeeID attribute for those users.

Code used in the User Edit RCDC that is used to determine if the user viewing the object has permission to view the attribute EmployeeID (Default RCDC XML Code)

I.          Highlighted in some shade of pink (rights) is used by the RCDC to allow the user when viewing the resource object to view the attribute of attribute “EmployeeID” is defined by the attribute which is EmployeeID and is highlighted in Yellow.

<my:Control my:Name="EmployeeID" my:TypeName="UocTextBox" my:Caption="{Binding Source=schema, Path=EmployeeID.DisplayName}" my:Description="{Binding Source=schema, Path=EmployeeID.Description}"  my:RightsLevel="{Binding Source=rights, Path=EmployeeID}">

 

B.     What Happens when a User clicks on the New Button within the Resource Home Page?

1.      A Window will open which is controlled by the Create RCDC for the Resource type that you have clicked on with the New Button from the Resource Home Screen, so if you click on the New Button from the User Home Screen the Window that opens up is controlled by the

QUESTION:

1.      What MPR is currently being triggered to allow the user to click on the NEW Button?

A.) None

2.      How does the User Create RCDC check for rights to verify the User that clicked on the New Button has permissions to view any of the attributes that the User Interface will display?

A.) None

3.      When doe the MPR get triggered that gives permission to a set of users to create a resource?

A.) At the moment you click on Submit in the New Resource Window, until then no MPR is active.

So by now a light bulb should be going off…..the 2 questions that I just proposed are the exact 2 questions that I ask myself which started the light bulb flicker and as I thought about this the light got brighter and brighter until it made sense. 

 

C.     How do you control the User Interface with a value being set on the object being viewed, instead of the object during the viewing?

Example:   John Doe clicks on the user Jane Doe’s object in the FIM Portal and the User Interface dynamically changes as a result of a value that is set on Jane Doe’s User object.

  1. The Below code hides a tab when the Boolean associated to the object being viewed is set to false.
    1. Highlighted in Green (object) This represents the object being viewed is what is  what is being looked at to determine the action that needs to be taken.
    2. Highlighted in Red (isAdmin) is the attribute that must be a Boolean attribute and must be true or false.
  2. In order for this to work there must be a workflow that sets this value to true or false when it is initially created or you will see a configuration error on this object when you click on it (a null value will create an error)
<my:Grouping my:Name="MemberOfSecurityGroup" my:Caption="SG" my:Visible="{Binding Source=object, Path=isAdmin, Mode=OneWay}">

 

Example Code

Dynamic Tab

      • Object Being Viewed(The Following Complete Code is for a Dynamic Tab to be displayed or Hidden depending on the Object being viewed that has a Boolean value set to true or false)
        <my:Grouping my:Name="MemberOfSecurityGroup" my:Caption="SG" my:Visible="{Binding Source=object, Path=isAdmin, Mode=OneWay}"><my:Control my:Name="GroupMemberOfSG" my:TypeName="UocListView" my:ExpandArea="true" my:Caption="Security Groups"><my:Properties><my:Property my:Name="ColumnsToDisplay" my:Value="DisplayName,Email,Domain,DisplayedOwner" /><my:Property my:Name="EmptyResultText" my:Value="There are no groups according to the filter definition." /><my:Property my:Name="PageSize" my:Value="20" /><my:Property my:Name="ShowTitleBar" my:Value="true" /><my:Property my:Name="ShowActionBar" my:Value="false" /><my:Property my:Name="ShowPreview" my:Value="false" /><my:Property my:Name="ShowSearchControl" my:Value="false" /><my:Property my:Name="EnableSelection" my:Value="false" /><my:Property my:Name="SingleSelection" my:Value="false" /><my:Property my:Name="ItemClickBehavior" my:Value=" ModelessDialog " /><my:Property my:Name="ListFilter" my:Value="/Group[(Type='Security') and ((ComputedMember='%ObjectID%') or (ExplicitMember='%ObjectID%'))]" /></my:Properties></my:Control></my:Grouping>

 

      • Object Initiating the View(The Following Complete Code is for a Dynamic Tab to be displayed or Hidden depending on the user viewing the resource, and if the user has permission to read the attribute, additionally this attribute does not have to be a Boolean attribute)
        <my:Grouping my:Name="MemberOfSecurityGroup" my:Caption="SG" my:Visible="{Binding Source=rights, Path=SecGroups}"><my:Control my:Name="GroupMemberOfSG" my:TypeName="UocListView" my:Caption="Security Groups" my:RightsLevel="{Binding Source=rights, Path=IsAdmin}"><my:Properties><my:Property my:Name="ColumnsToDisplay" my:Value="DisplayName,Email,Domain,DisplayedOwner" /><my:Property my:Name="EmptyResultText" my:Value="There are no groups according to the filter definition." /><my:Property my:Name="PageSize" my:Value="20" /><my:Property my:Name="ShowTitleBar" my:Value="true" /><my:Property my:Name="ShowActionBar" my:Value="false" /><my:Property my:Name="ShowPreview" my:Value="false" /><my:Property my:Name="ShowSearchControl" my:Value="false" /><my:Property my:Name="EnableSelection" my:Value="false" /><my:Property my:Name="SingleSelection" my:Value="false" /><my:Property my:Name="ItemClickBehavior" my:Value=" ModelessDialog " /><my:Property my:Name="ListFilter" my:Value="/Group[(Type='Security') and ((ComputedMember='%ObjectID%') or (ExplicitMember='%ObjectID%'))]" /></my:Properties></my:Control></my:Grouping>

 

 

Scenario 1: John Doe_A1 is the Admin account that John Doe would use to perform his Admin functions. A new employee Jane Doe is hired (im unsure of their relationship) and Jane will need to perform some Admin Functions as well. John logs in to the FIM portal with his normal user account and when he clicks on Jane Does account he does not get the option to set the attribute "AdminAccountRequired" with a "true" value. but When John logs into the FIM Portal with his Admin Account he is now presented with the option to set the "AdminAccountRequired" attribute with a true value. This could be used to notify an some admin to create an Admin Account for Jane or it could be used with a workflow possibly with additional permissions that will automatically create the Admin Account. Once Jane gets her Admin Account "JaneDoe_A1" if John logs into the FIM Portal with his Admin account and clicks on Jane Does Admin Account "JaneDoe_A1" he is not given the option to set the attribute "AdminAccountRequired" with a true value because this account is already an admin account and you would not need to create an admin account for another admin account.

This Scenario would require the following:

2 Boolean Attributes bound to the User Resource

  1. isAdminAccount
  2. AdminAccountRequired

3 Sets

All Admin Accounts isAdminAccount is Equal to true
Admin Account Required AdminAccountRequired is Equal to true
Non Admin Accounts isAdminAccount is not equal to true

 

1 MPR

  1. MPR that gives permissions to people in the All Admin Accounts set to Read and Modify the attribute of "AdminAccountRequired" for all users within the Non Admin Accounts Set

Workflows

  1. On a new user creation with a function evaluator a "false" value needs to be applied to the attribute of "isAdminAccount"
  2. On a new admin account creation a "true" value needs to be set with a  function evaluator  for the "isAdminAccount" attribute
  3. On all new user accounts being created with a function evaluator a value of "false" needs to be set for the "AdminAccountRequired" attribute
  4. (Option A) Create resource workflow that builds an Admin Acocunt for a userbased off the values of the user with the request.
  5. (Option B) Notification workflow to inform an admins group with the information needed to build an admin account.

 

 The Following Code could be used to give users with the Boolean Attribute "isAdmin" set to "true" permissions to read, modify the Boolean Attribute "AdminAccountRequired" for all users except for any user that has the Boolean Attribute "isAdmin" set with a value of "true"

<my:Control my:Name="AdminAccountRequired" my:TypeName="UocCheckBox" my:ExpandArea="true" my:Caption="AdminAccountRequired" my:RightsLevel="{Binding Source=rights, Path=AdminAccountRequired}"><my:Properties><my:Property my:Name="Required" my:Value="{Binding Source=schema, Path=AdminAccountRequired.Required}"/><my:Property my:Name="Text" my:Value="Admin Account Requested"/><my:Property my:Name="Checked" my:Value="{Binding Source=object, Path=AdminAccountRequired, Mode=TwoWay}"/></my:Properties><my:Events><my:Event my:Name="CheckedChanged" my:Handler="Admin Account Requested"/></my:Events></my:Control></my:Grouping>

Comments

  • Anonymous
    April 19, 2016
    Nice article. By the way as much as I have tried I never managed to get a true or false out of a rights binding. Are you positive your example with my:Visible=”{Binding Source=rights, Path=SecGroups” in the MemberOfSecurityGroup grouping actually works? As much as I tried to either use the visible or readonly property with the rights binding to an attribute that admins can read but regular users cannot or vice versa I have never been able to succeed. I had the need to require an attribute for regular users, but not for admins and I had to resort to using two attributes and two instances of the same control. One attribute was readable by admins and had a rights binding to one instance of the control and the other attribute was readable by users and had a rights binding to the other instance. However, according to your example I should have been able to get away with one control and one attribute. Unfortunately it did not work, unless I am missing something.
    • Anonymous
      April 25, 2016
      I have used this process several times ,can you add the XML you are working with to the reply so i can look it