Glossary

The number of hours during which an access token is valid. SecureAuth IdP generates an authorization code that is given to the client application. The application then requests an Access Token that is subsequently generated by SecureAuth IdP and given to the application. The authorization code is then discarded when the Access Token is received.

The Public Key of the Assertion Consumer Service (ACS) / SAML Request Certificate in Base64 format to enable SecureAuth IdP to accept a SAML assertion.

NOTE: The default page in the IIS Management Console must also be changed to SAML20idpinitACS.aspx for SecureAuth IdP to consume the SAML assertion.

What happens automatically when the user does not pass the User Risk analysis. This can be one of the following:

Allow the help desk to reset users' passwords using SecureAuth's IdM API.

SecureAuth IdP checks if the current account is locked or enabled, and verifies if the current password needs to be changed. If any of these checks fail, the user cannot to log in.

A list of the groups that are only allowed access to this realm.

A list of groups granted permission to view and download this application from the Mobile App Store.

Enable the administrator to search the directory for users without supplying the username and/or password.

The appliance's Globally Unique Identifier (GUID) assigned by SecureAuth.

The Fully Qualified Domain Name (FQDN) of the Operating System (OS) for the SecureAuth IdP appliance instance.

The application description is for internal use only. It appears beneath the Application Name on the Summary Page in the Identity Platform. In the Advanced Settings / Classic Experience, it appears beneath the Page Header on the realm tile and in the realm list on the Web Admin. Administrators can write notes here to provide instructions or to briefly describe the purpose of the application / realm.

This displays in the left-side menu, under the Document Title.

A unique ID that is required for a custom application to make calls to SecureAuth's Authentication API.

A unique key value that is required for a custom application to make calls to SecureAuth's Authentication API.

The name of the data store “section” in which users can be found. By default, this is "/".

The application name appears in the Application Manager list and as the title on the browser tab in the Identity Platform. In the Advanced Settings / Classic Experience, it appears on the admin side as well as the client side. On the admin side, this will be the header on the realm on the startup page, and will appear in the left-side menu under the Realm Name.

The application name as it will appear in the Mobile App Store.

The application name (target resource of the realm; for example, Salesforce) that appears on the Push-to-Accept login request.

A list of allowed applications or denied applications.

Application templates are third-party application integrations that SecureAuth Identity Platform supports in cloud and hybrid deployments.

The URL provided by the Service Provider which is used to accept a SAML assertion.

Click the certificate link to download the public key certificate. This matches the company's private key certificate for appropriate assertion, and is sent to the SP to enable the integration.

The specific name of the attribute. The SP requests which attributes are required and the exact names.

An optional value that is provided by the SP, and is the base domain of the application.

Each audit log records all authentication events for each realm user and can be reviewed to check for any inconsistencies.

Provides a multi-factor authentication method for end user validation during the login process after the app is installed on a mobile device or Chromebook and then connected to the user profile.

The target action of the realm. For example, where users are sent after they are authenticated.

The method used to authenticate the subject. This can be one of the following options:

The method used to the authenticate the user. This can be one of the following options:

The authentication workflow. Each mode varies in security strength and user-friction. This can be one of the following options:

The endpoint used to retrieve the authentication cookie that is appended (relative) to the Base URL. This is only applicable if Authentication Method is set to Cookie.

The percentage that the user's fingerprint (FP) ID must be higher than for a successful 2-Factor Authentication. If the user's FP ID is lower than the threshold value, another form of 2-Factor Authentication is required, such as SMS OTP, Telephony OTP, PUSH Notification, or OATH Token.

This is typically set between 90 - 100%, and must be higher than the Update Threshold.

Additional authentication proof that may be requested by the SP.

The SP asks for certain Authentication Context Classes, which are categories that carry Authentication Context declarations (requested additional authentication information) and simplify the interpretation between SecureAuth IdP and the SP.

SecureAuth IdP, as the authorization server, creates an authorization code after the user authenticates that is presented to the client application. The client application then requests an access token, which is then generated by SecureAuth IdP to grant the user access.

The number of minutes during which an Authorization Code is valid. The client uses the Authorization Code to request an Access Token. If the Authorization Code expires, then the workflow restarts to generate a new one.

Whether users are prompted to grant consent to a client for a given request, or if acceptance is assumed granted and tokens are issued.

Whether the client application must request consent to access data or if it can bypass the step and automatically pull information for access. The remaining fields in the OpenID Server section are the information that the application can pull with or without consent, based on the selection made.

Enable SecureAuth IdP to auto-submit a 2-Factor option response when a user has only one option available.

The SecureAuth IdP Auxiliary Properties that are mapped to directory fields containing user information.

The root URL of the User Risk integration instance. For example, Sailpoint or Exabeam.

The Bearer token value, which is like a shared secret, that is used for authentication.

This is only applicable if Authentication Method is set to OAuth 2.0.

If True is selected from the Require Begin Site field, then select the type of Begin Site that is required for this realm. The options are:

The URL on which users land before the SecureAuth IdP login pages. This is auto-populated when a pre-configured Begin Site is selected from the Begin Site field, or can be a customized URL when Custom is selected.

The number of minutes during which SecureAuth IdP disables the use of Time-based Passcodes tokens for a locked account.

The number of certificates stored in a user's profile.

The basis on which the certificate expires. The options are:

The hashing algorithm used for certificate signing requests. The options are:

The certificate URL which is auto-populated if using WSE 3.0. If using WS 2.0, this must be set with SSL.

Whether SecureAuth IdP utilizes the message-level security (WSE 3.0 / WCF) or the transport-level security (WS 2.0 with SSL) to make a web service call to issue a certificate. Set to False if using a Proxy.

For how long the certificate is valid. The options are:

Revoke the certificates stored in a user's profile.

The licensing certificate of the appliance.

The challenge question used for the Help Desk 2-Factor Authentication method. When users employ the Help Desk mechanism, the admin asks a knowledge-based question to the user to validate the identity before providing a one-time password (OTP). See also KB Questions.

The Change Password Stored Procedure (SP) name in the database.

The action taken if Certificate Revocation List checking is enabled. The options are:

Additional profile data that is sent to client applications within the JSON Web Token (JWT). The listed Claims are options that would be requested by the client application. If an unlisted Claim needs to be included, you can add it in the Custom Claims section.

Whether or not to remove the Pre-Auth Cookie after authentication.

The certificate serial number of the SecureAuth IdP appliance to identify itself to the hosted facility when making the WSE 3.0 / WCF web service request.

Enable communication between the client application and SecureAuth IdP utilizing the Client ID and the Client Secret.

Enable an enterprise to set a Fully Qualified Domain Name (FQDN) as the client point of termination for SecureAuth IdP validation.

The Client ID of the Native Client Application (configured on Azure AD).

The Client ID is created automatically by SecureAuth IdP to be shared with the client application for authorization. This is similar to a user ID.

The Client ID assigned by Facebook / Google / Windows Live / LinkedIn to the user's application.

The Client Secret is created automatically by SecureAuth IdP to be shared with the client application for authorization. This is similar to a password.

The shared secret assigned by Facebook / Google / Windows Live / LinkedIn to the company's application.

The credential used in the realm workflow for the user. The options are:

The number of minutes that SecureAuth IdP subtracts from the NotBefore SAML condition to account for any time difference between SecureAuth IdP and the Identity Provider.

The company's Globally Unique Identifier (GUID) assigned by SecureAuth present on all company's SecureAuth IdP appliances.

How SecureAuth IdP and the directory connect. The options are:

How SecureAuth IdP communicates with LDAP or Active Directory data stores and is built from the domain name and auto populated by clicking Generate LDAP Connection String.

The Oracle Database connection string, which is used to enable communication between the database and SecureAuth IdP. It should be in the following format with the company's own values:

Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1522)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=[DBName]))); User Id=[username];Password=[password]

The SQL / ODBC / ASPNETDB connection string, which is used to enable communication between the data store and SecureAuth IdP. It is generated by clicking Generate Connection String, which utilizes the information provided in the previous fields; or check Custom Connection String to create a custom connection string.

How SecureAuth IdP communicates with LDAP or Active Directory data stores and is built from the domain name.

The SQL / ODBC / ASPNETDB connection string, which is used to enable communication between the data store and SecureAuth IdP. It is generated by clicking Generate Connection String, which utilizes the information provided in the previous fields; or check Custom Connection String to create a custom connection string

How SecureAuth IdP communicates with the database logs. This field is auto-populated by clicking the Generate Connection String button.

The number of seconds permitted to query the log database and generate the results on the Reporting Page before the connection times out.

Specifies how the service provider will send the authentication request to SecureAuth IdP, either SP- or IdP-initiated.

This configuration can't be modified in the Advanced Settings / Classic Experience.

The company's enterprise data store. The options are:

Client applications request to access certain information from the user's profile in the data store. The user must consent to these requests before continuing the workflow.

Determine which SecureAuth IdP Property stores the user's consent to avoid requesting it with every login. This consent can be revoked in the directory at any time.

The number of hours during which the cookie is valid.

To where users are redirected when an error occurs if On or Remote Only is selected from the Custom Errors field.

Redirect users to a different page when an error occurs rather than the defaulted error page that the webpage provides.

The URL scheme of the native mobile app. For example, app1:/. Applicable for multi app and multi app groups check integrations only.

Intelligence dashboard provides real time visibility to key metrics, insights into total number of logins, and a break down of logins by system, applications, data stores, and use of multi-factor method options.

How the information is stored in a data store. The options are:

The data store from which to pull profile information.

The SecureAuth IdP Property that includes the attribute required. The options are Data Store properties which point to fields in the directory. This information is provided by the SP as it expects the attribute to be delivered a certain way.

Used to simplify the user ID for logging in. For example, set to DC=com,DC=local to make the user ID domain/username rather than the full name.

Debug logs can record database operations, system processes, and errors that occur during the authentication workflow, and can be reviewed to check for any inconsistencies.

The Decryption Key is stored in the web configuration file and must match the decryption key on the client application for SSO.

The delimiter is used with the Shared Secret to encrypt the user ID, and is typically a symbol, such as a colon, semicolon, or quotation mark.

A list of the groups that are denied access to this realm.

A list of groups not granted access to view or download the application from the Mobile App Store.

SecureAuth IdP can collect client-unique information (digital fingerprints) from the end-user's device or browser and store it in the user profile in the directory. When the end-user utilizes the same device (or browser) to log in to SecureAuth IdP again, the current client-unique information (a new fingerprint) will be collected and compared with the previously registered fingerprint(s) for authentication. If one existing fingerprint matches the current fingerprint with an acceptable Authentication Threshold score, then the end-user will not be required to undergo additional 2-Factor Authentication (OTP).

The list of keywords that cannot be used.

For some target resources, such as the Secure Portal, the user's name can be displayed on the page. Administrators then select which username will be displayed from the dropdown provided.

The following options correspond to the attributes mapped to the SecureAuth IdP Properties in the Data tab:

These options are created from factors other than or in addition to the SecureAuth IdP Profile mapping:

How to alert the user when their session has expired. The options are:

The SecureAuth IdP Property that contains the distinguishedName (DN).

The document title is shown on the admin side as well as the client side. On the admin side, this will be the header on the realm on the startup page, and will appear in the left-side menu under the Realm Name.

On the client side, this will be displayed on the browser's tab.

The domain name of the directory.

Auto-populated by the information from the Create using this realm and Workflow Options fields, and contains a list of the workflow realm domain names.

The domain name if the SMTP requires one for authentication purposes.

The domain name. The administrator can combine realms by entering a common domain name that generates a valid token that can work in different spaces (SSO). If this field is blank, the appliance domain becomes the default.

The domain of the SecureAuth IdP application. The full URL of the Public Server Address is required to download the Metadata File.

Select the type of authentication option(s) available for use for the email addresses mapped to the Email 1 - Email 4 Properties in the Data tab.

Send a generic email to the user after a successful creation has been completed.

Enable a Windows service email notification system that warns users of certificate expiration.

The SecureAuth IdP Property that is mapped to the attribute that contains the Google Apps Email password.

Enable administrators to disable active user accounts, or enable disabled user accounts from the Help Desk page.

Enable or disable the appliance calling the SecureAuth Web Services to gather information.

Enable Base64 encoding of the username. This is necessary if the SP requires it.

The ID that SecureAuth IdP uses to search the directory for the user.

The public key provided by the SP. The SP keeps and maintains the private key.

For Java products only. When users enter their passwords, the passwords are encrypted using the Java Applet and sent to the SecureAuth IdP server as an encrypted string rather than as plain text.

For additional security, enable SecureAuth IdP to encrypt the SAML assertion that is sent to the SP.

Encrypt the token sent from SecureAuth IdP to the application that contains the authenticated user ID and other profile attributes. Applicable for single and multi app integrations.

Error logs record all warnings and errors during the authentication workflow, and can be reviewed to check for any inconsistencies.

The URL for the company's end-user license agreement.

Enable email notifications that warn users that their certificates will expire.

The format in which the Extended Attribute is delivered to the SP.

The SP expects the Extended Attribute to be delivered a certain way to provide the appropriate response. The options are:

The specific name of the Extended Attribute. The SP specifies which attributes are required, and the name must match the name specified by the SP.

For IP Reputation / Threat Data analysis, select specific Failure Actions for each risk level, based on the generated risk score.

In case of a system failure, SecureAuth IdP can seamlessly switch to a configured backup server to prevent disruptions in service.

What happens automatically when the user does not pass the specific Adaptive Authentication analysis. The options are:

The Firefox Java Runtime Environment (JRE) Plugin URL.

The Firefox Plugin URL.

The field from the enterprise data store where the requested properties are located. SecureAuth IdP includes some common out-of-the-box Active Directory values; however, the data may be located in different fields.

How many of the Show Enabled fields are required to be filled out by the user on the Self-service Account Update page.

If a web page is utilizing an iFrame, then enable the SecureAuth IdP webpages to break out into its own page rather than staying within the first web page.

A client-side link that takes users to the Forgot / Reset Password realm, which can be configured in the Post Authentication tab. Here, users can retrieve lost passwords securely.

A client-side link that takes users to the Forgot Username realm, which can be configured in the Post Authentication tab. Here, users can retrieve lost usernames securely.

The number of days the fingerprint is valid. For example, if the expiration length is set to 10 days, then the user's fingerprint expires in 10 days, no matter how often it is used.

The number of days the fingerprint is valid since last usage.

For example, if this is set to 10 days, then the user's fingerprint expires if it is not used during the 10 days since it was last employed.

Elect whether to deliver a cookie to the device or browser, or to pull unique IDs from the mobile devices using the SecureAuth Device Recognition App (iOS and Android mobile app) and deliver them to match the fingerprint (FP) ID in the directory.

Elect whether to deliver a cookie to the browser that corresponds to the fingerprint (FP) in the data store.

The number of Fingerprint (FP) entries to save to each stored fingerprint profile.

Geo-velocity analyzes the user's location based on the initial and subsequent IP Addresses and computes physical speed calculated from the difference between the two IP Address locations.

For example, if a user logs in from New York and then logs in an hour later from China, SecureAuth IdP automatically responds with an appropriate Failure Action if the calculated velocity is greater than the MPH (miles per hour) Limit.

The endpoint used to get user profiles that is appended (relative) to the Base URL.

The Get Profile Stored Procedure (SP) name in the database.

The Shared Secret that is sent to SecureAuth IdP, which is provided by the Service Provider (SP).

The Get User Stored Procedure (SP) name in the database.

Limit the number of certificates that a user can have active in the directory. Once the user has surpassed the limit, the user needs to call Help Desk to resolve the issue.

Limit the number of mobile cookies that a user can have that are active in the directory. Once the user has surpassed the limit, the user needs to call Help Desk to resolve the issue. Applicable for Mobile Enrollment and Validation realms.

The groups to which the user belongs.

Filter the Extended Attribute value(s) by including groups that match the specified regular expression, such as "sp-*". Instead of sending over all of the group names, this RegEx enables SecureAuth IdP to send over only those that match the pattern.

Further filter the attribute by including groups that start a certain way, such as "sp-*". Instead of sending over all of the group names, this RegEx enables SecureAuth IdP to send over only those that are necessary.

The list of groups to which the user belongs.

The list of user groups that are either allowed or denied based on the selection made from the dropdown.

The list of user groups that are allowed or denied access based on the selection from the Validation Type field. Applicable for multi app and multi app groups check integrations only.

The field in the directory that corresponds to a user's groups.

The Help Desk (Account Management) Page enables administrators and help desk teams to modify and update user profiles.

The risk score range that classifies as high risk.

The components of HTTP Headers that factor into the device fingerprint. Set the weight values for each HTTP Header component and for the System Components to equal a total of 100%.

The workflow that is a combination of the Authorization Code and Implicit workflows that allows to request a combination of identity token, access token and code via the front channel using either a fragment encoded redirect (native and JS based clients) or a form post (server-based web applications).

A friendly name that appears in the Web Admin for future reference.

The boundaries within which a user needs to interact with the site before the session is expired and needs to be re-authenticated.

The SAML ID of the Identity Provider (IdP). This can be any value as long as it's consistent on both sides, as the Issuer must match on the IdP and SP side exactly.

The Internet Explorer (IE) ActiveX version number.

The Internet Explorer Java Runtime Environment (JRE) Plugin URL.

The certificate types based on the selection from the Client Side Control field.

Redirect users to different realms if SecureAuth IdP detects a mobile or a web browser. Select the SecureAuth IdP Realm configured specifically for mobile browsers to where users are redirected if using mobile devices.

The workflow that enables SecureAuth IdP to generate an access token immediately after user authentication (without an authorization code) that is given to the client application.

Enable SecureAuth IdP to provide certificates that are requested by an application. For example, MobileIron VSP.

Enable SecureAuth IdP to include SAML conditions in the SAML assertion. The SP requests this if it is necessary.

The database name when the connection is opened.

The name of the logging database.

Redirect users to the self-service page to provide missing information, and then redirect them back to the Post Authentication action once the data has been provided.

Check the options for which Inline Initialization is enabled:

Elect whether users can change their expired passwords during the workflow.

Enable the use of the IIS app pool's service account for connection to the database and is a part of the connection string.

Enable the use of the webpage's ID for connection to the database and is a part of the Connection String.

The device limitation and functionality of the client. The options are:

The workflow in which a previously-issued access token (from SecureAuth IdP) is sent to the Introspection endpoint at which SecureAuth IdP states whether it is still valid, along with expiration and scope information.

To where users are redirected if their persistent token is invalid. For example, another realm.

List of the allowed or denied IP Addresses that is based on the IP Address Rule selected.

Create a list of allowed IP Addresses or denied IP Addresses.

Block IP Addresses by country by using the Configure IP Blocking setting.

The IP Blocking URL that is auto-populated if using WSE 3.0, but must be set if using WS 2.0 with SSL.

Whether SecureAuth IdP utilizes the message-level security (WSE 3.0 / WCF) or the transport-level security (WS 2.0 with SSL) to make a web service call to retrieve IP-to-Country data.

Allows or denies specific IP Addresses or country codes from accessing the realm.

The list of IP Addresses that are either allowed or denied based on the selection made from the dropdown.

The final IP List can be: 72.32.245.182,72.32.245.0/24,72.32.245.1-72.32.245.254

Utilizes threat intelligence system to detect risk, sent in a Risk Level Score.

Enable IPSec Profile Update to add IPSec Profile / Host Pairs.

The certificate serial number provided by Symantec.

The number of hours during which the SAML assertion to SecureAuth IdP is valid. Applicable if not enabling SAML Conditions.

The name of issuer that must be unique and is commonly in a URL format. This name displays in the iss claim within the JSON Web Token (JWT).

The Java Applet version number.

The Java Applet for Java Runtime Environment (JRE) 7 version number.

The Java Applet for Java Runtime Environment (JRE) 8 version number.

Applicable when SecureAuth IdP fails to launch the Java Applet. From here, elect whether the user falls back to Public Mode, Universal Browser Credential Mode, Cookie Mode, or the user is denied access.

How long SecureAuth IdP waits for the Java Applet to initiate.

Enable SecureAuth IdP to check for Java presence.

Set the security level for the certificate storage. If set to zero (0), then a certificate can be transferred from one system to another; if set to four (4), then the certificate cannot be copied at all.

Add time to wait for Java to respond. If no Timeout is set, or if Java does not respond during the allowed time period, then an error is presented.

The Java Runtime Environment (JRE) 7 version number.

The Java Runtime Environment (JRE) Installation path, where SecureAuth IdP looks to retrieve the JRE if it is not already on the client machine.

The Java Runtime Environment (JRE) version number.

Enable the encryption of JSON Web Tokens (JWTs). This feature requires that the client requesting the encrypted JWTs to provide the X.509 public key via a JSON Web Key URI.

The URL at which the JSON document that is published with the public key information can be accessed. Applicable if Enabled is selected from the JSON Web Encryption field.

Enable SecureAuth IdP to convert knowledge-based questions to certificate-based encryption from Base64 encoding.

How the knowledge-based questions and answers are formatted and stored in the directory. The options are:

The number of knowledge-based questions to display. The user is not required to answer all; the required field are set in the Number of Answers field.

The user's knowledge-based questions and answers used for 2-Factor Authentication.

KB (knowledge-based) Questions lets a Help Desk staff member verify an end-user's identity by asking a question only that user can answer. See also Challenge Question.

The shared secret for the encryption key that enables communication between SecureAuth IdP and the SP. The Key Value must match on both sides.

For the Native Certificate Enrollment Page, select the action to be taken after the enrollment is finalized.

Select the realms to which the Portal Page points. SecureAuth IdP then creates hyperlinks for the realms that are checked to be displayed on the Portal Page.

The URL link for the Enrollment Complete Page if Custom URL is selected from the Link Function / Behavior field.

The Live Site ID provided by Microsoft in the welcome email.

Where the user lands after authentication. Possible destinations are:

Lock user accounts upon reaching the maximum number of failed authentication attempts.

The Lock User Stored Procedure (SP) name in the database.

Adds SecureAuth’s multi-factor authentication to the Windows and Mac desktop and remote server login experience after the application is installed.

For how long the Push-to-Accept login request is valid for the user to accept or deny.

The number of seconds allowed between the SecureAuth IdP authentication session and the Live@Edu session. It is defaulted to 5 seconds.

Used to mark log sets that are associated with this realm. Typically, it is the same name as the realm (SecureAuth1, SecureAuth2, etc.).

The page where the user is sent when the token has expired and a new one needs to be created. For example, another SecureAuth IdP realm.

The risk score range that classifies as low risk.

The name of the Lightweight Third-Party Authentication (LTPA) Token, used for access into Domino and Lotus Notes. The SP provides the Token Name.

Elect to hide the password.

Require the fingerprint ID from the cookie to be presented and then matched to a fingerprint ID in the directory, with an acceptable Authentication Threshold score.

Limit the number of devices that can receive Push Notifications and Push-to-Accept login requests. For no limit, set to -1.

The maximum number of failed password entries a user is allowed before the account is locked.

The maximum number of characters of which the knowledge-based answers can be composed.

The maximum number of digits of which a one-time passcode can be composed.

The maximum number of characters of which a password can be composed.

The maximum number of characters of which a user ID / username can be composed.

The risk score range that classifies as medium risk.

The Metadata File is essentially what makes SAML work, and enables the secure transaction between SecureAuth IdP and the SP. Download the SAML Metadata File to upload it to the SP for automated configuration.

The amount of hours during which the Mobile certificate is valid. Applicable for Mobile Enrollment and Validation realms.

Common keywords that are used to identify mobile devices and browsers. SecureAuth IdP searches for these values in headers and would then redirect the user to realm selected from the Web / Mobile Transfer Site field.

NOTE: The IIS URL rewrite located in the IIS Management Console can also be utilized to configure this function.

Revoke mobile tokens / cookies stored in a user's profile.

The integration of multiple native mobile applications in a single realm with the same workflow, directory integration, registration methods, etc.

Enable the email notifications to notify users of all certificates.

The multi-workflow realms created by the information provided, and is auto-populated.

Require the user to change the password entered in the previous field on next login.

Select whether the user must change the password on the next attempted login. This is useful when using Administrative Password Reset to change it from the randomized password to one that the user selects.

Using the remaining Password Complexity section fields, specify which character sets must be used to create passwords. For example, if 2 is set, then the password must contain at least one (depending on the requirements listed in each of the fields) digit, symbol, uppercase letter, or lowercase letter, and at least one (1) of the characters not used for the first requirement, e.g. P@SSWORD (at least one uppercase letter and one symbol); if 4 is set, then the password must contain at least one (depending on the requirements listed in each of the fields) digit, symbol, uppercase letter, and lowercase letter, e.g. P@ssW0rd (at least one uppercase letter, one symbol, one lowercase letter, and one digit).

Send the First Name and Last Name attributes in the token (and query string) to the application.

Metadata that describes the format in which the content contained in the User ID Mapping field is being asserted by SecureAuth IdP, specified by the SP. The options are:

An auto-populated name generated by SecureAuth IdP.

The name of the token.

The name of the Mobile Browser Token, which can be set to anything. When a user is logging in from a mobile browser, SecureAuth IdP searches for the name entered here.

The title of the client.

A user-friendly title for the scope that displays on the client-side consent page.

The specific name of the attribute. The SP requests which attributes are required and the exact names.

Communicate to the SP which attribute is being sent over, and is in the form of a URL. The SP should provide the exact Namespace if it is required.

The user profile / risk score information is not found in the User Risk integration database.

How often the email notifications are sent. the options are:

The time of day at which the notifications start.

The number of knowledge-based questions the user must answer on the page. The value set here must be less than or equal to the KBQ Count selection.

How many passwords SecureAuth IdP remembers to ensure that the new password is not the same.

The number of knowledge-based questions asked during the 2-Factor Authentication login process.

The type of App Enrollment / OATH provisioning utilized by the application(s).

The unique identifier name for the account.

Whether SecureAuth IdP generates a new seed for every provisioned device. If set to true, this disables the OATH usage on the previously provisioned device. If set to false, this enables SecureAuth IdP to reuse the same seed for each provisioned device and enables the use of multiple devices simultaneously.

Enable a one-time use PIN that is immediately cleared from the user directory once it is used for 2-Factor Authentication. New users commonly use this for self-service 2-Factor enrollment.

Whether only one fingerprint (FP) cookie is allowed per browser.

Enable the user's PIN to be displayed in the directory as plain text.

Select what user information is validated.

The number of digits used in one-time passwords (OTPs) for 2-Factor Authentication.

The password that corresponds to the p12 file obtained from the Google Apps Client ID creation (provided by Google).

The title that displays at the top of the client-side webpages, and is typically the same as the Document Title.

A Windows and Mac desktop application that generates one-time passcodes (OTPs) to use for validation during the login process.

The number of seconds during which the Time-based Passcode is valid. After the provided amount of seconds has passed, that OTP no longer works for the 2-Factor Authentication session.

How many digits the Time-based Passcode is for 2-Factor Authentication.

A rolling time-frame window of minutes during which the OTP is valid, which allows for time differences between devices and servers.

The number of days from the last password change that the password is valid. Surpassing this amount, the password expires.

How the password is stored. This selection also dictates which Password Stored Procedure (SP) to use.

How the SQL Database password is stored in the directory.

The minimum length of characters passwords must be.

The mode in which users can reset their passwords.

A unique string of text to append to passwords before they are hashed. Not applicable if Clear is selected in the Password Format field.

The type of password being synchronized to the iOS device(s) for provisioning.

The amount of days before expiration during which users are warned about their password expiration. Applicable for the Inline Password Change feature.

Set the timeout of the token.

Allow access to username and password information once the connection is open, and is part of the connection string.

Send the Phone 1 - Phone 4 attributes in the token (and query string) to the application.

Select the type of authentication option(s) available for use for the phone numbers mapped to the Phone 1 - Phone 4 Properties in the Data tab.

Modify how much of the phone number is masked. By default, SecureAuth IdP displays phone numbers in the following way: xxx-xxx-1234.

The user's static Personal Identification Number (PIN).

Enable users to utilize a Personal Identification Number (PIN) for 2-Factor Authentication.

Return the users' profile attributes to the application in a query string, in addition to the token sent.

Return the users' groups to the application in a query string, in addition to the token sent.

The SMTP's required port, and by default, it is set to Port 25.

Select if and how the Portal Page is accessible.

The cookie that communicates to SecureAuth IdP that the user has been authenticated. This can be set to point to a specific realm so that the administrator knows where the user's identity was validated. Single Sign-on (SSO) is achieved with this cookie.

A generic URL for any Post Authentication module to use if an additional web service call is required to complete the Post Authentication action.

The Form Post information created from the URL and Create Post information.

The cookie generated from a Begin Site. SecureAuth IdP checks to see if there is a Pre-Auth Cookie present; and if there is, then SecureAuth IdP extracts the user ID from the token and proceeds with the login process. If the Pre-Auth Cookie is not present and Require Begin Site is set to True, then SecureAuth IdP sends the user back to the Begin Site to acquire the Pre-Auth Cookie.

The Private Enterprise Number (PEN) of the Syslog server.

Which password is used to protect the profile for the iDevices and for Android device keys.

If Private Mode is selected during the login workflow, this field determines the number of days during which the private mode certificate is valid.

The SecureAuth IdP Profile Property that contains that user's User Risk Score (written to by the User Risk integration).

To where users are redirected if their profile is missing. For example, profilemissing.aspx.

The properties used by SecureAuth IdP. Based on the responses provided, SecureAuth IdP pulls and sends the information that corresponds to the directory fields for authentication and assertion purposes. The administrator can dictate what data is paired with which property, but SecureAuth IdP includes some out-of-the-box AD examples based on common practices.

An auto-populated name generated by SecureAuth IdP.

The IP Addresses of load balancers, gateways, proxies, or other devices in between the user and SecureAuth IdP to enable the appliance to identify the device to read the header.

The Password associated to the Proxy Username of the proxy account required only if the proxy requires authentication.

The IP Address or the Fully Qualified Domain Name (FQDN) of the Proxy Server.

The TCP Port on which the proxy server is configured to respond.

The Username of the proxy account required only if the proxy requires authentication.

The Public IP Address if the Network Address Translation (NAT) is used to change the SecureAuth IdP IP Address to a Public IP Address.

If Public Mode is selected during the login workflow, then this field sets the number of hours during which the certificate is valid. Applicable for Certificate Enrollment Only realms.

The options provided to users on the page when logging in.

The Push URL that is auto-populated if using WSE 3.0, but must be set if using WS 2.0 with SSL.

Whether SecureAuth IdP utilizes the message-level security (WSE 3.0 / WCF) or the transport-level security (WS 2.0 with SSL) to make a web service call to make a Push Notification request. Select False if using a Proxy.

The realm description is for internal use only. Administrators can write notes here to provide instructions or to briefly describe the purpose of the realm.

This displays in the left-side menu, under the Document Title.

A realm is a distinct authentication workflow. Each realm can be configured uniquely depending on the target (application, self-service page, help desk), the user accessing it, and how they are accessing it (registration methods).

The realm name is automatically assigned to each new realm, starting with SecureAuth0, which is the Admin Realm, and increasing sequentially with each new realm creation (SecureAuth1, SecureAuth2, etc.).

For company's own login pages or if company is using Windows SSO. Elect the type of token received from the site.

Identifiable information of the SAML recipient, which usually maps to the SAML Consumer URL. This is an optional field; but required for some SPs, such as Salesforce.

The value is typically the same as the Assertion Consumer Service (ACS) / SAML Consumer URL.

Redirect users to a different page after saving self-services updates.

The auto-populated URL that is created by authenticated user redirect choice or selection. If Use Custom Redirect is selected, then the field needs to be set to where users are redirected after authentication.

The workflow that enables a refresh token to be provided during authorization that can be used to get a new access token.

When an Access Token expires, it can be refreshed for an extended period of time without requiring a new login. This Lifetime is longer than the Access Token Lifetime value.

The absolute URL of the target resource. The user is redirected to this URL after authentication.

Enable SecureAuth IdP to automatically enable Private or Public Mode based on the previous selection on that device.

Enable SecureAuth IdP to provide a new persistent token after the previous one has been validated.

If Push device replacement is enabled, then select how the enrolled devices are replaced.

If fingerprint replacement is enabled, then select how the fingerprints are replaced.

Block WS-Trust requests via a blocking engine in the WS-Trust Security Token Services (STS).

Select which Mobile Login Requests are available for 2-Factor Authentication use in the realm.

Whether a Begin Site is required for this realm or not. A begin site is a site on which users land before the SecureAuth IdP login pages.

Whether the current password is required to reset a user's password. SecureAuth IdP's self-service password reset enables password reset with 2-Factor Authentication.

Whether to require a static PIN to unlock the app / extension to generate OATH One-Time Passwords (OTPs).

Whether SSL is required to view the token.

To where users are redirected once they reset their passwords.

The Reset Password Stored Procedure (SP) name in the database.

During the request, the client application will send its credentials (Client ID and Client Secret) along with the user's credentials (which are validated against the directory) to gain access. The user is not required to authenticate and no authorization code is required.

A client-side link that takes users back to the first page of the login process of that specific realm.

Select whether the realm restricts login attempts by IP Addresses or Country Codes.

Select whether the realm restricts login attempts by specific users or user groups.

The workflow in which a previously-issued OAuth access token (from SecureAuth IdP) is explicitly revoked.

Enables flexible visibility into appliance configurations. Use RBAC to define roles in the appliance settings and restrict who has access and ability to change configurations. (Available in hybrid and on-prem only.)

The Safari Plugin version number.

The name of the Access Control (Safe) where credentials are stored.

An optional value that is provided by the SP, and is the base domain of the application.

The base domain of the Identity Provider from which SecureAuth IdP accepts the SAML assertion.

Check to enable SecureAuth IdP to utilize the NotBefore and NotOnOrAfter SAML conditions to produce a validity period of the SAML assertion to SecureAuth IdP.

The URL provided by the SP used to accept a SAML assertion.

The method (algorithm) used to encrypt the SAML Assertion, if True is selected from the Encrypt SAML Assertion field.

The unique SAML ID from the third-party Identity Provider.

The method (algorithm) used to encrypt the SAML Key.

The number of minutes that SecureAuth IdP subtracts from the NotBefore SAML attribute to account for any time difference between SecureAuth IdP and the SP.

Identifiable information of the SAML recipient, which usually maps to the SAML Consumer URL. This is an optional field; but required for some SPs, such as Salesforce.

The value is typically the same as the SAML Consumer URL.

Enable SecureAuth IdP to include the SAML Response InResponseTo in the SAML Assertion. The SP requests this if it is necessary.

This response is used in SP-initiated instances, and it enables SecureAuth IdP to communicate to the SP that it has received the user ID sent by the SP.

The time period during which the SAML assertion is valid. Choose a value from 1 to 48 to specify the NotOnOrAfter SAML attribute.

The Subject Alternative Name properties, which can be Default or customized.

Save the logging information from this realm to all existing realms on the appliance.

The exposed URL for accepting SCEP requests by SCEP / NDES server.

The local web service URL to accept SCEP requests, which typically will not need to change.

The name of the scope, which is what the client application requires to access in the user profile. A user will need to consent to the client accessing their user profile data before proceeding.

The name that is passed to the client. The client requests this URL-safe value from SecureAuth IdP (the authorization server).

The ID that SecureAuth IdP uses to search the directory for the user.

Tell SecureAuth IdP what field is expected for the username. It is auto populated by clicking Generate Search Filter. The user supplies the attribute that equals %v to log into realms.

The SecureAuth Authentication API embeds the SecureAuth Identity Platform functionality into a custom application, enabling flexible workflow configurations and user interfaces.

SecureAuth cloud uses IP addresses to provide services to SecureAuth® Identity Platform, end user browsers, and mobile devices registered to provide multi-factor authentication methods.

Newer release of the SecureAuth product (release 19.07 and later) with a new UI and available as an on-prem, hybrid, or cloud deployment solution.

Classic version of the SecureAuth product (release 9.3 and earlier) with a Web Admin UI available only as an on-prem solution.

Configure two-factor authentication login access to VPN and remote resources through RADIUS.

The version of the SecureAuth IdP appliance.

The SecureAuth IdP appliance includes multiple themes, which dictates how the client-side webpages will appear. The 2016 Light Theme is selected by default.

The sender's email address that displays in the From field. For example, do-not-reply@company.com.

The alias name for the email address that displays in the From field. For example, SecureAuth Support.

The address of the SMTP server through which OTP SecureAuth IdP emails (2-Factor Authentication, account update, password reset, etc.) are sent. This field is required.

An LDAP account that has read or write access to user accounts that SecureAuth IdP will authenticate.

The certificate serial number of the hosted facility used to facilitate the WSE 3.0 / WCF web service.

The EMAIL ADDRESS value from the Google Apps Service Account, e.g. XXXX@developer.gserviceaccount.com.

The name of the session state, which is defaulted to a value by SecureAuth IdP, but can be customized to act in a particular way.

The Shared Secret (password) that is provided by the SP. This must match with the SP for the communication to be successful.

Display a page listing the reasons why a user's password fails validation checking.

Display the one-time passcode (OTP) on the page after a user has successfully provisioned their account for Time-based Passcodes. This is especially useful for Browser Time-based Passcode usage to enable immediate access to the OTP to authenticate into another realm.

Display the configured password complexity requirements on the password reset page.

The number of seconds allowed for the application to remain idle before requiring the PIN to unlock the application.

Display the necessary information to provision a third-party app that generates Time-based Passcodes (Google Authenticator).

For Certificate Enrollment Only and Cisco ASA integrations, elect whether to show the User ID Textbox for users to provide their user ID if Cisco ASA does not send the user ID to SecureAuth IdP.

Elect to show the one-time use PIN option on the 2-Factor Authentication login screen, even though it is not available.

The signing algorithm used for signing JSON web tokens.

The certificate used for signing the JSON Web Token (JWT) (the private key). The public key will then need to be exported and provided to the client application.

The certificate for the SAML Assertion.

Enable SecureAuth IdP to sign the SAML Assertion that is being sent over to the SP. This is a "stamp of approval" from SecureAuth IdP in the form of a certificate stating the user is trusted, and the SP informs the administrator if the assertion needs to be signed or not.

Enable SecureAuth IdP to sign the SAML Message, which is the entire message including the SAML assertion that is sent to the SP. This is a "stamp of approval" from SecureAuth IdP in the form of a certificate stating the user is trusted, and the SP informs the administrator if the assertion needs to be signed or not.

If only one native mobile application integration is present in a single realm, then provide the custom URL scheme to ensure that users will always be redirected from SecureAuth IdP to the application. For example, app1:/.

Elect to skip matching the IP Address of the device to the IP Address recorded in the fingerprint (FP) ID in the user's data store profile.

Whether there is a UserID view (user ID textbox / page), which usually is selected for VPN enrollments as the UserID is received from the VPN.

Enable the token to be valid as long as the user is interacting with the page.

The SMS URL that is auto-populated if using WSE 3.0, but must be set if using WS 2.0 with SSL.

Whether SecureAuth IdP utilizes the message-level security (WSE 3.0 / WCF) or the transport-level security (WS 2.0 with SSL) to make a web service call to make an OTP text message request. Select False if using a Proxy.

Select from which directory integration SecureAuth IdP can pull the profile information for authentication and assertion purposes.

The domain name of the directory.

The type of format used for RFC3164.

The Service Provider's (SP) Start URL, where users log into the application. For SP-initiated Post Authentication integrations, this tells SecureAuth IdP to redirect users to the SP Start URL when landing on the SecureAuth IdP realm first in order to initiate the login process. This also assists SecureAuth IdP in accurately redirecting users for SSO.

The Service Provider's (SP) Start URL, where users log into the application. For SP-initiated Post Authentication integrations, this tells SecureAuth IdP to redirect users to the SP Start URL when landing on the SecureAuth IdP realm first in order to initiate the login process. This also assists SecureAuth IdP in accurately redirecting users for SSO.

Secure Socket Layer that acts as an encrypted tunnel through which emails are sent.

Used when not using SecureAuth IdP as the termination point. For bi-lateral authentication, a certificate is required here as the trusted SSL Certificate.

The Fully Qualified Domain Name (FQDN) of where the SSL cert is terminated. This communicates to SecureAuth IdP where the certificate has been terminated, enabling IdP to validate the information.

The URL for the OpenID Provider.

The Form Post information created from the Create Static Post information.

The Property in which SecureAuth IdP stores the user's LinkedIn ID for 2-Factor Authentication.

The subject text of the emails sent by SecureAuth IdP. For example, SecureAuth One-time Registration Code.

Enable SecureAuth IdP to include the SubjectConfirmationData Not Before in the SAML Assertion. The SP requests this if it is necessary.

This communicates that the SubjectConfirmationData will not be valid before the timestamp.

Select which languages that the SecureAuth IdP appliance supports. SecureAuth IdP alters the language selection based on the user's browser settings.

Enable the client-side use of Symantec VIP for 2-Factor Authentication.

Permit the use of Symantec VIP tokens for 2-Factor Authentication.

The minimum number of symbols required in each password (may not be required depending on the value set for the Must contain how many of the following field).

Conduct a one-way synchronization of the user's AD password to Google.

Synchronize the passwords every time from Google Apps to iOS devices. If set to True, then only one device can be used at a time.

The port on which the Syslog Server listens.

The required spec, provided by Syslog.

The IP Address or the Fully Qualified Domain Name (FQDN) of the Syslog Server.

The system components that factor into the fingerprint. Set the weight values for each System Component and for the HTTP Headers components to equal a total of 100%.

The Telephony URL that is auto-populated if using WSE 3.0, but must be set if using WS 2.0 with SSL.

Whether SecureAuth IdP utilizes the message-level security (WSE 3.0 / WCF) or the transport-level security (WS 2.0 with SSL) to make a web service call to make an OTP telephony call. Select False if using a Proxy.

Select the template to use for SecureAuth IdP emails. OTPEmailTemplate is the default.

The Domain Name of the Azure Directory.

Click to test that the web services communication is working and that certificates are valid.

Click to test that the directory integration was successful.

Click to verify the connection and to ensure successful integration.

The SecureAuth IdP appliance includes multiple themes, which dictates how the client-side webpages will appear. The 2016 Light Theme is selected by default.

A time-based temporary passcode used for 2-Factor Authentication.

The number of minutes during which a cookie is valid.

Tell SecureAuth IdP where the user ID is in the received token.

Tell SP where the user ID is in the sent token.

To where users are redirected if their token is missing, e.g. enrollment / provisioning realm. This is used for Near Field Communications (NFC).

A name for the token that is shared with the application. For example, UserID.

The maximum amount of fingerprint (FP) IDs that can be stored in a user's profile at the same time. Set to -1 for no maximum count.

Enable transparent SSO, which is “behind the scenes” single sign-on between applications. Users will log in once via 2-Factor Authentication; and upon opening a new application, no credentials would be required.

How the encrypted user information is sent to the SP.

The name of the value that is used to send the user information.

The code provided by SecureAuth support to temporarily disable the Transaction web service calls.

The code that is automatically assigned to the appliance during the build process and indicates whether it is intended for Transaction logging model or User based model.

The Transaction Log URL that is auto-populated if using WSE 3.0, but must be set if using WS 2.0 with SSL.

Whether SecureAuth IdP utilizes the message-level security (WSE 3.0 / WCF) or the transport-level security (WS 2.0 with SSL) to make a web service call to track transactions. Select False if using a Proxy.

Generate a Unique Assertion ID (GUID) to pass to the SP, which is required by some applications.

Enable administrators to unlock locked user accounts from the Help Desk page.

Whether a user's account is unlocked upon password reset, or administrative action.

The Unlock User Stored Procedure (SP) name in the database.

The Update Profile Stored Procedure (SP) name in the database.

The percentage that the user's fingerprint (FP) ID must be higher than to merge with the existing FP ID.

If the user's FP ID is lower than the Authentication Threshold, but higher than the Update Threshold, then SecureAuth IdP will merge the new FP ID with the previous one after a successful 2-Factor Authentication via another method. If the FP ID is lower than the Update Threshold, SecureAuth IdP will create an entirely new FP ID to store in the user's profile to use for subsequent authentications.

This is typically set between 80 - 90%, and must be lower than the Authentication Threshold.

The Update User Stored Procedure (SP) name in the database.

Upload a page to change the look and feel of the target action of the realm.

The SecureAuth IdP Property that contains the userPrincipalName (UPN).

The URI link of the white-listed page to where the client can be redirected to capture the SecureAuth IdP response.

The data is sent to this URL.

To where users are redirected once the Post Authentication processing is complete.

Check to enable CyberArk Vault to provide the password of the directory service account to SecureAuth IdP rather than providing the service account username and password in the Web Admin.

Enable the use of a Proxy Service, which routes communication in this realm through a web proxy.

Create a list of allowed user agents or denied user agents (devices, browsers, etc.).

A list of the allowed or denied user agents that is based on the User Agent Rule selected.

Enable the tool that associates existing users and groups within the LDAP data store using SecureAuth's IdM API.

Stores the consent granted to a client as an encrypted and compressed string value in the attribute specified in the Consent Storage Attribute field.

Create a list of allowed or denied user groups.

A list of the allowed groups or denied groups based on the selection made from the User Group Check Type dropdown.

For Cisco ASA integrations to check for a "Cisco-specific" user ID.

The user ID of the account that has read and/or write access to the SQL / ODBC / ASPNETDB database.

The User ID to access the database logs.

User ID Profile Field

The user ID that is asserted to the target resource.

The user ID that is asserted to the target resource.

Enable the SecureAuth IdP realm to run under a user or under a service name when using Integrated Windows Authentication (Kerberos).

The list of user accounts that are either allowed or denied based on the selection made from the dropdown, comma separated.

Enable the tool that adds new user profiles, and retrieves and updates existing user profiles using SecureAuth's IdM API.

How the username is delivered to the user in Forgot Username realm.

The SecureAuth User Risk Scoring Service calculates a user risk score in real-time by accessing user behavior described in the section above. The final score is a value between 0 and 100, where 0 is the least risk and 100 is the most risk.

Enable the end-user to change the current password with a new password using SecureAuth's IdM API.

Enable SecureAuth IdP to use an existing Certificate Authority (CA) to issue certificates via SCEP. By default, it is set to false as SecureAuth IdP employs its own, hosted CA to issue the certificates.

Whether the iOS password provisioning with Google Apps (synchronization of password changes from Google Apps to iOS devices) is being used. This setting is configured in the Post Authentication tab.

The Validate Password or Get Password Stored Procedure (SP) name in the database (depending on which SP is being used).

Enable SecureAuth IdP to check the complexity of the password based on the directory password requirements. Configure the settings in the Password Complexity section to display the requirements on the page.

Check whether the persistent token (Java, UBC, cookie, certificate, etc.) is still valid.

How SecureAuth IdP validates the user from the directory information.

Enable or disable the use of Yubikeys for 2-Factor Authentication.

How to encrypt the cookie. The web configuration file specifies which format to use.

The Validation Key is stored in the web configuration file and must match the validation key on the client application for SSO.

What is being sent in a form post to be validated.

Redirect users to a different realm if SecureAuth IdP detects that they are using an iPhone or iPad.

The type of restriction being placed on the native mobile application using the current Custom URL Scheme. Applicable for multi app and multi app groups check integrations only.

The SecureAuth IdP Property that includes the attribute required. The options are values from the Data tab, which point to fields in the directory. This information is provided by the SP as it expects the attribute to be delivered a certain way.

The maximum speed in Miles Per Hour users may have traveled between authentications. This speed is calculated based on the difference between the initial and subsequent IP Address locations and the recorded times when authentications occurred.

The version number of the token, provided by the SP.

The amount of days before expiration that a user is notified.

Select Click to view Web Config Backups to access web.config file backups to review changes made in the realms and to revert to older versions of the configurations.

Select Click to edit Web Config file to edit the source code of the realm directly.

Redirect users to different realms if SecureAuth IdP detects a mobile or a web browser.

The action taken when a user surpasses the Push device limit set in the Device Max Count field.

The action taken when a user surpasses the fingerprint (FP) limit set in the Total FP Max Count field.

Enable users to bypass the login process with Windows, as it uses a Kerberos ticket for the username and password (Windows Desktop SSO).

The Windows Firefox 2 version number.

The Windows Firefox 3 version number.

The Windows Firefox 4 version number.

The Windows Firefox 5 version number.

Remove the stored OATH Seed from the user's profile upon enrolling for a new OATH Token. This option is especially useful for companies transitioning from OATH Seed use to OATH Token as they can choose to keep the provisioned OATH Seed, or start fresh.

Lock the OTP application after 1-10 failed PIN attempts. If provisioned data is wiped, then the user needs to re-provision that device / browser for OATH tokens / Time-based Passcodes.

Enter the realm names (SecureAuth1, SecureAuth 2, etc.) that have distinct workflow options.

If this is checked, then changes can be made in the directory through SecureAuth IdP. A service account with write access is required.

For example, any self-service modifications that are enabled need to be checked "writable," otherwise the user will not be able to make the appropriate changes on the self-services page(s), and the directory will not be updated with the latest information.

The absolute URL of the target resource. The user is redirected to this URL after authentication.

The SAML ID of the Identity Provider (IdP). This can be any value as long as it's consistent on both sides, as the Issuer must match on the IdP and SP side exactly.

The algorithm used for the assertion signature.

The WS-Federation version that is asserted from post authentication.

Click View and Configure WS-Trust endpoints to configure the endpoints used in a WS-Trust integration. For example, Outlook.

The page where users can provision their YubiKey devices. This should direct users to the YubiKey Provisioning realm, which is configured in the Post Authentication tab.