Proofreading: Advanced configuration and IdP Configuration

Author: Karuna-Mendix

content/en/docs/appstore/use-content/platform-supported-content/modules/SAML/_index.md

@@ -156,7 +156,7 @@ There are different versions of the SAML module, depending on which version of M
 3. To download the required release, in the **Releases** tab, find the release that is compatible with your app per the guidelines in the **Documentation** tab, and then click the **Download** button by the number of the release.
 4. Follow the instructions in [How to Use Marketplace Content](/appstore/use-content/) to import the SAML module into your app.
 
-### Post-Installation Configuration Steps
+### Post-installation Configuration Steps
 
 By default, the SAML module will be installed as the **SAML20** module in your app’s Marketplace modules. You can find all microflows and other configuration elements in this module.
 

content/en/docs/appstore/use-content/platform-supported-content/modules/SAML/advanced_configuration.md

@@ -21,31 +21,31 @@ If you are using a custom URL, see [How Do I Get my SAML Metadata or CommunityCo
 
 ### Use a Certificate Issued by a Certificate Authority {#use-ca}
 
-By default the SAML SSO module will use self-signed certificates. It is, however, also possible to use certificates issued by a certificate authority (CA).
+By default, the SAML SSO module will use self-signed certificates. It is, however, also possible to use certificates issued by a certificate authority (CA).
 
 SAML SSO supports 2 file formats:
 
-* a PKCS 12 file, which typically has extension .pfx or .p12.
+* a PKCS 12 file, which typically has an extension .pfx or .p12.
 * a jks file.
 
-To use a CA-certificate, upload it as your key store file as described in [Managing the Keys and Key Store](/appstore/modules/saml/idp-attributes/#keystore).
+To use a CA certificate, upload it as your key store file as described in [Managing the Keys and Key Store](/appstore/modules/saml/idp-attributes/#keystore).
 Remember to do the following:
 
-* set the certificate password in the `KeystorePassword` constant of your app to be able to read the contents of the uploaded key store.
-* use an alias for the certificate — this must be the name parameter that is provided when creating the certificate you are uploading. If the values do not match, the SAML module will fall back to using a self-signed certificate instead.
-* the value of the configured SP EntityID must match the alias that is included in the uploaded key store.
+* Set the certificate password in the `KeystorePassword` constant of your app to be able to read the contents of the uploaded key store.
+* Use an alias for the certificate — this must be the name parameter that is provided when creating the certificate you are uploading. If the values do not match, the SAML module will fall back to using a self-signed certificate instead.
+* The value of the configured SP EntityID must match the alias that is included in the uploaded key store.
 
 ### Customizing the Login Page
 
-Mendix runtime/system module comes with a default login page. When using SAML with a single IdP, this page is not required.
+The Mendix runtime/system module comes with a default login page. When using SAML with a single IdP, this page is not required.
 You need to customize this login page when end-users have different ways of login:
 
 1. If you want to use both Mendix (local) login and SSO login:
 
     1. Go to the **App** > **Show App Directory in Explorer** > **theme/web** folder (for Mendix versions below 9.0.0, this is the **theme** folder).
     2. Rename `login.html` to `login-without-sso.html`.
     3. Rename `login-with-mendixsso-button.html` to `login.html`.
-    4. Open login.html, update the **href** to `/SSO`, and give a button name
+    4. Open login.html, update the **href** to `/SSO`, and give a button name.
 
     Your app is now configured to use Mendix SSO login.
 2. If you want to connect your app with multiple IdPs and the end-user of your app needs to select the IdP to use for login.

content/en/docs/appstore/use-content/platform-supported-content/modules/SAML/idp_attributes.md

@@ -9,19 +9,19 @@ description: "Describes the list of IdP Attributes for the SAML module"
 
 ## Introduction
 
-This document provides you the detail description of each IdP attribute and their default value for deploy-time configuration. You need to use these attributes when configuring the SAML module to create the IdP configuration. For more details, see [Non-default Configuration](/appstore/modules/saml/#non-default).
+This document provides you a detail description of each IdP attribute and its default value for deploy-time configuration. You need to use these attributes when configuring the SAML module to create the IdP configuration. For more details, see [Non-default Configuration](/appstore/modules/saml/#non-default).
 
 ## Identity Configuration
 
-The **Identity Configuration** tab allows the seamless integration between your application and an Identity Provider (IdP) using SAML protocols. It provides details on key settings, including **Response Protocol Binding**, **AssertionConsumerService Concept**, and **Assertion consumer service index** enabling you to optimize SAML response handling and service provider metadata configurations.
+The **Identity Configuration** tab allows seamless integration between your application and an Identity Provider (IdP) using SAML protocols. It provides details on key settings, including **Response Protocol Binding**, **AssertionConsumerService Concept**, and **Assertion consumer service index** enabling you to optimize SAML response handling and service provider metadata configurations.
 
 ### Response Protocol Binding{#saml-binding}
 
 You may need to choose a different SAML binding to match your IdP. You can configure the SAML binding in the **Identity Configuration** tab of the `OpenConfiguration` microflow.
 
 By default, the SAML SSO module uses `POST_BINDING` for the SAML response. In most cases (for example, when using AzureAD) you will want to stick to this default.
 Some IdPs, however, require your app to use the more secure `ARTIFACT_BINDING`.
-To use artifact binding, select ARTIFACT_BINDING option for **Response protocol binding**. This configuration helps enable the Post/Artifact binding, used as the following:
+To use artifact binding, select the ARTIFACT_BINDING option for **Response protocol binding**. This configuration helps enable the Post/Artifact binding, used as the following:
 
 * `ProtocolBinding` attribute in Auth-request.
 * `AssertionConsumerService` binding in SP-MetaData.
@@ -31,14 +31,14 @@ Using artifact binding for SAML responses at the SAML IdP is only available in t
 * v3.3.0/v3.3.1 and above for Mendix 9 and 10
 * v2.3.0 and above for Mendix 8
 
-`POST_BINDING` is the default value when using a [Easy Default Flow](/appstore/modules/saml/#easy-flow).
+`POST_BINDING` is the default value when using an [Easy Default Flow](/appstore/modules/saml/#easy-flow).
 
 ### Use AssertionConsumerService Concept
 
-In most cases (for example, with Entra ID), you don not want to use the AssertionConsumerService concept in requests. Some IdPs, however, require requests to include an AssertionConsumerServiceIndex. This refers to the definition of the Assertion Consumer Service in the SP-metadata.
+In most cases (for example, with Entra ID), you do not want to use the AssertionConsumerService concept in requests. Some IdPs, however, require requests to include an AssertionConsumerServiceIndex. This refers to the definition of the Assertion Consumer Service in the SP metadata.
 
-* If **Use AssertionConsumerService Concept** is set to `No…` then Auth-Request contains the `AssertionConsumerServiceURL` and `ProtocolBinding` attributes.
-* If **Use AssertionConsumerService Concept** is set to `Yes…` then Auth-Request contains only the ‘`AssertionConsumerServiceIndex`’ attribute.
+* If the **Use AssertionConsumerService Concept** is set to `No…` then Auth-Request contains the `AssertionConsumerServiceURL` and `ProtocolBinding` attributes.
+* If the **Use AssertionConsumerService Concept** is set to `Yes…` then Auth-Request contains only the ‘`AssertionConsumerServiceIndex`’ attribute.
     By default, it is `No` when using a [Easy Default Flow](/appstore/modules/saml/#easy-flow).
 
 ### Assertion Consumer Service Index
@@ -48,12 +48,12 @@ Set **Assertion consumer service index** to the value you want to use for `Asser
 
 ## Attribute Consuming Service
 
-In the **Attribute Consuming Service** tab, you can configure your app using the SAML protocol to request specific attributes, such as Date of Birth or Gender, from the SAML IdP. Your SAML IdP documentation will tell you what attributes can be requested. In the request you can also indicate whether you consider the attribute as mandatory or optional for your app’s logic.
+In the **Attribute Consuming Service** tab, you can configure your app using the SAML protocol to request specific attributes, such as Date of Birth or Gender, from the SAML IdP. Your SAML IdP documentation will tell you what attributes can be requested. In the request, you can also indicate whether you consider the attribute as mandatory or optional for your app’s logic.
 
 You can set up two sets of attributes, by adding new attributes, editing existing attributes, or removing selected attributes. These will be provided at different times. Those listed under **I want to request attribute(s) at my IDP during initial login** will be returned when the end-user initially signs in. Those listed under **I want to request attribute(s) at my IDP during in-session login** will be returned during [In-session Authentication](#in-session).
 Although the typical use case for requesting attributes is to obtain information about the user, you can request an attribute with a specific value. In this case, you can configure the optional Attribute value that must be returned.
 
-When using using a [Easy Default Flow](/appstore/modules/saml/#easy-flow), disable both initial and in-session login options.
+When using an [Easy Default Flow](/appstore/modules/saml/#easy-flow), disable both initial and in-session login options.
 
 Requesting user attributes at the SAML IdP is only available in the following versions of the module (depending on which Mendix version you are using)
 
@@ -69,21 +69,21 @@ Requesting user attributes at the SAML IdP is only available in the following ve
     * **What algorithm do you want to use to sign messages** (or *Encryption method*) – `SHA1 - RSA` or `SHA256 - RSA`
     * **Encryption key length** – 1024 or 2048 bits
 
-        When using using a [Easy Default Flow](/appstore/modules/saml/#easy-flow), default values are `SHA256 - RSA` and 2048 bits
+        When using an [Easy Default Flow](/appstore/modules/saml/#easy-flow), default values are `SHA256 - RSA` and 2048 bits
 
     Enabling encryption has the following effects on messages being exchanged:
 
-    * all the messages between your app and the IdP will be encrypted, this requires the IdP’s metadata to contain a KeyDescriptor having ‘use’ value ‘encryption’ or empty.
-    * all the messages between your app and the IdP will be signed. The SP metadata exported from your app will have `AuthnRequestSigned` with value `true`. This corresponds to IdPs whose metadata have `WantAuthnRequestSigned` with value `true`
-    * in SAML SSO module versions 1.17.3 and above, 2.3.0 and above, and 3.3.0 and above, your IdP is expected to sign all SAML assertions sent to your app. The SP metadata will have `WantAssertionsSigned` with value `true`. Any assertions that are not properly signed will be rejected. SAML’s signature inheritance is supported as well; if the SAML response message is signed by the IdP, it is not necessary for the assertion to be signed as well
+    * All the messages between your app and the IdP will be encrypted, this requires the IdP’s metadata to contain a KeyDescriptor having ‘use’ value ‘encryption’ or empty.
+    * All the messages between your app and the IdP will be signed. The SP metadata exported from your app will have `AuthnRequestSigned` with value `true`. This corresponds to IdPs whose metadata have `WantAuthnRequestSigned` with value `true`
+    * In the SAML SSO module versions 1.17.3 and above, 2.3.0 and above, and 3.3.0 and above, your IdP is expected to sign all SAML assertions sent to your app. The SP metadata will have `WantAssertionsSigned` with the value `true`. Any assertions that are not properly signed will be rejected. SAML’s signature inheritance is supported as well; if the SAML response message is signed by the IdP, the assertion does not need to be signed as well.
 
 See [Managing the Keys and Key Store](#keystore), below, for additional information and options related to encryption and signing keys.
 
 ### Managing the Keys and Key Store{#keystore}
 
 SAML implements encryption and signing using asymmetric keys. If encryption is enabled, all the certificates required for encryption are stored in the key store. When you choose **Enable better security for app** (or **Use encryption**) a key store is automatically created using the URL of the application, or the custom EntityID. Below version 3.5.0 it is shown as the **Key store alias**.
 
-The key-pair (or pairs) for your app (as an SP) can be self-generated by the SAML module or you can upload keypair certificate (or certificates) provided by your IdP.
+The key-pair (or pairs) for your app (as an SP) can be self-generated by the SAML module or you can upload a keypair certificate (or certificates) provided by your IdP.
 
 {{% alert color="warning" %}}
 For version 3.5.0 and above, there are separate key pairs generated for each IdP, for versions below that, the self-generated key pairs are used for all IdPs, if your app is configured to use multiple IdPs.
@@ -101,7 +101,7 @@ However, there may be a requirement to use a specific key store. If you want to
 For versions below 3.5.0 only:
 
 * Resetting the key store or uploading another key store will require you to export the SP metadata and import it to all applicable IdPs.
-* Click **Reset** to return the key store settings to their defaults
+* Click **Reset** to return the key store settings to their defaults.
 * Click **Download** to download the key store file and use it when configuring other SAML SPs.
 {{% /alert %}}
 
@@ -111,7 +111,7 @@ Remember to set the new key store password in the `KeystorePassword` constant of
 
 ## Identity Provider Metadata
 
-### Read IDP metadata from URL
+### Read IDP Metadata from URL
 
 You can set up the module to re-import all IdP metadata files on a daily basis. Alternatively, you can import the metadata from a file, manually.
 
@@ -120,7 +120,7 @@ If you want to manually import the IdP metadata files from a URL, do the followi
 * Set **Read IDP metadata from URL** to *Yes.*
 * Set the **URL:** to the location where the IdP metadata is available.
 * Click **Refresh Metadata**
-    **The following metadata has been fetched** will show an overview of all the information that has been found in the IdP metadata information. It is usually not necessary to do anything here, but it can be useful in order to review the possible IdP and SP configuration options.
+    **The following metadata has been fetched** and will show an overview of all the information that has been found in the IdP metadata information. It is usually not necessary to do anything here, but it can be useful to review the possible IdP and SP configuration options.
 
 If you want to automatically synchronize the IdP metadata, make sure the **SE_SynchronizeIdPMetadata** [scheduled event](/refguide/scheduled-events/) is enabled. This is in the **_USE ME** > **Scheduled Events** folder of the SAML module.
 If you need to change your identity provider metadata you can find more information in the [Response Protocol Binding](#saml-binding) section.
@@ -149,18 +149,18 @@ This feature is deprecated.
 
 When you use the SAML SSO module in your app, your app will typically be a front-end app that redirects the user to their IdP via the browser for login.
 Using SAML protocols to secure the APIs of your back-end app is more challenging. We advise you to use OAuth access tokens by installing the [OIDC SSO](https://marketplace.mendix.com/link/component/120371) module instead of the SAML module. This is a common, and a best, practice.
-The SAML module currently allows you to use multi-tier delegation (which makes use of the SAML ECP profile) if you need it. Your front-end app can request a token during login that has the right characteristics so it can be shared with a back-end app. This is an advanced scenario which requires in-depth knowledge of the SAML protocol and the configuration of all integrating systems to get it working.
-In the SAML module, you can enable this by checking “Enable delegated authentication” on the provisioning tab. By checking this box you are able to access the authorized SAML token, the module will automatically keep the token alive. Only enable this functionality if you are actually using multi-tier delegated authentication.
+The SAML module currently allows you to use multi-tier delegation (which makes use of the SAML ECP profile) if you need it. Your front-end app can request a token during login that has the right characteristics so it can be shared with a back-end app. This is an advanced scenario that requires in-depth knowledge of the SAML protocol and the configuration of all integrating systems to get it working.
+In the SAML module, you can enable this by checking “Enable delegated authentication” on the provisioning tab. By checking this box you can access the authorized SAML token, the module will automatically keep the token alive. Only enable this functionality if you are using multi-tier delegated authentication.
 
 If you enable this, you will need to enter the **Delegated Auth URL**.
 
 ### In-session Authentication {#in-session}
 
-In-session authentication is a process that takes place within a session that was initiated by a (primary) end-user that signed in to your app or from within an anonymous session. This can be useful in the following situations:
+In-session authentication is a process that takes place within a session that was initiated by a (primary) end-user who signed in to your app or from within an anonymous session. This can be useful in the following situations:
 
-* to require the primary end-user to re-authenticate shortly before they are allowed to do a critical transaction in your app
-* to have a second end-user add their authentication (for example, for electronic signing) but leave the primary end-user associated with the overall session
-* to let the user interact anonymously with your app at first, but ask them to identify and authenticate themselves during that session
+* To require the primary end-user to re-authenticate shortly before they are allowed to do a critical transaction in your app
+* To have a second end-user add their authentication (for example, for electronic signing) but leave the primary end-user associated with the overall session
+* To let the user interact anonymously with your app at first, but ask them to identify and authenticate themselves during that session
 
 In-session authentication at the SAML IdP is only available in the following versions of the module (depending on which Mendix version you are using)
 
@@ -173,7 +173,7 @@ This flow can be initiated by using the URL `https://{app-url}/sso/login?action=
 
 To enable in-session authentication, you need to use the `OpenConfiguration` microflow to configure two microflows in the SAML SSO module:
 
-### Custom Prepare In-Session Authentication Microflow
+### Custom Prepare In-session Authentication Microflow
 
 Set **Custom Prepare In-Session Authentication microflow** to `CustomPrepareInSessionAuthentication`.
 
@@ -189,7 +189,7 @@ The `CustomEvaluateInSessionAuthentication` microflow implements the logic that
 
 **Disable Name ID Policy** – Check this box to disable the use of a name ID policy. This means you will use another attribute or claim to identify users.
 
-If you check this box, you will not be able to set **Preferred name id**.
+If you check this box, you will not be able to set the **Preferred name id**.
 
 ### Authentication Context Comparison