--- title: "Unqork as a SAML Service Provider" slug: "unqork-as-a-saml-service-provider" description: "Learn how Unqork as a SAML service provider enhances security and simplifies SSO, offering seamless access to applications without storing credentials." updated: 2026-04-30T19:37:58Z published: 2026-04-30T19:37:58Z canonical: "docs.unqork.io/unqork-as-a-saml-service-provider" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.unqork.io/llms.txt > Use this file to discover all available pages before exploring further. # Unqork as a SAML Service Provider **Unqork as a SAML service provider** secures [applications](/v1/docs/introduction-to-unqork-applications) that work with sensitive information. Having end-users use **SSO** **(single sign-on)** to access your application is an effective approach. When setting up SSO, you can select the authentication provider for your Unqork application. Instead of storing end-users' credentials in Unqork, the SSO provider manages them. SSO also gives your end-users fewer credentials to remember and a seamless login experience. You can trust your SSO provider to verify that the right people have access to your app. SAML (Security Assertion Markup Language) is one of the SSO methods Unqork supports. SAML makes granting access to your Unqork application easier by: - Letting you grant access to end-users without Unqork credentials. - Letting Unqork users log in without having to input their credentials. In this article, you'll learn about using Unqork as a SAML Service Provider. > [!TIP] > Unqork also supports SSO using the OIDC ( Connect) authentication method. To learn more, search **Connect (OIDC)** in our In-Product Help. ## What Is a SAML Service Provider? SAML is a secure exchange of information between an Identity Provider (IdP) and a Service Provider (SP). The SP in this case is Unqork. The IdP is any SSO provider, like Okta or Microsoft Azure Entra ID. As an SP, Unqork supports three SAML request/response flows: - IdP-Initiated Flow - SP-Initiated Flow (AuthnRequest HTTP-Redirect Binding) - SP-Initiated Flow (AuthnRequest HTTP-POST Binding) IdP-Initiated Flows are the most common SAML configuration in Unqork. In this flow, an end-user begins on a client's website, clicks a link, and gains access to an Unqork application without logging in. The client has already established the user's identity and uses SAML to pass proof of that identity to Unqork. One Unqork environment can support multiple SAML configurations. ## How SSO Using SAML Works in Unqork Here is how the authentication process works when using SAML. In this explanation, the SSO provider is the IdP and Unqork is the SP. If the end-user is already logged in to the SSO provider when they open your application, they a seamless login experience and don't need to log in again. If your end-user does need to log in first, you decide how they log in. For example, you can set up an automatic redirect to a provider-hosted login page. Or, you can use a series of API calls to communicate between an Unqork-hosted page and the SSO provider's API. When the end-user successfully logs in to the IdP, the IdP issues a SAML assertion and sends it to your Unqork environment. A SAML assertion is an encoded XML document that contains identity information about the end-user. The SAML assertion authenticates your end-user's identity. The assertion also contains information that tells your Unqork application whether the end-user has authorization to access your app—for example, if the end-user has specific role permissions or characteristics your app recognizes. The XML document structures this information as a series of `Attribute` elements. Each `Attribute` element contains an attribute name and an attribute value. The IdP doesn't send the SAML assertion directly to your application's front end. It also doesn't send it to a module you can access from Designer View. Your application should only have access to the attributes specified in the SAML configuration, not all the information in the assertion. So, the IdP sends the assertion to the Callback URL entered in the SAML configuration on the IdP's end. The Callback URL is an endpoint of the SP's underlying platform. For Unqork applications, that endpoint typically looks like `https://<host>/auth/saml/consume?idp=<SAMLname>`. There, the Unqork platform decodes the SAML assertion and creates a session for the end-user. Unqork also strips the assertion, keeping only the attributes listed in your SAML configuration. These attributes map to attributes in the `currentUser` object of the session's Submission Data. When configuring which attributes to pull from the SAML assertion, you also specify which Unqork attribute receives the mapped value. You control this mapping in the Attribute Mappings section of the SAML configuration. You can use attribute mapping to improve your end-user's experience. For example, you can use the email address returned by the IdP to autofill an email field in your application. ## Understanding the SAML Settings in Single Sign-On (SSO) Management To connect the SAML configuration on the SSO provider's end to your Unqork application, use the [Single Sign-On (SSO) Management](/v1/docs/single-sign-on-ssomanagement) page. Begin by reviewing each setting in the SSO configuration Modal. > [!NOTE] > Available settings in the SSO configuration Modal vary between Express View and Designer SSO configurations. The following images reflect the Express View SSO configuration modal. The settings description tables note which settings are specific to Express View or Designer configurations. > To learn more about using the Single Sign-On Management page, view our [Single Sign-On Management](/v1/docs/single-sign-on-ssomanagement) article. ### Basic Information Tab ![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/ssoSaml_expressModal_basicInfo_thumb_0_0(1).jpg?sv=2026-02-06&spr=https&st=2026-11-11T13%3A53%3A11Z&se=2026-11-11T14%3A53%3A11Z&sr=c&sp=r&sig=UU6rk%2FxhEMEgOnDzl6bal7R%2B3vu1e9twyVMApqf2dMk%3D) | Setting | Description | | --- | --- | | SSO Name* | Enter a name for your configuration. Use a descriptive name that relates to your configuration. For example, `{environment name and codebase}-{application name}-saml`. > [!NOTE] > Unqork uses this name to generate the default SP Entity ID and SAML Callback URL. | | Default Role | Select a default role for end-users who authenticate using the SSO configuration. The default role applies when no role is explicitly assigned. The available roles vary between Express View and Designer SSO configurations: - **Express View**: The default role is an Express role. The drop-down populates with roles defined in [Express Role Administration](/v1/docs/express-role-administration). - **Designer**: The default role is a Creator (User) role. The drop-down populates with roles defined in [Creator (User) Administration](/v1/docs/creator-user-administration). > [!NOTE] > Select a default role with the lowest-level permissions. > [!TIP] > You can use Attribute Mapping to assign a role based on attributes defined in the user's IdP-defined profile. See the [Creating Attribute Mappings](/v1/docs/unqork-as-a-saml-service-provider#Attribut) section for examples. | | Default Group | This setting only displays in Express View SSO configurations. Select a default group for end-users who authenticate using the SSO configuration. The default group applies when no group is explicitly assigned. To select multiple groups, choose more than one option from the Default Group drop-down. The Default Group drop-down lists the groups defined in Express Group Administration. > [!NOTE] > Select a default group with the lowest-level permissions. Leaving this empty assigns the end-user to no group. > [!TIP] > You can use Attribute Mapping to assign a group based on attributes in the end-user's IdP-defined profile. See the [Creating Attribute Mappings](/v1/docs/unqork-as-a-saml-service-provider#Attribut) section for examples. | ### Configure Protocol Tab > [!NOTE] > Select **SAML** from **Select Protocol** to access the following SAML configuration settings. The Configure Protocol tab is where you enter the IdP metadata XML file. The foundation of any SAML setup is creating a relationship between the IdP and SP by exchanging IdP and SP metadata XML files. The administrator of the SSO provider account issues an IdP metadata XML file, which you use to complete your SAML configuration. In return, you give the IdP the SP metadata XML file. This is the preferred method of configuration. > [!NOTE] > You can also set up a SAML configuration without parsing an IdP metadata file. However, using a metadata file is the preferred and most common setup method. > [!TIP] > In some cases, the administrator of the SSO provider account requests the SP metadata XML file before they issue the IdP metadata XML file. The configuration modal lets you generate a placeholder SP metadata XML file. Click **Copy Metadata URL** to generate an SP metadata XML file based on default configuration values and copy its URL to your clipboard. #### IdP Details After pasting the contents of the IdP metadata XML file in the IdP Metadata XML field, Unqork automatically parses the file. If the file is valid, the other fields in this section display and autofill based on the file's contents. ![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/ssoSaml_expressModal_configureProtocol_thumb_0_0.jpg?sv=2026-02-06&spr=https&st=2026-11-11T13%3A53%3A11Z&se=2026-11-11T14%3A53%3A11Z&sr=c&sp=r&sig=UU6rk%2FxhEMEgOnDzl6bal7R%2B3vu1e9twyVMApqf2dMk%3D) All settings in this section are required: | **Setting** | Description | | --- | --- | | IdP Metadata XML | Paste the contents of the IdP metadata XML file provided by the IdP. Unqork automatically parses the file. If the file is valid, the other fields in this section display and autofill based on the file's contents. | | SAML IdP NameID Format | This field holds a unique identifier that matches a user across multiple Unqork sessions. Leave this field empty to accept the default. The default NameID format is `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress.` This is the most common format. Use this unless the IdP provides an alternative. | | SAML IdP SSO URL | This field specifies the point of origin for the SAML response. This is where the end-user moves from a non-Unqork site to an Unqork application. This is usually the client's website. This is a required setting. It autofills based on the IdP metadata XML file. | | SAML IdP X.509 Certificate | This field specifies the public key certificate used to verify the digital signature of the SAML assertion. To insert multiple certificates, see the [Using Multiple Certificates](/v1/docs/unqork-as-a-saml-service-provider#using-multiple-certificates) section. Alternatively, use the **SAML IdP Metadata Refresh URL** setting in [Advanced Settings](/v1/docs/unqork-as-a-saml-service-provider#advanced-settings) to automatically update the SAML IdP X.509 Certificate field using a public IdP URL. | #### Using Multiple Certificates Unqork supports multiple certificates from a single IdP metadata file, displaying each one in the **SAML IdP X.509 Certificate** field separated by a comma. If the first certificate fails or expires, Unqork attempts to validate using the next certificate in the list. Use this method to ensure service availability when rotating from an expiring certificate to a new one. The order in which Unqork uses a certificate depends on the order the certificates appear in the XML file. The following code block shows IdP Metadata with multiple certificates: ```xml                                                                                                MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBSMQswCQYDVQQGEwJVUzETMBEG                        A1UECAwKQ2FsaWZvcm5pYTasdfgsdfhdfghwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwE                        S2V5dDEOMAwGA1UEAwwFbm9kZTEwHhcNMTkwMTAxMDAwMDAwWhcNMjkwMTAxMDAwMDAw                        WjBSMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcmasdYTEWMBQGA1UEBwwNU2Fu                        ... (Certificate Data) ...                                                                                                                                        MIIEAzCCAuugAwIBAgIUBm6h6B9WvO3D2K5Jm6h6B9WvO3AwDQYJKoZIhvcNAQELBQAw                        RzELMAkGA1UEBhMCasdsgdfghdfhfgBAgMadWSdDUI3IDFHGHFASgdfFGaghdwMTAxMDAwMDAwWhcNMzYwMTAxMDAw                        MDAwWjBHMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN                        ... (New Certificate Data) ...                                                                urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress                     ``` #### Configuration Details ![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/ssoSaml_expressModal_configurationDetails_thumb_0_0.jpg?sv=2026-02-06&spr=https&st=2026-11-11T13%3A53%3A11Z&se=2026-11-11T14%3A53%3A11Z&sr=c&sp=r&sig=UU6rk%2FxhEMEgOnDzl6bal7R%2B3vu1e9twyVMApqf2dMk%3D) | **Setting** | Description | | --- | --- | | SAML SP Entity ID | This field sets the ID of your Unqork application. Your SSO provider supplies this value if they require a non-default value. Leave this field empty to accept the default. The default value reflects the environment and the name of your SAML configuration, as defined in the SSO Name field. For example, `training-uat/SAMLconfig` is the default SAML SP Entity ID for a configuration named `SAMLconfig` created in the Unqork Training environment. | | SAML Callback URL | This is where Unqork sends the SAML response. The default value is `https://<host>/auth/saml/consume?idp=<SAMLname>`, where `<host>` is your environment name and `<SAMLname>` is your SAML configuration name. This is the recommended setting. For example, the default SAML Callback URL for an Express SSO configuration named SAMLconfig in the Unqork Training environment is `https://trainingx.unqork.io/auth/saml/consume?idp=SAMLconfig`. This setting is optional. Complete the field with your environment-specific SAML Callback URL. > [!NOTE] > Express View SSO configurations must have a SAML Callback URL with an Express View-specific host value. For example, `trainingx`-.`unqork.io`. Designer SSO configurations must have a Designer-specific host value. For example, `training.unqork.io`. By default, Express SSO configurations have a default Express View-specific host value and Designer SSO configurations have a Designer-specific host value. > [!TIP] > The host value changes as your application moves through environment stages. For example, the host changes from unqork-stagingx.unqork.io to `unqork-uatx.unqork.io`. Use the correct environment-specific host value in the SAML Callback URL. | | Copy Metadata URL | Click to generate the SP metadata XML file and copy its URL to your clipboard. > [!NOTE] > Unqork generates the SP metadata XML file from the current state of your SAML configuration. If you generate the SP metadata XML file before parsing an IdP metadata XML file, it uses default configuration values. | #### Advanced Settings Click **Show Advanced Settings** to display the following settings: ![Settings for SAML authentication including options for signed requests and encrypted assertions.](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/saml-sso-advanced-settings.jpg?sv=2026-02-06&spr=https&st=2026-11-11T13%3A53%3A11Z&se=2026-11-11T14%3A53%3A11Z&sr=c&sp=r&sig=UU6rk%2FxhEMEgOnDzl6bal7R%2B3vu1e9twyVMApqf2dMk%3D) | **Setting** | Description | | --- | --- | | Use HTTP-POST Binding | When selected, Unqork sends the SAML request using HTTP-POST Binding. This setting is optional. The default setting is ☐ (**unchecked**). | | Use Signed AuthnRequest | When selected, the IdP requires a signed AuthnRequest. This setting is optional. The default setting is ☐ (**unchecked**). | | Expect Encrypted Assertions | When selected, the IdP sends encrypted assertions in the SAML response. This setting is optional. The default setting is ☐ (**unchecked**). | | Do Not Request a Specific Authentication Context | This setting is optional. The default state is ☐ (**unchecked**).. Some IdPs don't support a specific authentication context (`RequestedAuthnContext`) in a SAML request. When selected, this removes `RequestedAuthnContext` from the request. This setting is optional. The default setting is ☐ (**unchecked**). | | SAML Certificate | Select an existing certificate to use. | | SAML IdP Metadata Refresh URL | Use this field to connect to IdP metadata hosted on a public URL. When you enter a URL, Unqork checks the endpoint hourly to automatically update the [SAML IdP X.509 Certificate](https://docs.unqork.io/docs/unqork-as-a-saml-service-provider?highlight=SAML%20IdP%20X.509%20Certificate&block=mfsjkka4-q4yw36-476) and [IdP Metadata XML](https://docs.unqork.io/docs/unqork-as-a-saml-service-provider?highlight=IdP%C2%A0Metadata+XML&block=mfsjkka2-63934t-468) fields. This setting is useful for identity providers that rotate signing certificates frequently. | ### Attribute Mapping Tab ![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/sso_SAMLSP_attributeMappings_thumb_0_0.jpg?sv=2026-02-06&spr=https&st=2026-11-11T13%3A53%3A11Z&se=2026-11-11T14%3A53%3A11Z&sr=c&sp=r&sig=UU6rk%2FxhEMEgOnDzl6bal7R%2B3vu1e9twyVMApqf2dMk%3D) The Attribute Mapping tab is where you map attributes in the SAML assertion to attributes in Unqork. Specifically, you map SAML attributes to attributes in the `currentUser` object in the session's submission data. You can also create custom attributes in addition to mapping SAML attributes to existing Unqork attributes. Attribute mapping provides a more seamless experience for your end-user. For example, you can map the email address returned by the IdP to the `email` attribute in the `currentUser` object, then use that value to autofill email address fields in your application. > [!NOTE] > The Attribute Mapping tab refers to SAML attributes as SAML claims. > [!TIP] > See the [Creating Attribute Mappings](/v1/docs/unqork-as-a-saml-service-provider#Attribut) section for examples of dynamic, conditional, and static attribute mappings. Click `+ Add Attribute Mapping` to create a new mapping. > [!CAUTION] > By default, the Attribute Mapping tab includes the mapping `{{NameID}}` to `userId`. Do not delete this mapping or your SSO configuration will fail. | **Setting** | Description | | --- | --- | | SAML Claim | Enter an attribute in the SAML assertion to map to an attribute in the `currentUser` object. Or, enter a static value to map to the `currentUser` object. This field accepts Nunjucks formatting, which lets you create dynamic and conditional attribute mappings. | | Unqork Attribute | Select or enter an Unqork attribute for the SAML attribute to map to. Unqork maps attributes to the currentUser object in the session's Submission Data. By default, the Unqork Attribute drop-down contains the following commonly-referenced attributes found in the `currentUser` object: `email`, `name`, `userId`. To create a custom attribute, type the attribute's name in the Unqork Attribute field, then press Enter/Return or select **Create {attribute name}**. | #### User Management Click **Show User Management** to display the following settings: | **Setting** | Description | | --- | --- | | Require User Exists | When selected, your end-user must have an existing Unqork account in your environment to access it using SSO. End-users don't need to log in using their credentials, but Unqork verifies that an end-user has credentials before logging them in. > [!TIP] > Whether you enable this setting depends on your SSO strategy. If you want your SSO provider to act as the single source of truth for authentication and authorization, leave **Require User Exists** clear. If you want Unqork to act as the user management system, select **Require User Exists**. The default setting is ☐ (**unchecked**). | | Disable User Creation | When selected, Unqork doesn't create an Unqork user account if the end-user doesn't already exist in the system. > [!TIP] > Whether you enable this setting depends on your SSO strategy. If you want your SSO provider to act as the single source of truth for authentication and authorization, leave **Disable User Creation** selected. If you want Unqork to act as the user management system, clear **Disable User Creation**. The default setting is (**checked**). | | Match Attribute | This setting lets you customize what SAML attribute Unqork uses to identify an existing user in your Unqork environment. The default is to match against the `Nam`eID attribute. This setting is optional. | ## Creating Attribute Mappings You can create three types of attribute mappings: dynamic, conditional, and static. ### Dynamic Attribute Mappings When creating an attribute mapping, you most commonly use Nunjucks to dynamically populate the attribute with the value returned by the IdP. For example, here is how to map the `email` SAML attribute to the `email` attribute in Unqork: 1. On the Attribute Mapping tab, click **+ Add Attribute Mapping**. 2. Enter `{{email}}` in the **SAML Claim** side of the mapping. > [!NOTE] > When filling out the SAML Claim side of the mapping, use the exact spelling and capitalization of the attribute as it displays on the IdP. > [!TIP] > The name of your Unqork Attribute doesn't need to match the name of the SAML attribute. 3. Select **email** from the **Unqork Attribute** drop-down. > [!NOTE] > The Unqork Attribute drop-down lists commonly-referenced attributes. To create a custom attribute, type the attribute in the Unqork Attribute field, then press Enter/Return or select **Create {attribute name}**. ![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/samlSP_attributeDynamic_thumb_0_0(2).jpg?sv=2026-02-06&spr=https&st=2026-11-11T13%3A53%3A11Z&se=2026-11-11T14%3A53%3A11Z&sr=c&sp=r&sig=UU6rk%2FxhEMEgOnDzl6bal7R%2B3vu1e9twyVMApqf2dMk%3D) ### Conditional Attribute Mappings You can also use more complex Nunjucks in the SAML Claim side of the mapping. For example, you can conditionally map values to your Unqork attribute based on one or more other attributes. This is useful when you want to automatically redirect some users to certain pages of your application. For example, you might want to send users with admin permissions directly to an administrator's dashboard. Your app can only have a single point of entry for all users, regardless of their role permissions. But you can conditionally assign a `currentUser` attribute based on the attribute values returned by the IdP, then reference that attribute to create custom redirect rules. > [!WARNING] > You cannot configure custom redirects based on roles and attributes in the SSO Configuration modal. Here is an example of a conditional attribute mapping: ![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/samlSP_attributeConditional_thumb_0_0(1).jpg?sv=2026-02-06&spr=https&st=2026-11-11T13%3A53%3A11Z&se=2026-11-11T14%3A53%3A11Z&sr=c&sp=r&sig=UU6rk%2FxhEMEgOnDzl6bal7R%2B3vu1e9twyVMApqf2dMk%3D) Here are the contents of the SAML Claim side of the mapping: ```plaintext 1 {% if dynamic_group | length %} 2 {% if 'MMC-Admin' in dynamic_group | string %}{{ 'MMC-Admin' }} 3 {% elif  'Eforms-Admin'  in dynamic_group | string %}{{userState}} 4 {% endif %}{% elif  userState | length %}{{userState}} 5 {% else %}{{ 'Unverified' }}{% endif %} ``` > [!NOTE] > When completing the SAML Claim side of the mapping, entered values show as a single line of text. This explanation uses a multiple-line display for clarity. In this example, the Nunjucks checks the dynamic_group and userState SAML attributes to determine what value to map to the Unqork attribute role. Both the dynamic_group and userState attributes contain values that could map to an Unqork role. Here is what each line does: **Line 1**: `{% if dynamic_group | length %}` This line checks that there is a value in the dynamic_group SAML attribute sent by the IdP. **Line 2**: `{% if 'MMC-Admin' in dynamic_group | string %}{{ 'MMC-Admin' }}` The next line checks if the value in the dynamic_group SAML attribute is the string 'MMC-Admin'. If so, Unqork maps 'MMC-Admin' to the role attribute. **Line 3**: `{% elif  'Eforms-Admin'  in dynamic_group | string %}{{userState}}{% endif %}` This line checks if the value in the dynamic_group SAML attribute is the string 'Eforms-Admin'. If so, Unqork maps the value in the userState SAML attribute to the role attribute. **Line 4**: `{% elif  userState | length %}{{userState}}` This line checks if the userState SAML attribute contains a value. If it does, Unqork maps that value to the role attribute. **Line 5**: `{% else %}{{ 'Unverified' }}{% endif %}` Finally, if none of the previous conditions are true, Unqork maps 'Unverified' to the role attribute. Use this fallback when the dynamic_group and userState attributes have no values. In this example, Unverified is the name of a role in the Unqork environment. ### Static Attribute Mappings The Attribute Mappings section has one more option. Instead of using Nunjucks to reference an attribute in the SAML assertion, you can hardcode a value. For example, you might need a static value that always displays in the currentUser object, but the IdP doesn't provide it as an attribute in the SAML assertion. To set a static value, type it in the SAML Claim side of the mapping. No additional formatting is necessary. For example: ![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/samlSP_attributeStatic_thumb_0_0.jpg?sv=2026-02-06&spr=https&st=2026-11-11T13%3A53%3A11Z&se=2026-11-11T14%3A53%3A11Z&sr=c&sp=r&sig=UU6rk%2FxhEMEgOnDzl6bal7R%2B3vu1e9twyVMApqf2dMk%3D) ## Configuring SSO Using SAML With Different SSO Providers Now that you know the SAML configuration settings, you're ready to begin connecting Unqork to your chosen SSO provider. Use the SSO guides below to begin: ### [SSO in Express View (SAML)](/v1/docs/sso-in-express-view-saml) ### [Set Up Microsoft Entra ID for SSO in Express View (SAML)](/v1/docs/setting-up-microsoft-entra-id-for-sso-in-express-view-oidc) Set Microsoft Entra ID as an SSO (single sign-on) provider using the SAML (Security Assertion Markup Language) authentication method. ### [Set Up Okta for SSO in Express View (SAML)](/v1/docs/setting-up-okta-for-sso-in-express-view-saml) Learn how to use Okta as an SSO (single sign-on) provider using the SAML (Security Assertion Markup Language) authentication method. ### [SSO in Designer (SAML)](/v1/docs/sso-in-designer-saml) ### [Set Up Microsoft Entra ID for SSO in Designer (SAML)](/v1/docs/setting-up-microsoft-entra-id-for-sso-in-designer-saml) Learn how to use Microsoft Entra ID as an SSO (single sign-on) provider, using the SAML (Security Assertion Markup Language) authentication method. ### [Set Up Okta for SSO in Designer (SAML)](/v1/docs/setting-up-okta-for-sso-in-designer-saml) Learn how to use Okta as an SSO (single sign-on) provider, using the SAML (Security Assertion Markup Language) authentication method. ### [SSO Certificates](/v1/docs/sso-certificates) ### [Using Certificates with SAML Assertions](/v1/docs/how-to-using-certificates-with-saml-assertions) Create a SAML signing certificate, then add it to a new or existing SSO configuration. Security Assertion Markup Language (SAML) is a protocol that allows an identity provider (IdP) to send a user's credentials to a service provider (SP) to verify their identity and grant them access to a service. End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. Single Sign-On is an authentication scheme that enables users to use one set of login credentials across multiple services. In JavaScript, a method is a function that is associated with an object. It is essentially a property of an object whose value is a function. Methods define actions or operations that can be performed on the object they belong to. OIDC (OpenID Connect) is an identity authentication protocol that lets two applications share user information without exposing user credentials. In JavaScript, a method is a function that is associated with an object. It is essentially a property of an object whose value is a function. Methods define actions or operations that can be performed on the object they belong to. Identity provider (IdP) provide a service that creates, manages, and verifies users' digital identities, allowing them to securely authenticate and access different applications or services. Identity provider (IdP) provide a service that creates, manages, and verifies users' digital identities, allowing them to securely authenticate and access different applications or services. Okta is a cloud-based identity and access management (IAM) platform that helps organizations manage user identities, access rights, and credentials across multiple applications, websites, and databases. HTTP (Hypertext Transfer Protocol) is an application-layer protocol used to transmit hypermedia documents like HTML. The HTTP POST method is used to send data to a server to create or update a resource, typically including the data in the body of the request. End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. A definition Extensible Markup Language (XML) is markup language that lets you define and store data in a shareable way. End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. A data structure is the design used for organizing, using, and storing data. Elements are are what you use to build Unqork applications. Elements include modules, workflows, Data Collections, Data Schema, and Record Collections. Creators use Deisgner View to build and manage modules in the Unqork Designer Platform. A URL (uniform resource locator) is a unique identifier used to locate a resource on the internet. Also known as a web address. An API endpoint is the location where an API receives requests for a specific resource on its server. It's the point of contact between an API client and an API server, and is usually a uniform resource locator (URL) that provides the location of the resource. An object is a type of data structure that represents a single, self-contained entity that acts as a container for the characteristics of that entity. Also known as Record Data. Submission data consists of information saved by Unqork components. View submission data by using the angular command, or in Record Collections. A modal is a window that appears on top of the content you are currently viewing. Express View is how your end-user views your application. Express View also lets you preview your applications to test your configuration and view the styling. This is also the view your end-users will see when interacting with your application. After configuring a module, click Preview in the Module Builder to interact with the module in Express View. The Unqork front-end application framework that delivers Creator-built applications to end-users. Express is the layer end-users interact with—the published forms, screens, and navigation built in the Module Builder. Express is distinct from Express View, which is a Creator-facing preview tool in the IDE. Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform. A place on your operating system that stores recently copied content. The clipboard only stores one item at a time. A key-value pair is a fundamental data structure where a unique "key" is associated with a specific "value," used for organizing and retrieving data efficiently, like in dictionaries or databases. Also known as Record Data. Submission data consists of information saved by Unqork components. View submission data by using the angular command, or in Record Collections. Nunjucks is a flexible JavaScript templating engine that supports template inheritance, filters, and logic-based expressions for dynamic content rendering. A string is an object that represents a sequence of characters. Strings typically hold data represented in text form.