The following sections include the concepts required to understand Identity Broker’s connectivity to SharePoint systems.
User profiles are SharePoint's representation of user information. Profile information is of a structure that has some semblance of the underlying directories used by SharePoint for user authentication and synchronization, such as Microsoft Active Directory.
User profiles in Microsoft Office SharePoint Server (MOSS) 2007 and SharePoint 2010, dynamic and enable users to be represented with a variety of attributes. These profiles are typically more representative of their source directory, with information such as position details, managers and location information represented in the profiles. However, user profile schema is extensible beyond the fields of the directory, allowing for a variety of types and fields that are only present in SharePoint.
Users are able to log in to their own SharePoint accounts and typically update much of their own information, with core information only managed by administrators.
All SharePoint profiles have a distinguished name known as an Account Name that acts as a unique identifier for the profile, as well as the handle by which users are able to log in to the system. These are both managed internally by SharePoint's User Profile Service. Delta changes are managed using a timestamped change token.
A default SharePoint installation will contain manager and assistant references in its user profile schema. These will contain the account name of the related user profile. As such, in order for these types of fields to be correctly populated, values for these fields should contain the account name(s) of an existing user profile.
In SharePoint, although the profiles are displayed with the manager and assistant display name, they are internally referenced using their account name:
As SharePoint schema is completely extensible, multiple fields may be configured and managed in a similar fashion. Ensure that the connector schema appropriately references the correct type, and that all exports match the reference expected by SharePoint.
User profiles are very similar between MOSS 2007 and SharePoint 2010, with some differences in types and schema options. See Microsoft SharePoint 2007 User Profile Connector and Microsoft SharePoint WCF User Profile Connector for managing user profiles.
Users are capable of creating and maintaining lists containing various information. In a typical instance, non-administrators are able to alter list contents and keep items up to date. List schema is completely customizable, like user profiles, allowing for a wide variety of data to be maintained in the system.
SharePoint lists can be represented by different views, which expose different subsets of list information and can be used for performance. For more information, refer to An Introduction To SharePoint Views and Designing large lists and maximizing list performance.
Lists can be extended to have references to user profiles. See the above section about how references to user profiles are managed in SharePoint, and configure interactions with lists to do the same.
Lists belong to the underlying Windows SharePoint Services installation, and as such, can be managed in any version of SharePoint. Each list item is uniquely identified by its Record Id, as lists and their items do not have any other properties where their uniqueness is enforceable. Delta changes are managed through the use of a Modified (timestamp) property. See Microsoft SharePoint List Connector for configuring list management.
Organization profiles were introduced in SharePoint 2010 and are used to represent information on hierarchy, such as organization units. Organization profiles, like user profiles, also have a dynamic schema, and can optionally be bound to an account name. Organization profiles do not have any unique fields outside of an unsettable Record Id field. As such, in order to bring organization profiles under management, two additional fields are required to be added and populated in their schema. Like user profiles, delta changes are managed through the use of a timestamped change token.
As with user profiles, organization profiles may contain references to user profiles through use of Members and Leaders fields. SharePoint requires these fields to be populated with the account name of existing user profiles. In order to correctly bring these fields under management, ensure they are populated appropriately and refer to user profiles that exist in SharePoint.
Organization profiles reference other organization profiles to calculate their parent reference. Without a successfully configured parent reference, organization profiles may exhibit unexpected behaviour. Profiles reference their parent by using the Record Id of their parent, which is not a configurable field. As a result, an additional field in SharePoint is required in order to bring organization profiles under management. More information on this is available in the Microsoft SharePoint WCF Organization Profile Connector documentation.
As described above, members will appear as resolved in SharePoint, but internally stored using the user profile's Account Name:
Similarly, parent references appear as resolved in SharePoint:
However, they are internally stored using the organization profile's Record Id:
Refer to Microsoft SharePoint WCF Organization Profile Connector for more information on organization profile management.
Identity Broker liaises with MOSS 2007 and WSS instances through the use of web services, and Windows Communication Foundation (WCF) for SharePoint 2010 interaction. Refer to the installation guides referenced on each individual connector page for more information.
Choice List Type Fields
SharePoint profiles may be configured to use choice lists for field values, allowing for reuse or limiting of options available for particular fields. These fields may cause issues in an identity management solution if SharePoint, the solution, and the Identity Broker configuration are not synchronized in their expectation of how these fields will be handled.
The following handling for these fields is recommended:
- The identity management solution should not allow for the exporting of inconsistently cased values for a choice list type field - this can result in cycling errors.
- Where applicable, consider marking these fields as read only in the schema.
- Be aware that any changes to a field value will result in a value change for all users who have the choice/s selected, and this may result in a large number of changes flowing through the solution. If this is not intended, ensure these fields are suitably locked down to prevent potentially harmful flows from occurring.
There are some specific considerations for the formatting of data for presentation to the identity management solution via an Identity Broker adapter.
Distinguished Name Configuration
The configuration of each Identity Broker adapter Distinguished Name template is paramount to the successful management of SharePoint information. For each of the object types, the following configurations are advised.
As the SharePoint AccountName is used extensively throughout SharePoint and an identity management solution, the distinguished name template for the User Profile adapter should be set to a Distinguished Name Schema Field Template component using this field. These distinguished names will be of the format CN=CommonName,DC=NetBiosDomainName. For example, an account name may be CN=1001,DC=UNIFY2010.
The AccountName is already of the correct format for memberships to resolve in the other objects, so no further transformation should be required to adapt these fields.
SharePoint list items only have one unique field, namely its ID. However, as this field is not settable when provisioning new list items to the system, the distinguished name generator configuration should use the Identity Broker ID, and it is suggested to use the UID field component. The entity identifier is unique and can be set as new items are added by exporting a Guid value to the IdBID field.
In order to accommodate for seamless integration with an identity management solution, organization profiles should use a standard field for their distinguished names. The field selected should be the prescribed profile reference field described in the Schema section of Microsoft SharePoint WCF Organization Profile Connector. An example of a suggested DN format is OU=IdMProfileReference or OU=OrganizationalCode, depending on the defined fields in the identity management solution.
There are a few considerations to keep in mind when exporting data to SharePoint:
- Ensure that the distinguished names for entities are of the same format as defined for the adapter
- The solution must be kept up-to-date in order to ensure rename operations are picked up in a timely manner, allowing subsequent exports to run unhindered
- Prior to adding a new membership to an organization profile or list, ensure that the exported distinguished name corresponds to an existing user profile
- Choice List types in SharePoint can cause issues for identity management unless some care is given to their configuration. Refer to the Choice List Type Fields section above for more information.
- As mentioned above, in order for references to correctly resolve, referenced user profiles and organization profiles must exist in the SharePoint instance. Ensure that the identity management solution is configured to ensure the following happens around exports of user profiles and organization profiles to SharePoint:
Customer support service by UserEcho