mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
Merge branch 'main' into ENG-2706
This commit is contained in:
x032205
@@ -13,7 +13,7 @@ To enable and configure GitHub Organization Synchronization, follow these steps:
|
||||
|
||||
<Steps>
|
||||
<Step title="Set up GitHub organization configuration">
|
||||
1. Navigate to **Organization Settings** and select the **Security Tab**.
|
||||
1. Navigate to the **Single Sign-On (SSO)** page and select the **Provisioning** tab.
|
||||
|
||||
2. Click the **Configure** button and provide the name of your GitHub Organization.
|
||||
|
||||
|
||||
@@ -18,7 +18,9 @@ Prerequisites:
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the LDAP configuration in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > LDAP and select **Manage**.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Select **Connect** for **LDAP**.
|
||||
|
||||
|
||||
|
||||
Next, input your LDAP server settings.
|
||||
|
||||
|
||||
@@ -27,7 +27,9 @@ Prerequisites:
|
||||
|
||||
</Step>
|
||||
<Step title="Prepare the LDAP configuration in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > LDAP and select **Manage**.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Select **Connect** for **LDAP**.
|
||||
|
||||
|
||||
|
||||
Next, input your JumpCloud LDAP server settings.
|
||||
|
||||
|
||||
@@ -75,8 +75,8 @@ In the following steps, we explore how to issue a X.509 certificate under a CA.
|
||||
Here's some guidance on each field:
|
||||
|
||||
- Friendly Name: A friendly name for the certificate; this is only for display and defaults to the common name of the certificate if left empty.
|
||||
- Common Name (CN): The (common) name for the certificate like `service.acme.com`.
|
||||
- Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) for the certificate; these can be host names or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- Common Name (CN): The common name for the certificate like `service.acme.com`.
|
||||
- Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) for the certificate; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- TTL: The lifetime of the certificate in seconds.
|
||||
- Key Usage: The key usage extension of the certificate.
|
||||
- Extended Key Usage: The extended key usage extension of the certificate.
|
||||
@@ -240,7 +240,7 @@ openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
|
||||
```
|
||||
|
||||
Note that you can also obtain the CRL from the certificate itself by
|
||||
referencing the CRL distribution point extension on the certificate itself.
|
||||
referencing the CRL distribution point extension on the certificate.
|
||||
|
||||
To check a certificate against the CRL distribution point specified within it with OpenSSL, you can use the following command:
|
||||
|
||||
|
||||
@@ -4,9 +4,10 @@ sidebarTitle: "Overview"
|
||||
description: "Learn how to create a Private CA hierarchy and issue X.509 certificates."
|
||||
---
|
||||
|
||||
Infisical can be used to create a Private Certificate Authority (CA) hierarchy and issue X.509 certificates for internal use. This allows you to manage your own PKI infrastructure and issue digital certificates for services, applications, and devices.
|
||||
Infisical can be used to create a Private Certificate Authority (CA) hierarchy and issue X.509 certificates for internal use. This allows you to manage your own PKI infrastructure and issue digital certificates for subscribers such as services, applications, and devices.
|
||||
|
||||
Infisical's internal PKI offering is split into two modules:
|
||||
Infisical's PKI offering is split into three components:
|
||||
|
||||
- [Private CA](/documentation/platform/pki/private-ca): Infisical lets you create private CAs, including root and intermediary CAs.
|
||||
- [Certificates](/documentation/platform/pki/certificates): Infisical allows you to issue X.509 certificates using the private CAs you create.
|
||||
- [Certificate Authorities](/documentation/platform/pki/private-ca): Create and manage private CAs, including root and intermediate CAs.
|
||||
- [Subscribers](/documentation/platform/pki/subscribers): Define and manage entities that will request X.509 certificates from CAs. This module provides a centralized view of all subscribers, enabling you to issue certificates and monitor their status.
|
||||
- [Certificates](/documentation/platform/pki/certificates): Track and monitor issued X.509 certificates, maintaining a comprehensive inventory of all active and expired certificates.
|
||||
|
||||
@@ -7,7 +7,7 @@ description: "Learn how to create a Private CA hierarchy with Infisical."
|
||||
## Concept
|
||||
|
||||
The first step to creating your Internal PKI is to create a Private Certificate Authority (CA) hierarchy that is a structure of entities
|
||||
used to issue digital certificates for services, applications, and devices.
|
||||
used to issue digital certificates for your [subscribers](/documentation/platform/pki/subscribers).
|
||||
|
||||
<div align="center">
|
||||
|
||||
@@ -24,7 +24,7 @@ graph TD
|
||||
|
||||
A typical workflow for setting up a Private CA hierarchy consists of the following steps:
|
||||
|
||||
1. Configuring an Infisical root CA with details like name, validity period, and path length — This step is optional if you wish to use an external root CA.
|
||||
1. Configuring an Infisical root CA with details like name, validity period, and path length — This step is optional if you wish to use an external root CA with Infisical only serving the intermediate CAs.
|
||||
2. Configuring and chaining intermediate CA(s) with details like name, validity period, path length, and imported certificate to your Root CA.
|
||||
3. Managing the CA lifecycle events such as CA succession.
|
||||
|
||||
@@ -99,7 +99,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
|
||||
|
||||
Great! You've successfully created a Private CA hierarchy with a root CA and an intermediate CA.
|
||||
Now check out the [Certificates](/documentation/platform/pki/certificates) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
Now check out the [Subscribers](/documentation/platform/pki/subscribers) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
|
||||
2.3b. If you have an external root CA, select **External CA** for the **Parent CA Type** field.
|
||||
|
||||
@@ -110,7 +110,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
Finally, press **Install** to import the certificate and certificate chain as part of the installation step for the intermediate CA
|
||||
|
||||
Great! You've successfully created a Private CA hierarchy with an intermediate CA chained to an external root CA.
|
||||
Now check out the [Certificates](/documentation/platform/pki/certificates) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
Now check out the [Subscribers](/documentation/platform/pki/subscribers) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
@@ -255,7 +255,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
}
|
||||
```
|
||||
|
||||
Great! You’ve successfully created a Private CA hierarchy with a root CA and an intermediate CA. Now check out the Certificates page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
Great! You’ve successfully created a Private CA hierarchy with a root CA and an intermediate CA. Now check out the [Subscribers](/documentation/platform/pki/subscribers) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
130
docs/documentation/platform/pki/subscribers.mdx
Normal file
130
docs/documentation/platform/pki/subscribers.mdx
Normal file
@@ -0,0 +1,130 @@
|
||||
---
|
||||
title: "Subscribers"
|
||||
sidebarTitle: "Subscribers"
|
||||
description: "Learn how to manage PKI subscribers and issue X.509 certificates for them."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
In Infisical PKI, subscribers are logical representations of entities such as devices, servers, applications that request and receive certificates from Certificate Authorities (CAs).
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Issuing CA] --> C1[Certificate]
|
||||
C1 --> S1[Subscriber]
|
||||
A --> C2[Certificate]
|
||||
C2 --> S2[Subscriber]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## Workflow
|
||||
|
||||
The typical workflow for managing subscribers consists of the following steps:
|
||||
|
||||
1. Creating a subscriber and defining which (issuing) CA will issue X.509 certificates for it as well as attributes to be included on the certificates including common name, subject alternative names, TLL, etc.
|
||||
2. Requesting for a certificate against the subscriber with or without a certificate signing request (CSR).
|
||||
3. Managing certificate lifecycle events such as certificate renewal and revocation. As part of the certificate revocation flow,
|
||||
you can also query for a Certificate Revocation List [CRL](https://en.wikipedia.org/wiki/Certificate_revocation_list), a time-stamped, signed
|
||||
data structure issued by a CA containing a list of revoked certificates to check if a certificate has been revoked.
|
||||
|
||||
<Note>
|
||||
Note that this workflow can be executed via the Infisical UI or manually such
|
||||
as via API.
|
||||
</Note>
|
||||
|
||||
## Guide to Issuing Certificates with Subscribers
|
||||
|
||||
In the following steps, we explore how to issue a X.509 certificate for a subscriber.
|
||||
|
||||
<Steps>
|
||||
<Step title="Creating a subscriber">
|
||||
A subscriber is the logical representation of an entity that requests and
|
||||
receives certificates from a CA. With a subscriber, you can specify the
|
||||
attributes that must be present on the X.509 certificates issued for it.
|
||||
|
||||
Head to your Infisical PKI Project > Subscribers to create a subscriber.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each field.
|
||||
|
||||
- Subscriber Name: A slug-friendly name for the subscriber such as `web-service`.
|
||||
- Issuing CA: The Certificate Authority (CA) that will issue X.509 certificates for the subscriber.
|
||||
- Common Name (CN): The common name to be included on certificates to be issued to the subscriber.
|
||||
- Subject Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) to be included on certificates; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- TTL: The lifetime of the certificate.
|
||||
- Key Usage: The key usage extension of the certificate.
|
||||
- Extended Key Usage: The extended key usage extension of the certificate.
|
||||
|
||||
<Note>
|
||||
It's possible to issue certificates for a subscriber with or without a certificate signing request (CSR).
|
||||
- If requesting without a CSR, the attributes specified on the subscriber will be used to issue a certificate for the subscriber.
|
||||
- If requesting with a CSR, the attributes on it will be validated against the attributes specified on the subscriber
|
||||
and a certificate is only issued if they comply.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Requesting a certificate">
|
||||
Once you have created a subscriber from step 1, you can issue a certificate for it.
|
||||
|
||||
Press on the subscriber you want to issue a certificate for and click on the **Issue Certificate** button on that subscriber's page.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Guide to Revoking Certificates
|
||||
|
||||
In the following steps, we explore how to revoke a X.509 certificate and obtain a Certificate Revocation List (CRL) for a CA.
|
||||
|
||||
<Steps>
|
||||
<Step title="Revoking a Certificate">
|
||||
Assuming that you've issued a certificate for a subscriber, you can revoke it by
|
||||
selecting the **Revoke Certificate** option on the certificate you wish to revoke
|
||||
on the subscriber's page.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Obtaining a CRL">
|
||||
In order to check the revocation status of a certificate, you can check it
|
||||
against the CRL of a CA by heading to its Issuing CA and downloading the CRL.
|
||||
|
||||
|
||||
|
||||
To verify a certificate against the
|
||||
downloaded CRL with OpenSSL, you can use the following command:
|
||||
|
||||
```bash
|
||||
openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
|
||||
```
|
||||
|
||||
Note that you can also obtain the CRL from the certificate itself by
|
||||
referencing the CRL distribution point extension on the certificate.
|
||||
|
||||
To check a certificate against the CRL distribution point specified within it with OpenSSL, you can use the following command:
|
||||
|
||||
```bash
|
||||
openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
|
||||
```
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="What is the workflow for renewing a certificate?">
|
||||
To renew a certificate, you have to issue a new certificate for the same
|
||||
subscriber. The original certificate will continue to be valid through its
|
||||
original TTL unless explicitly revoked.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -5,23 +5,23 @@ description: "Learn how to enable a set of policies to manage changes to sensiti
|
||||
|
||||
<Info>
|
||||
Approval Workflows is a paid feature.
|
||||
|
||||
If you're using Infisical Cloud, then it is available under the **Pro Tier** and **Enterprise Tire**.
|
||||
|
||||
If you're using Infisical Cloud, then it is available under the **Pro Tier** and **Enterprise Tier**.
|
||||
If you're self-hosting Infisical, then you should contact sales@infisical.com to purchase an enterprise license to use it.
|
||||
</Info>
|
||||
|
||||
## Problem at hand
|
||||
|
||||
Updating secrets in high-stakes environments (e.g., production) can have a number of problematic issues:
|
||||
- Most developers should not have access to secrets in production environments. Yet, they are the ones who often need to add new secrets or change the existing ones. Many organizations have in-house policies with regards to what person should be contacted in the case of needing to make changes to secrets. This slows down software development lifecycle and distracts engineers from working on things that matter the most.
|
||||
- As a general rule, before making changes in production environments, those changes have to be looked over by at least another person. An extra pair of eyes can help reduce the risk of human error and make sure that the change will not affect the application in an unintended way.
|
||||
- After making updates to secrets, the corresponding applications need to be redeployed with the right set of secrets and configurations. This process is often not automated and hence prone to human error.
|
||||
Updating secrets in high-stakes environments (e.g., production) can have a number of problematic issues:
|
||||
- Most developers should not have access to secrets in production environments. Yet, they are the ones who often need to add new secrets or change the existing ones. Many organizations have in-house policies with regards to what person should be contacted in the case of needing to make changes to secrets. This slows down software development lifecycle and distracts engineers from working on things that matter the most.
|
||||
- As a general rule, before making changes in production environments, those changes have to be looked over by at least another person. An extra pair of eyes can help reduce the risk of human error and make sure that the change will not affect the application in an unintended way.
|
||||
- After making updates to secrets, the corresponding applications need to be redeployed with the right set of secrets and configurations. This process is often not automated and hence prone to human error.
|
||||
|
||||
## Solution
|
||||
|
||||
As a wide-spread software engineering practice, developers have to submit their code as a PR that needs to be approved before the code is merged into the main branch.
|
||||
As a wide-spread software engineering practice, developers have to submit their code as a PR that needs to be approved before the code is merged into the main branch.
|
||||
|
||||
In a similar way, to solve the above-mentioned issues, Infisical provides a feature called `Approval Workflows` for secret management. This is a set of policies and workflows that help advance access controls, compliance procedures, and stability of a particular environment. In other words, **Approval Workflows** help you secure, stabilize, and streamline the change of secrets in high-stakes environments.
|
||||
In a similar way, to solve the above-mentioned issues, Infisical provides a feature called `Approval Workflows` for secret management. This is a set of policies and workflows that help advance access controls, compliance procedures, and stability of a particular environment. In other words, **Approval Workflows** help you secure, stabilize, and streamline the change of secrets in high-stakes environments.
|
||||
|
||||
### Setting a policy
|
||||
|
||||
@@ -33,6 +33,10 @@ First, you would need to create a set of policies for a certain environment. In
|
||||
|
||||
The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need full approval prior merging. A **Soft** enforcement level allows for break glass functionality on the request. If a change request is bypassed, the approvers will be notified via email.
|
||||
|
||||
### Self approvals
|
||||
|
||||
If the **Self Approvals** option is enabled, users who are designated as approvers on the policy can approve requests that they themselves have submitted.
|
||||
|
||||
### Example of creating a change policy
|
||||
|
||||
When creating a policy, you can choose the type of policy you want to create. In this case, we will be creating a `Change Policy`. Other types of policies include `Access Policy` that creates policies for **[Access Requests](/documentation/platform/access-controls/access-requests)**.
|
||||
@@ -41,10 +45,18 @@ When creating a policy, you can choose the type of policy you want to create. In
|
||||
|
||||
### Example of updating secrets with Approval workflows
|
||||
|
||||
When a user submits a change to an enviropnment that is under a particular policy, a corresponsing change request will go to a predefined approver (or multiple approvers).
|
||||
When a user submits a change to an environment that is under a particular policy, a corresponding change request will go to a predefined approver (or multiple approvers).
|
||||
|
||||
|
||||
|
||||
Approvers are notified by email and/or Slack as soon as the request is initiated. In the Infisical Dashboard, they will be able to `approve` and `merge` (or `deny`) a request for a change in a particular environment. After that, depending on the workflows setup, the change will be automatically propagated to the right applications (e.g., using [Infisical Kubernetes Operator](https://infisical.com/docs/integrations/platforms/kubernetes)).
|
||||
|
||||
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Is it possible to disable self-approval for policies?">
|
||||
Yes, if you'd like to require an approval from an approver other than the one who created the request, then you can disable the **Self Approvals** feature inside of your target policy.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -15,7 +15,7 @@ Prerequisites:
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a SCIM token in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > SCIM Configuration and
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **Provisioning** tab. Under SCIM Configuration,
|
||||
press the **Enable SCIM provisioning** toggle to allow Azure to provision/deprovision users for your organization.
|
||||
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ Prerequisites:
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a SCIM token in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > SCIM Configuration and
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **Provisioning** tab. Under SCIM Configuration,
|
||||
press the **Enable SCIM provisioning** toggle to allow JumpCloud to provision/deprovision users and user groups for your organization.
|
||||
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ Prerequisites:
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a SCIM token in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > SCIM Configuration and
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **Provisioning** tab. Under SCIM Configuration,
|
||||
press the **Enable SCIM provisioning** toggle to allow Okta to provision/deprovision users and user groups for your organization.
|
||||
|
||||
|
||||
|
||||
@@ -39,8 +39,8 @@ description: "Learn how to configure Auth0 OIDC for Infisical SSO."
|
||||
|
||||
</Step>
|
||||
<Step title="Finish configuring OIDC in Infisical">
|
||||
3.1. Back in Infisical, in the Organization settings > Security > OIDC, click **Connect**.
|
||||
|
||||
3.1. Back in Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **OIDC**.
|
||||
|
||||
|
||||
3.2. For configuration type, select **Discovery URL**. Then, set **Discovery Document URL**, **JWT Signature Algorithm**, **Client ID**, and **Client Secret** from step 2.1 and 2.2.
|
||||
|
||||
|
||||
@@ -12,7 +12,9 @@ description: "Learn how to configure Auth0 SAML for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Auth0, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Auth0**, then click **Connect** again.
|
||||
|
||||
|
||||
|
||||
Next, note the **Application Callback URL** and **Audience** to use when configuring the Auth0 SAML application.
|
||||
|
||||
|
||||
@@ -12,7 +12,9 @@ description: "Learn how to configure Microsoft Entra ID for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Azure / Entra, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Azure / Entra**, then click **Connect** again.
|
||||
|
||||
|
||||
|
||||
Next, copy the **Reply URL (Assertion Consumer Service URL)** and **Identifier (Entity ID)** to use when configuring the Azure SAML application.
|
||||
|
||||
|
||||
@@ -28,8 +28,8 @@ Prerequisites:
|
||||
1.4. Access the IdP’s OIDC discovery document (usually located at `https://<idp-domain>/.well-known/openid-configuration`). This document contains important endpoints such as authorization, token, userinfo, and keys.
|
||||
</Step>
|
||||
<Step title="Finish configuring OIDC in Infisical">
|
||||
2.1. Back in Infisical, in the Organization settings > Security > OIDC, click Connect.
|
||||
|
||||
2.1. Back in Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Select **Connect** for **OIDC**.
|
||||
|
||||
|
||||
2.2. You can configure OIDC either through the Discovery URL (Recommended) or by inputting custom endpoints.
|
||||
|
||||
|
||||
@@ -12,7 +12,9 @@ description: "Learn how to configure Google SAML for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Google, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Google**, then click **Connect** again.
|
||||
|
||||
|
||||
|
||||
Next, note the **ACS URL** and **SP Entity ID** to use when configuring the Google SAML application.
|
||||
|
||||
|
||||
@@ -12,7 +12,9 @@ description: "Learn how to configure JumpCloud SAML for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select JumpCloud, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **JumpCloud**, then click **Connect** again.
|
||||
|
||||
|
||||
|
||||
Next, copy the **ACS URL** and **SP Entity ID** to use when configuring the JumpCloud SAML application.
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ Infisical groups not present in their groups claim.
|
||||
2.1. In Infisical, create any groups you would like to sync users to. Make sure the name of the Infisical group is an exact match of the Keycloak group name.
|
||||
|
||||
|
||||
2.2. Next, enable **OIDC Group Membership Mapping** in Organization Settings > Security.
|
||||
2.2. Next, enable **OIDC Group Membership Mapping** on the **Single Sign-On (SSO)** page under the **General** tab.
|
||||
|
||||
|
||||
2.3. The next time a user logs in they will be synced to their matching Keycloak groups.
|
||||
|
||||
@@ -66,8 +66,8 @@ description: "Learn how to configure Keycloak OIDC for Infisical SSO."
|
||||
|
||||
</Step>
|
||||
<Step title="Finish configuring OIDC in Infisical">
|
||||
3.1. Back in Infisical, in the Organization settings > Security > OIDC, click Connect.
|
||||
|
||||
3.1. Back in Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **OIDC**.
|
||||
|
||||
|
||||
3.2. For configuration type, select Discovery URL. Then, set the appropriate values for **Discovery Document URL**, **JWT Signature Algorithm**, **Client ID**, and **Client Secret**.
|
||||
|
||||
|
||||
@@ -12,9 +12,9 @@ description: "Learn how to configure Keycloak SAML for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Keycloak, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Keycloak**, then click **Connect** again.
|
||||
|
||||
|
||||
|
||||
|
||||
Next, copy the **Valid redirect URI** and **SP Entity ID** to use when configuring the Keycloak SAML application.
|
||||
|
||||
|
||||
@@ -12,8 +12,10 @@ description: "Learn how to configure Okta SAML 2.0 for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Okta, then click **Connect** again.
|
||||
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Okta**, then click **Connect** again.
|
||||
|
||||
|
||||
|
||||
Next, copy the **Single sign-on URL** and **Audience URI (SP Entity ID)** to use when configuring the Okta SAML 2.0 application.
|
||||
|
||||
</Step>
|
||||
|
||||
Reference in New Issue
Block a user