SAML 2.0 Local IdP Entity Dialog
Contents
casso127
HID_local-idp-entity
Contents
Configure SAML 2.0 Local IdP Entity
The Configure Local SAML 2.0 IdP Entity section lets you identify the entity. The settings include:
- casso127Entity IDIdentifies the federation entity to a partner. The Entity ID is a universal identifier like a domain name. If the Entity ID represents aremote partner,this value must be unique. If the Entity ID represents alocal partner,it can be reused on the same system. For example, if the Entity ID represents a local asserting party, this same ID can be used in more than one partnership.An Entity ID that represents a remote partner can only belong to a single active partnership.Value:URI (URL recommended)Note the following guidelines:
- The entity ID must be a URI, but an absolute URL is recommended.
- If the entity ID is a URL:
- The host part of the URL must be a name rooted in the organization's primary DNS domain.
- The URL must not contain a port number, a query string, or a fragment identifier.
- Do not use the ampersand (&) in the Entity ID because it is recognized as a separate query parameter.
- Do not specify a URN.
- The entity ID for a remote partner be globally unique to avoid name collisions within and across the federation.
Examples of Valid Entity IDs- CompanyA:portal1
- http://idp_name.forwardinc.com/idp
- https://idp_name.example.edu/sp
Examples of Invalid Entity IDs:Entity NameNames the entity object in the policy store. The Entity Name must be a unique value. Federation uses the Entity Name internally to distinguish an entity at a particular site. This value is not used externally and the remote partner is not aware of this value.Note:The Entity Name can be the same value as the Entity ID, but the value is never shared with any other entity at the site.Value:An alphanumeric stringExample:Partner1DescriptionSpecifies additional information to describe the entity.Value:Alphanumeric string up to 1024 characters.Base URLSpecifies the base location of the server that is visible to the intended users of the federation. This server is typically the server whereCA Single Sign-Onis installed. However, the server can be the URL of the server that hosts federation services, such as the Single Sign-on service. The base URL enablesCA Single Sign-Onto generate relative URLs in other parts of the configuration, making configuration more efficient.You can edit the Base URL. For example, you can configure virtual hosts for theCA Single Sign-Onsystem. One virtual host handles the UI communication. The other virtual host handles the user traffic that the embedded Apache Web Server processes. You can edit the Base URL to point only to the server and HTTP port of the Apache Web Server.Value:valid URLExample:https://fedserver.ca.com:5555Note the following important guidelines for modifying this field:If you modify the base URL, do not put a forward slash at the end of the base URL. A final slash results in two slashes being appended to other URLs that use this base URL.If you are using more than oneCA Single Sign-Onfor failover support, set this field to the host name and port of the system managing failover to the other systems. This system can be a load balancer or proxy server.
Default Signature and Encryption Options
The Default Signature and Encryption section defines the signing and encryption behaviors for federated communication. The section contains the following settings:
- Signing Private Key Alias(Optional) Specifies the alias that is associated with a specific private key in the certificate data store. This field indicates which private key the asserting party uses to sign assertions, assertion responses, single logout requests, and single logout responses. If the key you want to use is not in the certificate data store, clickImportto import it before proceeding.Value:Selection from the drop-down list
- Signed Authentication Requests RequiredIndicates that AuthnRequest messages are required to be signed for acceptance. If you select this checkbox, the asserting party cannot send unsolicited responses.
Supported Name ID Formats and Attributes (SAML 2.0)
casso127
casso127
The Supported Name ID Formats and Attributes section allows you to specify the Name ID formats that the entity support. Additionally, for an Identity Provider it indicates the attributes to add to an assertion.
The Name Identifier names a user in a unique way in the assertion and specifies which attributes to include in the assertion. The format of the Name Identifier establishes the type of content that is used for the ID. For example, the format can be the User DN, in which case the content can be a uid.
Attributes added to an assertion can further identify a user and enable an application using the assertion to be customized for each user.
- Supported Name ID FormatsLists all the Name ID formats that the entity supports. Select all the formats that apply.For a description of each format, see theAssertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0specification.
- Supported Assertion Attributes (local and remote IdP)Specifies the attributes that the asserting party includes in the assertion. The table includes the following columns:
- Assertion AttributeIndicates the specific user directory attribute that is included in the assertion.Value:Name of a valid user directory attribute
- Supported FormatDesignates the format of the attribute.Options:Unspecified, Basic, URI