The settings on the Details page are identical for the Employee, Custom, and Personal Profiles. This page allows you to specify the display name, resource ID encryption, and how the system reads and writes data.
In the Administration Console, click Edit > .
> > >Click either
, , or , depending on which profile you want to edit.Click the
tab (it is displayed by default).Specify the general settings, as necessary:
Display Name: The Web service name. This specifies how the profile is displayed in the Administration Console.
Have Discovery Encrypt This Service’s Resource Ids: Specifies whether the Discovery Service encrypts resource IDs. A resource ID is an identifier used by Web services to identify a user. The Discovery Service returns a list of resource IDs when a trusted service provider queries for the services owned by a given user. The Discovery Service has the option of encrypting the resource ID or sending it unencrypted.
Specify data location settings:
The following settings apply only to the Custom, Employee, and Personal Profiles.
Selected Read Locations: The list of selected locations from which the system reads attributes containing profile data. If you add multiple entries to this list, the system searches attributes in each location in the order you specify. When a match is found for an attribute, the other locations are not searched. Use the Up/Down and Left/Right arrows to control which locations are selected and the order in which to read them. Read locations can include:
Configuration Datastore: Liberty attribute values can be stored in the configuration store of the Administration Console. If your users have access to the User Portal, they can add values to a number of Liberty attributes.
LDAP Data Mappings: If you have mapped a Liberty attribute to an LDAP attribute in your user store, the values can be read from the LDAP user store. To create LDAP attribute maps, see Section 12.9, Mapping LDAP and Liberty Attributes.
Remote Attributes: If you set up federation, the Identity Server can read attributes from these remote service providers. Sometimes, the service provider is set up to push at set of attribute values when the user logs in. These pushed attributes are cached, and the Identity Server can quickly read them. If a requested attribute has not been pushed, a request for the Liberty attribute is sent to remote service provider. This can be time consuming, especially if the user has federated with more than one remote service provider.
should always be the last item in this list.Available Read Locations: The list of available locations from which the system can read attributes containing profile data. Any location in this list is currently not being used.
Selected Write Locations: The list of selected locations to write attribute data to. If you add multiple entries to this list, the system searches attributes in each location in the order you specify. When a match is found for an attribute, the other locations are not searched. Use the Up/Down and Left/Right arrows to control which locations are selected and the order in which they are selected.
Configuration Datastore: Liberty attribute values can be stored in the configuration store of the Administration Console. The Identity Server can write values to these attributes. If this location appears first in the list of
, all Liberty attribute values are written to this location. If you want values written to the LDAP user store, the location must appear first in the list.LDAP Data Mappings: If you have mapped a Liberty attribute to an LDAP attribute in your user store, the Identity Server can write values to the attribute in the LDAP user store. To create LDAP attribute maps, see Section 12.9, Mapping LDAP and Liberty Attributes.
Available Write Locations: The list of available locations to write attributes containing profile data. Any location in this list is currently not being used.
(Optional) Specify data model extensions.
Data Model Extension XML: The data model for some Web services is extensible. You can enter XML definitions of data model extensions in this field. Data model extensions hook into the existing Web service data model at predefined locations.
All schema model extensions reside inside of a schema model extension group. The group exists to bind model data items together under a single localized group name and description. Schema model extension groups can reside inside of a schema model extension root or inside of a schema model extension. There can only be one group per root or extension. Each root is hooked into the existing Web service data model. Multiple roots can be hooked into the same location in the existing Web service data model. This conceptual model applies to the structure of the XML that is required to define data model extensions.
See Section D.0, Data Model Extension XML for more information.
Click
, then click on the Web Service Provider page.Update the Identity Server configuration on the Servers page.