After a service has been discovered and authorization data has been received from a trusted identity provider, the Web service consumer can invoke the service at the Web service provider. A Web service provider is the hosting or relying entity on the server side that can make access control decisions based on this authorization data and upon its business practices and preferences.
In the Administration Console click Edit > .
>Select one of the following actions
New: To create a new Web service, click
. This activates the Create Web Service Wizard. You can create a new profile only if you have deleted one.Delete: To delete an existing profile, select the profile, then click
.Enable: To enable a profile, select the profile, then click
.Disable: To disable a profile, select the profile, then click
.Edit a Policy: To edit the policy associated with a profile, click the Section 13.2.4, Editing Web Service Policies.
link. For configuration information, seeEdit a profile: To edit a profile, click the name of a profile. For information on configuring the details, see Section 13.2.1, Modifying Service and Profile Details for Employee, Custom, and Personal Profiles and Section 13.2.2, Modifying Details for Authentication, Discovery, LDAP, and User Interaction Profiles.
For information on modifying the description, see Section 13.2.3, Editing Web Service Descriptions.
The Identity Server comes with the following Web service profile types:
Authentication Profile: Allows the system to access the roles and authentication contracts in use by current authentications. This profile is enabled by default so that Embedded Service Providers can evaluate roles in policies. This profile can be disabled. When it is disabled, all devices assigned to use this Identity Server cluster configuration cannot determine which roles a user has been assigned, and the devices evaluate policies as if the user has no roles.
WARNING:Do not delete this profile. In normal circumstances, this profile is used only by the system.
Credential Profile: Allows users to define information to keep secret. It uses encryption to store the data in the directory the user profile resides in.
Custom Profile: Used to create custom attributes for general use.
Discovery: Allows requesters to discover where the resources they need are located. Entities can place resource offerings in a discovery resource, allowing other entities to discover them. Resources might be a personal profile, a calendar, travel preferences, and so on.
Employee Profile: Allows you to manage employment-related information and how the information is shared with others. A company address book that provides names, phones, office locations, and so on, is an example of an employee profile.
LDAP Profile: Allows you to use LDAP attributes for authorization and general use.
Personal Profile: Allows you to manage personal information and to determine how to share that information with others. A shopping portal that manages the user’s account number is an example of a personal profile.
User Interaction: Allows you to set up a trusted user interaction service, used for identity services that must interact with the resource owner to get information or permission to share data with another Web service consumer. This profile enables a Web service consumer and Web service provider to cooperate in redirecting the resource owner to the Web service provider and back to the Web service consumer.
Click
.On the Servers page, update the Identity Server.
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
, , 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:
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 13.6, 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 a 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. Locations in this list are 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 13.6, Mapping LDAP and Liberty Attributes.
Available Write Locations: The list of available locations to write attributes containing profile data. Locations in this list are 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 C.0, Data Model Extension XML for more information.
Click
, then click on the Web Service Provider page.Update the Identity Server.
This page allows you to specify information for Discovery, LDAP, and User Interaction Web service profiles. If you are creating a Web service type, this is Step 2 of the Create Web Service Wizard.
For conceptual information about profiles, see Managing Web Services and Profiles.
In the Administration Console, click Edit > > .
>Click
or , depending on which profile you want to edit.Configure the following fields:
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: (Not applicable for the Discovery profile) 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. This ID is encrypted with the public key of the resource provider generated at installation. Encrypting resource IDs is turned off by default.
Click
.All of the Description pages on each profile are identical. You can define how a service provider gains access to portions of the user’s identity information that can be distributed across multiple providers. The service provider uses the Discovery Service to ascertain the location of a specific identity service for a user. The Discovery Service enables various entities to dynamically and securely discover a user’s identity service, and it responds, on a permission basis, with a service description of the desired identity service.
In the Administration Console, click Edit > .
> >Click the profile or service.
Click
.Click the description name, or click
.Fill in the following fields:
Name: The Web Service Description name.
Security Mechanism: (Required) Liberty uses channel security (TLS 1.0) and message security in conjunction with the security mechanism. Channel security addresses how communication between identity providers, service providers, and user agents is protected. For authentication, service providers are required to authenticate identity providers by using identity provider server-side certificates. Identity providers have the option to require authentication of service providers by using service provider client-side certificates.
Message security addresses security mechanisms applied to the discrete Liberty protocol messages passed between identity providers, service providers, and user agents.
Select the mechanism for message security. Message authentication mechanisms indicate which profile is used to ensure the authenticity of a message.
X.509: Used for message exchanges that generally rely upon message authentication as the principle factor in making authorization decisions.
SAML: Used for message exchanges that generally rely upon message authentication as well as the conveyance and attestation of authorization information.
Bearer: Based on the presence of the security header of a message. In this case, the bearer token is verified for authenticity rather than proving the authenticity of the message.
Under
, select either or .Brief Service Access Method: Provides the information necessary to invoke basic SOAP-over-HTTP-based service instances without using WSDL.
EndPoint URL: This is the SOAP endpoint location at the service provider to which Liberty SOAP messages are sent. An example of this for the Employee Profile is [BASEURL]/services/IDSISEmployeeProfile. If the service instance exposes an endpoint that is different from the logically generated concrete WSDL, you must use the WSDL URI instead.
A WSF service description endpoint cannot contain double-byte characters.
SOAP Action: The SOAP action HTTP header required on HTTP-bound SOAP messages. This header can be used to indicate the intent of a SOAP message to the recipient.
WSDL Service Access Method: Specify the method used to access the WSDL service. WSDL (Web Service Description Language) describes the interface of a Web service.
Service Name Reference: A reference name for the service.
WSDL URI: Provides a URI to an external concrete WSDL resource containing the service description. URIs need to be constant across all implementations of a service to enable interoperability.
Click
.Update the Identity Server configuration.
Web Service policies are permission policies (query and modify) that govern how identity providers share end-user data with service providers. Administrators and policy owners (users) can control whether private information is always allowed to be given, never allowed, or must be requested.
As an administrator, you can configure this information for the policy owner, for specific service providers, or globally for all service providers. You can also specify what policies are displayed for the end user in the User Portal, and whether users are allowed to edit them.
In the Administration Console, click Edit >
> >Click the
link next to the service name.Click the category you want to edit.
All Trusted Providers: Policies that are defined by the service provider’s ability to query and modify the particular Liberty attributes or groups of attributes for the Web service. When All Trusted Providers permissions are established, and a service provider needs data, the system first looks here to determine whether user data is allowed, never allowed, or must be asked for. If no solution is found in All Trusted Providers, the system examines the permissions established within the specific service provider.
Owners: Policies that limit the end user’s ability to modify or query data from his or her own profile. The settings you specify in the
group are reflected on the My Profile page in the User Portal. Portal users have the authority to modify the data items in their profiles. The data items include Liberty and LDAP attributes for personal identity, employment, and any customized attributes defined in the Identity Server configuration. Any settings you specify in the Administration Console override what is displayed in the User Portal. Overrides are displayed in the column.If you want the user to have Write permission for a given data item, and that data item is used in an LDAP Attribute Map, then you must configure the LDAP Attribute Map with Write permission.
On the All Service Policy page, select the policy’s check box, then click
.This lets you modify the parent service policy attribute. Any selections you specify on this page are inherited by child policies.
Query Policy: Allows the service provider to query for the data on a particular attribute. This is similar to read access to a particular piece of data.
Modify Policy: Allows the service provider to modify a particular attribute. This is similar to write access to a particular piece of data.
Query and Modify: Allows you to set both options at once.
To edit child attributes of the parent, click the policy.
In the following example, child attributes are inheriting Ask Me permission from the parent
attribute. The attribute, however, is modified to never allow permission for sharing.If you click the
attribute, you can see that all of its child attributes have inherited the setting. You can specify different permission attributes for (for example), but the inherited policy still overrides changes made at the child level, as shown below.The interface allows these changes in order to simplify switching between configurations if, for example, you want to remove an inherited policy.
Inherited: Specifies the settings inherited from the parent attribute policy, when you view a child attribute. In the User Portal, settings displayed under
are not modifiable by the user. At the top-level policy in the User Portal, the values are inherited from the settings in the Administration Console. Thereafter, inheritance can come from the service policy or the parent data item’s policy.Ask Me: Specifies that the service provider requests from the user what action to take.
Always Allow: Specifies that the identity provider always allows the attribute data to be sent to the service provider.
Never Allow: Specifies that the identity provider never allows the attribute data to be sent to the service provider.
When a request for data is received, the Identity Server examines policies to determine what action to take. For example, if a service provider requires a postal address for the user, the Identity Server performs the following actions:
Checks the settings specified in
.If no solution is found, checks for the policy settings configured for the service provider.
Click
until the Web Service Provider page is displayed.Click
, then update the Identity Server as prompted.This page allows you to create a Web service profile type. This is Step 1 of the Create Web Service Wizard. Access Manager comes with several Web service profiles, but if you have deleted a profile type, you can create it again.
In the Administration Console, click Edit > >
>Select the Web service type from the drop-down list, then click
.Continue with one of the following: