Create an entity without metadata by using the following process:
The first step in configuring an entity is to establish the entity type and determine the entity role.
To establish the entity type
The Create Entity dialog displays.
Note: Click Help for a description of fields, controls, and their respective requirements.
Indicates that you are creating an entity that is local to your site.
Indicates that you are configuring an entity that represents the partner at the remote site.
Select the asserting or relying party.
Select the token type, which defines the SAML format for the encrypted token that contains user credential information. Choose the Legacy option only if you want the token to comply with the SAML token type for WS-Federation 1.0.
After you have specified the entity type, configure the details of the entity. For a local entity, define the following information:
Follow these steps:
Click Help for a description of the fields.
The Confirm dialog is displayed.
Be aware of the following features:
If the Entity ID represents a remote partner, the value must be unique. If the Entity ID represents a local partner, it can be reused on the same system.
The Entity Name identifies an entity object in the policy store. The Entity Name must be a unique value. This value is for internal use only; the remote partner is not aware of this value.
Note: The Entity Name can be the same value as the Entity ID, but do not share the value with other entities at the same site.
For signing and encryption features, you must have the appropriate key/certificate entries in the certificate data store. If you do not have the appropriate key/certificate entries, click Import to import a private key/certificate pair from a file on your local system. You can also import trusted certificates.
Note: If you are using SAML 2.0 POST profile, signing assertions is required.
You can specify various service URLs and IDs for WS-Federation entites to communicate.
You can indicate the identifier types that the federated entity supports.
You can configure the asserting party to include specific assertion attributes when it generates an assertion. The recommended method is to define these attributes at the entity level. The entity serves as a template for the partnership so any assertion attributes you define for the entity get propagated to the partnership. The benefit of defining assertion attributes at the entity is that it enables you to use an entity in more than one partnership.
If you want to add or remove assertion attributes for the partnership, make such modifications at the partnership level, not at the entity level.
After you have specified the entity type, configure the details of the entity. For a remote entity type, define the following information:
Follow these steps:
https://www.google.com/a/example.com/acs
https://login.salesforce.com/?saml=EK05LGnm40H7
http://myserver.forwardinc.com:9080/samlsp/acs
Click Help for the field descriptions.
The Confirm dialog is displayed.
Be aware of the following features:
If the Entity ID represents a remote partner, the value must be unique. If the Entity ID represents a local partner, it can be reused on the same system.
The Entity Name identifies an entity object in the policy store. The Entity Name must be a unique value. This value is for internal use only; the remote partner is not aware of this value.
Note: The Entity Name can be the same value as the Entity ID, but do not share the value with other entities at the same site.
For signing and encryption features, you must have the appropriate key/certificate entries in the certificate data store. If you do not have the appropriate key/certificate entries, click Import to import a private key/certificate pair from a file on your local system. You can also import trusted certificates.
Note: If you are using SAML 2.0 POST profile, signing assertions is required.
You can specify various service URLs and IDs for WS-Federation entites to communicate.
You can indicate the identifier types that the federated entity supports.
You can configure the asserting party to include specific assertion attributes when it generates an assertion. The recommended method is to define these attributes at the entity level. The entity serves as a template for the partnership so any assertion attributes you define for the entity get propagated to the partnership. The benefit of defining assertion attributes at the entity is that it enables you to use an entity in more than one partnership.
If you want to add or remove assertion attributes for the partnership, make such modifications at the partnership level, not at the entity level.
Review the entity configuration before saving it.
Follow these steps:
A new entity is configured.
You can change an entity ID value for the remote entity from within the context of a single partnership configuration. However, changing the entity ID at the partnership level does not link the partnership to another entity, nor does it update the original entity. Modifications to an entity are a one-way propagation from the entity to the partnership. A change to the entity ID at the partnership level does not get propagated to the original entity.
Note: The entity ID you specify has to match what your remote partner is using.
Regard entity configurations as templates. Partnerships are created based on the entity templates so changing the partnership does not change the original entity template.
Refer to editing an entity from a partnership for more details about entities within a partnership.
Copyright © 2015 CA Technologies.
All rights reserved.
|
|