You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/authenticate/auth-guides/pass-params-idp.mdx
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,11 +15,11 @@ There's a number of reason why you might want to use upstream params:
15
15
- to create a smoother sign in experience - by passing the email through
16
16
- to offer an account switcher (such as the Google account switcher) during sign in
17
17
18
+
Upstream params are available for OAuth 2.0 connections, e.g. [social connections](/authenticate/social-sign-in/add-social-sign-in/), [Entra ID OAuth 2.0 enterprise connection](/authenticate/enterprise-connections/azure/), and as part of [advanced configurations](/authenticate/enterprise-connections/advanced-saml-configurations/) in SAML connections.
19
+
18
20
## Limitations
19
21
20
-
- Each IDP has their own set of supported parameters and values, so you'll need to check their documentation to determine which URL parameters are supported.
21
-
- Applies only to OAuth 2.0 connections, e.g. [social connections](/authenticate/social-sign-in/add-social-sign-in/) and [Entra ID OAuth 2.0 enterprise connection](/authenticate/enterprise-connections/azure/).
22
-
- SAML IdPs do not support upstream parameters.
22
+
Every identity provider has their own set of supported parameters and values, so you'll need to check their documentation to determine which URL parameters are supported.
When you set up a SAML connection, you might need to include advanced configurations to meet identity provider requirements, and to get the connection running properly and securely.
14
+
15
+
Here's some of the advanced options you will come across when setting up a connection.
16
+
17
+
## Name ID
18
+
19
+
Name ID (Name Identifier) is a key element in a SAML assertion that uniquely identifies the user (subject) within a given SAML context. It is included in the `Subject` element of the SAML assertion and is critical for identifying and linking user identities between your Identity Provider (IdP) and Kinde.
20
+
21
+
Available Name ID formats:
22
+
-**Unspecified**: No particular format is required
23
+
-**EmailAddress**: A user is identified by their email address
24
+
-**Persistent**: A stable, opaque identifier intended to remain consistent across sessions
25
+
-**Transient**: A short-lived identifier, often used in single sign-on (SSO) scenarios for one-time use
26
+
27
+
The Name ID you select in Kinde must be supported and configured in your IdP.
28
+
29
+
## Sign request algorithm
30
+
31
+
The Sign Request Algorithm defines the cryptographic algorithm used to sign SAML requests (AuthnRequest). Signing ensures the authenticity and integrity of SAML messages.
32
+
33
+
Available algorithms:
34
+
-**RSA-SHA256**: A commonly used and secure option.
35
+
-**RSA-SHA1**: Older and less secure; often deprecated.
36
+
37
+
Secure configurations favor SHA256 or stronger algorithms to protect against vulnerabilities.
38
+
39
+
## Protocol binding
40
+
41
+
Protocol Binding refers to the transport mechanism used to send the SAML authentication request from Kinde to your IdP.
42
+
43
+
Common Binding Types:
44
+
-**HTTP Redirect Binding**: The SAML request is sent as a URL parameter using a GET request. It is lightweight but limited in message size.
45
+
-**HTTP POST Binding**: The SAML request is sent via an HTML form using the POST method. It supports larger payloads and is commonly used for transmitting signed requests.
46
+
47
+
The choice of binding affects security, performance, and compatibility. POST Binding is generally preferred for secure communications due to its ability to handle signed messages and larger payloads.
48
+
49
+
## Key attributes
50
+
51
+
Key Attributes are additional pieces of information about the user that come from your IdP to Kinde. These attributes provide more context about the authenticated user and are often used for access control or personalization.
52
+
53
+
Kinde-supported key attributes:
54
+
55
+
- Email Address: The user’s email, often used for identification or communication.
56
+
- First Name / Last Name: Used for personalization or internal system mapping.
57
+
- User ID: The attribute in the SAML token that contains the user ID.
58
+
59
+
Only configure key attributes if supported by your IdP.
60
+
61
+
## Upstream parameters
62
+
63
+
You can pass provider-specific parameters to an Identity Provider (IdP) during authentication. These are also known as 'upstream params'. The values your pass can either be static per connection or dynamic per user.
64
+
65
+
You can use upstream paramsto create a smoother sign in experience - by passing the email through, or to offer an account switcher (such as the Google account switcher) during sign in.
66
+
67
+
Note that every identity provider has their own set of supported parameters and values, so you'll need to check their documentation to determine which URL parameters are supported.
Copy file name to clipboardExpand all lines: src/content/docs/authenticate/enterprise-connections/cloudflare-saml.mdx
+46-44Lines changed: 46 additions & 44 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,17 +4,20 @@ title: Use Cloudflare as a SAML identity provider
4
4
sidebar:
5
5
order: 10
6
6
relatedArticles:
7
+
- 17559023-5b50-4690-ba7b-fd1df4b78664
7
8
- fcf28a71-c3a8-4474-9564-ad089d3f2105
8
9
- e100d77b-530b-4327-8216-93c955657e0c
9
10
- 66b2a627-b24a-4ccf-a792-80a6a9fe35ef
10
-
- 0dfcab9d-8610-4881-9293-8501bd472041
11
-
- d894dd3c-356f-41b0-b510-c35066a2277d
12
11
---
13
12
14
13
If you use Cloudflare to centralize authentication and authorization in your business, you can integrate Kinde as a service provider for these processes. This gives you the benefits of Kinde’s robust auth capabilities, while keeping the familiar Cloudflare structure.
15
14
16
15
You need to set up an enterprise connection in Kinde for this, and add a Cloudflare application. We recommend setting up and testing the connection in a non-production environment before making available to users.
17
16
17
+
## Advanced configurations
18
+
19
+
Depending on your SAML set up, you may need to include advanced configurations for your connection. See [Advanced SAML configurations](/authenticate/enterprise-connections/advanced-saml-configurations/)
20
+
18
21
## Step 1: Add the connection in Kinde
19
22
20
23
<Aside>
@@ -40,14 +43,37 @@ You can make a connection available only to a specific organization, or you can
40
43
41
44
## Step 2: Configure the connection
42
45
43
-
1. Enter a random string value for Entity ID, for e.g. `870sa9fbasfasdas23aghkhc12zasfnasd`.
44
-
2. Complete any optional fields you want, including key attributes. You'll add the IdP Metadata URL later. You only need to enter a **sign in URL** if your IdP requires a specific URL.
45
-
3. Add **Home realm domains**. We recommend adding these to speed up the sign in process for users of those domains. Note that all home realm domains must be unique across all connections in an environment. For more information, see [Home realm domains or IdP discovery](/authenticate/enterprise-connections/home-realm-discovery/).
46
-
4. If you use home realm domains, the sign in button is hidden on the auth screen by default. To show the SSO button, select the **Always show sign-in button** option.
47
-
5. Copy the **Assertion Customer Service (ACS) URL** and the Entity ID somewhere you can access it later. You’ll need this to set up your Cloudflare application.
48
-
6. Select provisioning options.
49
-
7. Add a signed certificate and key if you have it. You can also do this later.
50
-
8. Select **Save**.
46
+
1. Enter a name for the connection. It should match the connection name in Cloudflare.
47
+
2. Enter a random string value for Entity ID, for e.g. `870sa9fbasfasdas23aghkhc12zasfnasd`.
48
+
3. Enter the **IdP metadata URL**. This URL comes from your identity provider.
49
+
50
+
51
+
52
+
4. Enter a **sign in URL** if your IdP requires a specific URL.
53
+
5. If you want, select the **Sign request algorithm** and **Protocol binding**. The options you choose will depend on what your identity provider prefers or requires.
54
+
6. Select a **Name ID** format. This helps identify and link user identities between your IdP and Kinde.
55
+
7. Enter an **Email key attribute**. This is the attribute in the SAML token that contains the user’s email. Setting this value ensures that the email address returned in the SAML response is correctly retrieved. We do not recommend leaving this field blank, but if you do we will set ‘email’ as the attribute.
56
+
8. (Optional) Add a first name and last name key attribute.
57
+
58
+
59
+
60
+
9. Enter any relevant **Home realm domains**. This is how SAML recognizes a user’s credentials and routes them to the correct sign in page. Note that home realm domains need to be unique across all connections in an environment. [Read more about home realm domains](/authenticate/enterprise-connections/home-realm-discovery/).
61
+
10. If you use home realm domains, the sign in button is hidden on the auth screen by default. To show the SSO button, select the **Always show sign-in button** option.
62
+
63
+
64
+
65
+
11. Copy the reply relevant URL:
66
+
1. If you don't use a custom domain, copy the **Assertion customer service (ACS) URL**.
67
+
2. If you do use a custom domain, select the **Use custom domain instead** option and copy the custom domain URL.
68
+
Later, add this URL to your identity provider configuration.
69
+
12. If you want to enable just-in-time (JIT) provisioning for users, select the **Create a user record in Kinde** option. This saves time adding users manually or via API later.
70
+
71
+
72
+
73
+
13. (Temporary feature) Select if you want to treat this connection as a trusted provider. A [trusted provider](/authenticate/about-auth/identity-and-verification/) is one that guarantees the email they issue is verified.
74
+
14. (Optional) In the **Sign SAML request** section, paste in the **Signed certificate** and **Private key**. You may have got these from your IdP or you may have generated yourself (see procedure above).
75
+
15. Enter any [upstream params](/authenticate/enterprise-connections/advanced-saml-configurations/#upstream-parameters) that you want to pass to the identity provider. Not all providers support this, so check their documentation first.
76
+
16. Select **Save**.
51
77
52
78
## Step 3: Add and configure your Cloudflare application
53
79
@@ -56,45 +82,21 @@ You can make a connection available only to a specific organization, or you can
56
82
3. Go to **Access > Applications**, then select **Add an application**.
57
83
4. Select SaaS as the type of application. The **Add application** window opens.
Copy file name to clipboardExpand all lines: src/content/docs/authenticate/enterprise-connections/custom-saml-google-workspace.mdx
+33-14Lines changed: 33 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,7 @@ title: Custom SAML with Google Workspace
4
4
sidebar:
5
5
order: 9
6
6
relatedArticles:
7
+
- 17559023-5b50-4690-ba7b-fd1df4b78664
7
8
- fcf28a71-c3a8-4474-9564-ad089d3f2105
8
9
- 66b2a627-b24a-4ccf-a792-80a6a9fe35ef
9
10
- e100d77b-530b-4327-8216-93c955657e0c
@@ -15,6 +16,10 @@ You can set up SAML to work with your Google Workspace.
15
16
16
17
Google does not support hosting your SAML metadata XML file on their web services, but Kinde requires access to the file via URL so that certificates are always up to date. We recommend you host the file on a public web service that can be accessed by Kinde. For example, you could use an [AWS S3](https://aws.amazon.com/s3/) bucket, [Cloudflare R2](https://developers.cloudflare.com/r2/), or public website.
17
18
19
+
## Advanced configurations
20
+
21
+
Depending on your SAML set up, you may need to include advanced configurations for your connection. See [Advanced SAML configurations](/authenticate/enterprise-connections/advanced-saml-configurations/).
22
+
18
23
## Step 1: Add Google Workspace SAML in Kinde
19
24
20
25
You can make a connection available only to a specific organization, or you can create it so it can be used across any organization in your business.
@@ -42,16 +47,32 @@ You can make a connection available only to a specific organization, or you can
4. Complete any optional fields you want, including key attributes. You only need to enter a **sign in URL** if your IdP requires a specific URL.
46
-
5. Enter Home realm domains. This speeds up the sign in process for users of those domains. Note that all home realm domains must be unique across all connections in an environment. For more information about how, see [Home realm domains or IdP discovery](/authenticate/enterprise-connections/home-realm-discovery/).
47
-
6. If you use home realm domains, the sign in button is hidden on the auth screen by default. To show the SSO button, select the **Always show sign-in button** option.
48
-
7. Scroll down and copy the **ACS URL**. Paste the URL somewhere you can access it later.
50
+
4. Enter a **sign in URL** if your IdP requires a specific URL.
51
+
5. If you want, select the **Sign request algorithm** and **Protocol binding**. The options you choose will depend on what your identity provider prefers or requires.
52
+
6. Select a **Name ID** format. This helps identify and link user identities between your IdP and Kinde.
53
+
7. Enter an **Email key attribute**. This is the attribute in the SAML token that contains the user’s email. Setting this value ensures that the email address returned in the SAML response is correctly retrieved. We do not recommend leaving this field blank, but if you do we will set ‘email’ as the attribute.
54
+
8. (Optional) Add a first name and last name key attribute.
55
+
56
+
57
+
58
+
9. Enter any relevant **Home realm domains**. This is how SAML recognizes a user’s credentials and routes them to the correct sign in page. Note that home realm domains need to be unique across all connections in an environment. [Read more about home realm domains](/authenticate/enterprise-connections/home-realm-discovery/).
59
+
10. If you use home realm domains, the sign in button is hidden on the auth screen by default. To show the SSO button, select the **Always show sign-in button** option.
60
+
61
+
62
+
63
+
11. Copy the reply relevant URL:
64
+
1. If you don't use a custom domain, copy the **Assertion customer service (ACS) URL**.
65
+
2. If you do use a custom domain, select the **Use custom domain instead** option and copy the custom domain URL.
66
+
Later, add this URL to your identity provider configuration.
67
+
12. If you want to enable just-in-time (JIT) provisioning for users, select the **Create a user record in Kinde** option. This saves time adding users manually or via API later.
68
+
69
+
49
70
50
-
71
+
13. (Temporary feature) Select if you want to treat this connection as a trusted provider. A [trusted provider](/authenticate/about-auth/identity-and-verification/) is one that guarantees the email they issue is verified.
72
+
14. (Optional) In the **Sign SAML request** section, paste in the **Signed certificate** and **Private key**. You may have got these from your IdP or you may have generated yourself (see procedure above).
73
+
15. Enter any [upstream params](/authenticate/enterprise-connections/advanced-saml-configurations/#upstream-parameters) that you want to pass to the identity provider. Not all providers support this, so check their documentation first.
74
+
16. Select **Save**.
51
75
52
-
8. Select provisioning options.
53
-
9. Add a signed certificate and key if you have it. You can also do this later.
54
-
10. Select **Save**. We need to get some information from Google Workspace Console to complete these fields.
55
76
56
77
## Step 3: Configure Google Workspace Admin Console
57
78
@@ -97,14 +118,12 @@ As mentioned at the start, you need to upload the **metadata file** that you dow
97
118
98
119
## Step 5: Complete Kinde configuration
99
120
100
-
1. In Kinde, go to **Settings > Authentication**.
101
-
2. Scroll down to **Enterprise Connections.**
102
-
3. On the **Google Workspace** tile, select **Configure.**
103
-
4. In the **IdP metadata URL** field, paste the URL for the metadata file.
104
-
5. Switch on the connection. This will make it instantly available to users if this is your production environment.
121
+
1. Open the connection's configuration page in Kinde.
122
+
2. In the **IdP metadata URL** field, paste the URL for the metadata file.
123
+
3. Switch on the connection. This will make it instantly available to users if this is your production environment.
105
124
1. For environment-level connections, scroll down and select the apps that will use the auth method.
106
125
2. For organization-level connections, scroll down and select if you want to switch this on for the org.
0 commit comments