User-Controlled Attributes in Forefront Identity Manager 2010
Security Tip of the Month – March 2010
See other Security Tips of the Month
By Mark Wahl, Senior Program Manager, Microsoft Forefront Identity Manager
In the first quarter of 2010, Microsoft will release Forefront Identity Manager 2010 (FIM 2010). In addition to enhancements to user provisioning, synchronization and certificate management features of the previous product Identity Lifecycle Manager 2007, FIM 2010 introduces new scenarios for policy-based identity management, and in particular self-service user and group management.
A key theme of FIM 2010 is empowering the end user, in order to reduce the burden on an enterprise's Active Directory (AD) administrator or help desk staff for performing typical everyday tasks necessary for maintaining an enterprise's identity data. In particular FIM 2010 can be deployed alongside AD and configured to allow to a user to perform many identity management tasks themselves, such as resetting a forgotten password, requesting to join or leave a distribution list, or managing the membership of security groups they own.
FIM 2010's interfaces are extensible to enable additional custom experiences as well. In this document, I'll show how FIM 2010's self-service user profile management can be configured for a privacy scenario: enabling end users to selectively control whether their colleagues can view their home phone number.
Self-Service User Profile Management
In a typical mid-size or large organization, the initial values of the attributes forming each user's identity resource originate in an application's database, such as a HR system's database. When a record for new employee is added in that HR system, FIM 2010 constructs the initial attributes, such as a name attribute and an employee number attribute, from the fields of that record in the HR database, and provisions those attributes into AD as well as to other directories and databases where the a copy of the resource is needed. (The document Publishing Active Directory Users From Two Authoritative Data Sources provides a step-by-step guide to how to implement a sample provisioning business process using FIM 2010's declarative provisioning rules.)
For attributes about a user which might not be maintained in the HR system, such as the user's home telephone number or personal mobile telephone number, FIM 2010 can be configured with business processes to allow the user to review and maintain these attributes through the FIM Portal.
Furthermore, the FIM Service's can be configured to include workflows in those processes, such as to ensure that the user's manager or a HR specialist has reviewed can approve the changes a user requests to their profile before those changes are provisioned out to AD.
Enabling End Users to Review their Profile through the FIM Portal
In order to enable end users to review their profile in FIM 2010 from a web browser using the FIM Portal, the FIM administrator must first configure in the FIM Service and FIM Sync Service that certain attributes of the person object type: Resource SID (in AD the attribute is called ObjectSID), Domain and Account Name (in AD sAMAccountName), are to be synchronized from AD through the FIM Sync Service into the FIM Service, that the Management Policy Rules "User management: Users can read attributes of their own" and "General: Users can read non-administrative configuration resources" are enabled, and finally that the resources for the existing users, including their attributes mentioned above, are imported from AD to the FIM Sync Service and exported to the FIM Service database. These steps are documented in the FIM 2010 Installation Guide in the sections Populating the FIM Service database, FIM Portal Access and Active Directory to FIM 2010 Initial Data Load. (The document Introduction to Distribution Group Management provides a step-by-step guide to configuring the self-service group management scenario which also includes the steps necessary for end users to view their own profile.)
Extending FIM 2010 for User-Controlled Attribute Visibility
The FIM 2010 schema, workflows, and portal-based experiences are extensible to support additional object types, additional attributes, and additional business processes. Let's see how to add more attribute to a FIM 2010 deployment to provide the user with an enhanced self-service profile management experience
Suppose Fabrikam wants to enable its employees to provide their contact information in the enterprise identity, so that other employees can find out how to reach them. However, users may not be comfortable with personal contact information, such as home phone numbers, mobile phone numbers or home addresses, being made available to all the other employees: they may wish the numbers to only be visible for administrators to use in an emergency. While some HR systems allow these attributes about a user to be specified as part of the user's record in the HR system, users might forget to go to the HR system when, for example, they change the mobile phone number, and thus this data in HR becomes out of date – it would be better for the enterprise to ensure consistency by providing the user a familiar web experience to manage this data.
In this example, a new attribute for a user's Home Phone is added to the FIM Service, along with policy change that enables users to set the value of this attribute through the FIM Portal, and furthermore enables them to control who else in the enterprise can read their Home Phone attribute through the Portal. This example assumes the FIM Service and Portal are already configured as described in the previous section to allow end users to access the FIM Portal. The rest of the configuration steps described below are to be performed by a FIM administrator logged into the FIM Portal.
For this example, I want to allow users to control who else at Fabrikam can read their Home Phone attribute. This can be done with an additional attribute, Home Phone Visible. For simplicity, in this example, this is specified as Boolean-valued attribute with just two choices. If the value is "True", then everyone can read the user's Home Phone attribute value. Otherwise, only the FIM administrator, and the user themselves, can read the user's Home Phone attribute value.
Extending the FIM Service Schema for New Attributes
The FIM Sync Service default schema already includes a HomePhone attribute for the Person object type, but the FIM Service default schema does not have this attribute, so it will need to be added, as well as a related attribute to control the visibility. In the FIM Portal, go to Administration, click on Schema Management, and then click on All Attributes. Click on New, provide the System Name "HomePhone", Display Name "Home Phone" and Data Type of Indexed string, and submit the new attribute. Then, click on New again, provide the System Name "HomePhoneVisible", Display Name "Home Phone Visible" and Data Type of Boolean, and submit this new attribute.
Next, add the bindings for these two attributes to the Person object type. Switch to All Bindings. Click on New, provide the Resource Type "User" and Attribute Type "Home Phone", specify that the attribute is not required to be present, and override the display name of the attribute binding to be "Home Phone" rather than "HomePhone". After submitting that binding, again click on New, provide the Resource Type "User" and Attribute Type "Home Phone Visible", specify that the attribute is not required to be present, override the display name of the attribute binding to be "Home Phone is Visible" rather than "HomePhoneVisible", and submit this binding.
The Home Phone Visible attribute you just created will be used in a Set definition, so it will be necessary to allow the FIM administrator to search for resources which match its values. Go to Administration, then click on Filter Permissions, and edit the Filter Permission "Administrator Filter Permission". In the Allowed Attributes field add "Home Phone Visible" and submit this change.
Defining Policies for the User Attributes
A Management Policy Rule (MPR) resource defines what happens a request is received at the FIM Service. A request type MPR specifies the permissions for a request to be allowed, as well as workflows which are needed for performing the request. In this example, users are allowed to change their own Home Phone and Home Phone Visible attributes, which can be configured by adding a new MPR of the request type that does not have any workflows attached to it. To add this MPR, click on Management Policy Rules, click New, provide the Display Name "users set own home phone number and visibility", the MPR type as Request, change the principal to be relative to the resource, select the attribute "Resource ID", select the operations Read resource and Modify a single-valued attribute, specify for permissions that the MPR grants permission, the target resource definition before request is "All Active People", the target resource definition after request is also "All Active People", change the Resource Attributes to Select specific attributes, specify the attributes "Home Phone; Home Phone Visible", and submit the new MPR.
A Set resource defines a collection of one or more resources, either explicitly by referencing the resources, or with an XPath filter which specifies the criteria of resources to include in the Set. The policy for allowing other users to read this new attribute is enforced by specifying a Set of users who have provided their Home Phone Visible attribute with value True. On the Administration page, click on Sets, click New, provide the Display Name "Users whose home phone visible attribute is true", and ensure the Enable criteria-based membership in current set flag is checked. Then change the filter to match the pattern:
Select user that match all of the following conditions:
- Home Phone Visible is true
- Add Statement or Add Sub-condition
Next, a new MPR is needed to reference this set to give other users read access. After submitting the new Set, click on Management Policy Rules, click New, provide the Display Name "users can read visible home phone numbers of other users", the MPR type as Request, requestors is the set "All Active People", the operation is Read resource, specify for permissions that the MPR grants permission, the target resource definition before request is the newly added set "Users whose home phone visible attribute is true", change the resource attributes to select specific attributes, specify "Home Phone" as the attribute, and submit the new MPR.
The user profile will have other attributes besides the home phone number that should be visible to other users by default. Within the Management Policy Rules list, find the MPR named "User management: Users can read selected attributes of other users" and enable it.
Adding the Home Phone Attribute to the FIM Portal
After completing the preceding steps, the new attributes will be available in the FIM Service with the configured business processes, but it will not be visible in the FIM Portal on a user's resource except in advanced mode, which is available only to the Administrator. To complete this example, it will be necessary to add to the Resource Control Display Configurations (RCDCs) that format the pages for viewing and editing Person resources to include the new attributes.
First, add the attribute for allowing other users to view. In the Administration page, click on Resource Control Display Configuration, click on "Configuration for User Viewing", in the Configuration Data section click on Export configuration, save the resulting XML to a file "user view configuration.xml", and then cancel editing. Open this new file in an XML editor, and add a new section after the control for the MobilePhone. Note that this new section has exactly the same structure as that for the MobilePhone control, the only difference is the name of the attribute is changed from MobilePhone to HomePhone:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<my:Control my:Name="MobilePhone"...
</my:Control>
<my:Control my:Name="HomePhone" my:TypeName="UocLabel"
my:Caption="{Binding Source=schema, Path=HomePhone.DisplayName}"
my:Description="{Binding Source=schema, Path=HomePhone.Description}"
my:RightsLevel="{Binding Source=rights, Path=HomePhone}">
<my:Properties>
<my:Property my:Name="Required"
my:Value="{Binding Source=schema, Path=HomePhone.Required}"/>
<my:Property my:Name="Text"
my:Value="{Binding Source=object, Path=HomePhone, Mode=TwoWay}"/>
</my:Properties>
</my:Control>
<my:Control my:Name="OfficeLocation" ...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
To store the revised file in the FIM Service database, click on "Configuration for User Viewing", in the Configuration Data section click Browse..., select the "user view configuration.xml" file you just edited, and submit this change.
Next, add a RCDC for the user to edit their Home Phone and Home Phone Visible attributes. Click on "Configuration for User Editing", in the Configuration Data section click on Export configuration, save the resulting XML to a file "user edit configuration.xml", and then cancel editing. Open this file in an XML editor, and add two new sections after the control for MobilePhone, one for the HomePhone attribute and one for the HomePhoneVisible attribute:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<my:Control my:Name="MobilePhone"...
</my:Control>
<my:Control my:Name="HomePhone" my:TypeName="UocTextBox"
my:Caption="{Binding Source=schema, Path=HomePhone.DisplayName}"
my:Description="{Binding Source=schema, Path=HomePhone.Description}"
my:RightsLevel="{Binding Source=rights, Path=HomePhone}">
<my:Properties>
<my:Property my:Name="Required"
my:Value="{Binding Source=schema, Path=HomePhone.Required}"/>
<my:Property my:Name="Columns" my:Value="34"/>
<my:Property my:Name="MaxLength" my:Value="128"/>
<my:Property my:Name="Text"
my:Value="{Binding Source=object, Path=HomePhone, Mode=TwoWay}"/>
</my:Properties>
</my:Control>
<my:Control my:Name="HomePhoneVisible" my:TypeName="UocRadioButtonList"
my:Caption="{Binding Source=schema, Path=HomePhoneVisible.DisplayName}"
my:RightsLevel="{Binding Source=rights, Path=HomePhoneVisible}">
<my:Options>
<my:Option my:Value="True"
my:Caption="Allow my home phone to be visible to all users"
my:Hint=""/>
<my:Option my:Value="False"
my:Caption="My home phone is only visible by me and FIM administrators"
my:Hint=""/>
<my:Option my:Value=""
my:Caption="Unspecified"
my:Hint=""/>
</my:Options>
<my:Properties>
<my:Property my:Name="Required"
my:Value="{Binding Source=schema, Path=HomePhoneVisible.Required}"/>
<my:Property my:Name="ValuePath" my:Value="Value"/>
<my:Property my:Name="CaptionPath" my:Value="Caption"/>
<my:Property my:Name="ItemSource" my:Value="Custom"/>
<my:Property my:Name="HintPath" my:Value="Hint"/>
<my:Property my:Name="SelectedValue"
my:Value="{Binding Source=object, Path=HomePhoneVisible, Mode=TwoWay}"/>
</my:Properties>
</my:Control>
<my:Control my:Name="OfficeLocation" ...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
To store the revised file in the FIM Service database, click on "Configuration for User Editing", in the Configuration Data section click Browse..., select the "user edit configuration.xml" file, and submit this change. After this change is present, it is generally necessary to restart the FIM portal to ensure that the changed RCDCs are used, and this can be done by running the command iisreset.
To test the change, log in to the FIM portal as a non-administrator user, click on My Profile, and change to the Contact Info tab. The new fields should now be visible, allowing the user to specify their home phone as well as the policy for other users ability to view it:
Going Further
This example has shown how to allow users to control the visibility of a single attribute for whether it can be seen by other users within the FIM system. FIM 2010 can be extended further to support more complex controls, such as allowing finer-grained controls for additional principals, controlling multiple related attributes, or by controlling which attributes are synchronized into AD or other connected systems. Through AD these policies can also be integrated with Active Directory Federation Services to allow a user to control which attributes are turned into claims for use by web applications across the Internet.