You manage authentication policies and settings on thescreen.
Select the IdP Authentication Policies check box if you
want to enable authentication policies for IdP Browser SSO requests,
adapter-to-adapter requests, and browser-based OAuth authorization code and
This check box is only visible when the IdP role is activated in thescreen.
(This check box is not selected by default.)
Select the SP Authentication Policies check box if you
want to enable authentication policies for SP-initiated Browser SSO requests
received by at the /sp/startSSO.ping endpoint.
This check box is only visible when the SP role is activated in thescreen.
(This check box is not selected by default.)Note:
Selecting the SP Authentication Policies check box does not enable authentication policies for IdP Browser SSO requests, adapter-to-adapter requests, and browser-based OAuth authorization code and implicit flows.
Select the Fail if policy engine finds no authentication
source check box if you want PingFederate to deny the
requests and to return an error message when the policy engine finds no
authentication source or authentication policy contract from the applicable
policies and none of the default authentication sources are
(This check box is not selected by default.)
Click Add Policy to create an authentication policy on
the Policy screen.
If you want to create a new policy based on an existing policy, select the Copy action.
- Enter a name and optionally a description of the policy.
Select an authentication source (an IdP adapter instance or an IdP
connection) or a selector instance from the
If you start this new policy by copying an existing policy, your new policy is pre-populated. Modify the policy to suit your new use cases.Tip:
When implementing your authentication requirements, think of authentication sources and selectors as checkpoints.
- For the
Adapter, IdP adapters developed using the
IdpAuthenticationAdapterV2interface from the PingFederate SDK (including the HTML Form Adapter), and SAML 2.0 IdP connections supporting the SP-initiated Browser SSO profile, you may specify a user ID to be passed in from an earlier-factor adapter.
- Click Options and follow the on-screen instructions to select the source and the attribute to be used as the incoming user ID.
- For any authentication source, you can optionally create one or more rules to define additional successful results. For example, if you want to deploy multifactor authentication using the PingID Adapter in stages by groups, you can create a rule to check for group membership information and only apply the PingID authentication flow to users who are members of certain groups.
- Click Rules and follow the on-screen instructions to manage your rules.
All results (including those based on rules) are displayed under the selected authentication source or selector instance. Each result forms a policy path.
For each policy path, select a policy action from the list.
- If additional processing is required, repeat step 4b.
- If the policy path is
extended from an authentication source and it is the end of the path, select
Done or Restart, which
marks this policy path
a closed-ended path.
A policy path is closed-ended if it contains one or more authentication sources (with or without any selector instances). A closed-ended path can optionally end with an authentication policy contract or a local identity profile.
If you need to reuse an authentication policy in multiple use cases, select an authentication policy contract or a local identity profile as the last policy action of a path, configure its contract fulfillment, and map the authentication policy contract to the applicable Browser SSO connections or OAuth grant-mapping configuration. Click ... Mapping underneath your selection and then follow the on-screen instructions to complete the contract fulfillment configuration.Note:
A policy path is also closed-ended if it ends with an instance of a custom authentication selector that returns an IdP adapter instance ID or the connection ID of an IdP connection. Because the custom selector returns an authentication source, such closed-ended path cannot end with an authentication policy contract or a local identity profile. (Instead, it must end with an action of Done or Restart.)
The Restart policy action provides users the opportunity to do over. When triggered, the policy engine routes the requests back to the first checkpoint of the invoked authentication policy. It makes most sense to use the Restart policy action for a Fail policy path if the policy engine can route the request differently based on user input prompted by an authentication source. For a sample use case, see step 5k in Enabling third-party identity providers.Note:
Undesirable looping behaviors can occur if you select Restart for the Fail path at the root of an authentication policy tree. PingFederate mitigates this risk by automatically limiting the number of policy restarts per transaction in maintenance releases 9.2.3, 9.3.3, and 10.0.3 or newer.
- If the policy path is
extended from a selector instance and it is the end of the path without any prior
authentication source, select Continue, which
leaves this path as an
open-ended path. Tip:
A policy path is open-ended if it contains only one or more selector instances (without any authentication sources). In this scenario, the policy engine continues to the next applicable authentication policy, if any.
Click Done to go back to the screen.
Your policy is enabled by default. As needed, toggle its status to disable the policy.
Repeat step 4 to create additional authentication
The order of authentication policies matters because the policy engine starts from the first policy and works its way down. As needed, reorder your policies by using the up and down arrows.
- If any individual policy is no longer required, select the Delete action or toggle its status to disable the policy.
screen, select one or more default authentication sources from
the list for the policy engine to fall back on when it finds no authentication
source from the applicable policies.Important:
Order matters because the policy engine starts from the first default authentication source on the list and works its way down. As needed, reorder your authentication sources by using the up and down arrows.
(There is no default selection.)
screen, add one or more HTTP request parameters to be tracked
throughout a request. Important:
For each instance of the HTTP Request Parameter Authentication Selector that you place in a policy as the second (or subsequent) checkpoint, add its configured HTTP Request Parameter Name value here. By doing so, the policy engine preserves the parameter it receives from the initial request and makes it available to the selector instance throughout the policy. For more information, see Configuring the HTTP Request Parameter Authentication Selector.
- Click Save.