First published on MSDN on Jan 08, 2015
Let’s first discuss the Idea of Dynamic RCDC and its limitations with the Default FIM Portal.
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.
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.
<my:Grouping my:Name="MemberOfSecurityGroup" my:Caption="SG" my:Visible="{Binding Source= object , Path= isAdmin , Mode=OneWay}"> |
Example Code
Dynamic Tab
<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> |
<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
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
Workflows
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> |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.