DOCS-2755 New SSO #1460
DOCS-2755 New SSO #1460
Conversation
✅ Deploy Preview for pensive-dubinsky-5f7a00 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
|
||
| [doc-admin-sso-gsuite]: gsuite/overview.md | ||
| [doc-admin-sso-okta]: okta/overview.md | ||
| You can use single sign‑on (SSO) technology to authenticate your company's users to the Wallarm Console if your company already uses a SAML SSO solution. Wallarm can be integrated with any solution that supports the SAML standard. |
There was a problem hiding this comment.
"if your company already uses a SAML SSO solution" - it is extra, can be deleted
There was a problem hiding this comment.
I would also introduce here the "service provider" and "identity provider" terms.
You can use single sign‑on (SSO) technology to authenticate your company's users to the Wallarm Console. Wallarm seamlessly integrates with any identity provider (IdP) that supports the SAML standard, such as Google or Okta, while acting as the service provider (SP).
|
|
||
| [link-saml]: https://wiki.oasis-open.org/security/FrontPage | ||
| [link-saml-sso-roles]: https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf | ||
|  |
There was a problem hiding this comment.
on the screenhot, there is the Custom SSO integration, what is it? it is not explained now in docs
There was a problem hiding this comment.
In the previous paragraph, we say "seamlessly integrates with any identity provider" and "such as Google or Okta" (shown on the screenshot), so custom = not Google or Okta, something else.
There was a problem hiding this comment.
Fixed in other comment
| The documents related to the configuration and operation of Wallarm with SSO assume the following: | ||
| * Wallarm acts as a **service provider** (SP). | ||
| * Google or Okta acts as an **identity provider** (IdP). | ||
| With **provisioning off**, for users that you have in your SAML SSO solution, you will need to create corresponding users in Wallarm. User roles will also be defined in Wallarm and you will be able to select users that should login via SSO - the remaining will use login/password. |
There was a problem hiding this comment.
I would combine this and the next paragraphs into a single paragraph.
With provisioning off, for users that you have in your SAML SSO solution, you will need to create corresponding users in Wallarm. User roles are defined within Wallarm, and you can either enable SSO authentication for all company users or select specific users to log in via SSO, while others continue using login/password.
and generally - remember that we try not to use future tense in the technical documentation - I've shared this best practice a while ago
There was a problem hiding this comment.
we also need to explain that when sso is enabled, 2fa and login/pass auth is not available. not here but in the explanation of sso
|
|
||
| 1. In Wallarm Console, go to **Integrations** → **SSO SAML AUTHENTICATION** and initiate the appropriate integration. Note that only one SSO integration can be active at the moment. | ||
|
|
||
|  |
There was a problem hiding this comment.
here is the best place to explain what is custom sso
| 1. In the SSO configuration wizard, at the **Send details** step, overview the metadata to be sent to your SAML SSO solution. | ||
| 1. Copy metadata or save them as XML. | ||
|
|
||
| See example for [G Suite](sso-gsuite.md#step-2-wallarm-generate-metadata). |
There was a problem hiding this comment.
I would suggest to delete the example links from here and would only keep them in the very beginning
|
|
||
| By default, SSO service for authentication in Wallarm is not active, corresponding blocks are not visible in the **Integrations** section in Wallarm Console. | ||
|
|
||
| To activate the SSO service, contact the [Wallarm support team](mailto:[email protected]). |
There was a problem hiding this comment.
important thing is that once we enable sso for a customer, we provide them with a dedicated domain for accessing Wallarm Console via SSO. however I am not sure if this happens in 100% of cases and what happens if both - login/password and sso auth are available (and when two step auth enabled?) . the document https://docs.wallarm.com/user-guides/use-sso/ has been deleted but very important information from this guide is not provided
There was a problem hiding this comment.
This guide is not relevant anymore. The SSO that we position as "the only one" does not allow any authentication besides SSO. Yes, the domain is provided in 100% of cases, it is done by support (step "activate sso").
2FA in my understanding is compatible only with password authentication.
| * `partner_analytic` (**Global Analyst**) | ||
| * `partner_auditor` (**Global Read Only**) | ||
|
|
||
| See all role descriptions [here](../../../user-guides/settings/users.md#user-roles). Contact the [Wallarm support team](mailto:[email protected]) to get more roles available. |
There was a problem hiding this comment.
to get more roles available.?????? how? it is strange, we provide a dedicated list of roles. the same for other documents with the same statement
|
|
||
| **Turning provisioning off** | ||
|
|
||
| You can turn the provisioning option off. If it is off, for users that you have in your SAML SSO solution, you will need to create corresponding users in Wallarm. User roles will also be defined in Wallarm. |
There was a problem hiding this comment.
You can turn the provisioning option off by contacting the Wallarm Support Team. If it is off, for users that you have in your SAML SSO solution, you will need to create corresponding users in Wallarm. User roles should also be defined in Wallarm Console.
There was a problem hiding this comment.
notice the link! our support team has their own portal
There was a problem hiding this comment.
Changed the link here, but we have "mailto" link in all other places in the docs.
|
|
||
| You can turn the provisioning option off. If it is off, for users that you have in your SAML SSO solution, you will need to create corresponding users in Wallarm. User roles will also be defined in Wallarm. | ||
|
|
||
| To turn the **provisioning off**, contact the [Wallarm support team](mailto:[email protected]). |
|
|
||
| To turn the **provisioning off**, contact the [Wallarm support team](mailto:[email protected]). | ||
|
|
||
| With provisioning turned off, you should manually create users, set their roles and select users that should login via SSO - the remaining will use login/password. You can also enable **Strict SSO** option which enables SSO authentication for all company account users at once. Other characteristics of Strict SSO are: |
There was a problem hiding this comment.
it is a mess. the paragraph describes everything - how it works when provisioning is off, what is strict sso. it is the bad practice
There was a problem hiding this comment.
better to have a dedicated strict sso block with good exlanation
There was a problem hiding this comment.
strict sso is enabled via the support team afaik
There was a problem hiding this comment.
This was done for purpose: we hide the entire "Turning provisioning off" not giving it a separate section. And strict sso is only tiny option for the case when provisioning is off.
There was a problem hiding this comment.
strict sso is enabled via the support team afaik
That is true. Fixed.
| 1. Do one of the following: | ||
|
|
||
| * Upload G Suite metadata as an XML file. | ||
| * Enter metadata manually as follows. |
| * Upload G Suite metadata as an XML file. | ||
| * Enter metadata manually as follows. | ||
|
|
||
| 1. Complete SSO configuration wizard. Connection between Wallarm to SAML SSO solution will be tested. |
There was a problem hiding this comment.
will be tested? by whom? what does it mean?
| ## Step 5 (Wallarm): Enter SSO SAML solution metadata | ||
|
|
||
| 1. In Wallarm Console, in the SSO configuration wizard, proceed to the **Upload metadata** step. | ||
| 1. Do one of the following: |
There was a problem hiding this comment.
you can skip the below unnumbered list here. and say: Either upload G Suite metadata as an XML file or enter metadata manually.
btw - metadata from where???? "metadata provided by your identity provider"?
There was a problem hiding this comment.
As in examples, the bulleted list makes sense; it is better to keep it here as well.
metadata from where????
Step name is "Enter SSO SAML solution metadata"
| [img-sp-wizard-finish]: ../../../../images/admin-guides/configuration-guides/sso/gsuite/sp-wizard-finish.png | ||
|
|
||
| This guide covers the process of connecting the [G Suite](https://gsuite.google.com/) (Google) service as an identity provider to Wallarm, which acts as the service provider. | ||
|
|
There was a problem hiding this comment.
nothing is sais about required user role on g suite side to perform this integration. please delete the documents very carefully, review this one https://docs.wallarm.com/admin-en/configuration-guides/sso/gsuite/overview/
There was a problem hiding this comment.
Added, but I think we had a lot of redundant info in old versions, including this one. Configuring intergrations and performing steps in ADNIN consoles of G Suite and Okta are obviously administrator tasks.
|
|
||
| ## Step 3 (G Suite): Configure application | ||
|
|
||
| !!! info "Prerequisites" |
There was a problem hiding this comment.
to be honest, this info block and the next warning block are useless
There was a problem hiding this comment.
I wouls just delete them
| !!! warning | ||
| Ensure that you replace the sample values for the **ACS URL** and **Entity ID** parameters with the real ones obtained in the previous step. | ||
|
|
||
| To configure application in G Suite: |
There was a problem hiding this comment.
in the original document from production, attribution is done as the 5th step if configuring application, did it change? can you test the flow?
There was a problem hiding this comment.
The flow has changed in some aspects. The thing that really changes is how we position elements of this flow: as now the "provisioning" option is crucial, it deserves the separate step (or even two, if performed on both sides)
There was a problem hiding this comment.
I went through flows for Google and Okta during demos from the team.
|
|
||
| ![Entering the metadata manually][img-transfer-metadata-manually] | ||
|
|
||
| 1. Complete SSO configuration wizard. Wallarm to G Suite connection will be tested. |
There was a problem hiding this comment.
the part about testing is really confusing everywhere. in addition to that, the screenshot states to go to the users page and enable sso for some, however this is not required with the new flow introduced, right?
There was a problem hiding this comment.
This is correct - this step is not needed, deleted the outdated screenshots.
|
|
||
| 1. Complete SSO configuration wizard. Wallarm to G Suite connection will be tested. | ||
|
|
||
| ![Completing SSO wizard][img-sp-wizard-finish] |
There was a problem hiding this comment.
the content from https://docs.wallarm.com/admin-en/configuration-guides/sso/gsuite/allow-access-to-wl/ is missed, I do not understand if this is needed for all options of SSO or what?
There was a problem hiding this comment.
This step is now within "Step X (SAML SSO solution): Configure application".
|
|
||
| 1. Complete SSO configuration wizard. Wallarm to G Suite connection will be tested. | ||
|
|
||
| ![Completing SSO wizard][img-sp-wizard-finish] |
There was a problem hiding this comment.
all the same comments for the okta document I suppose. also, it would be better if you make the include file with the information on attribution
There was a problem hiding this comment.
The provisioning is configured (this configuration we may call "attribution") differently for Okta and Google (this is the latest change that came after these comments).
| * All new users get the SSO as the authentication method by default. | ||
| * Authentication method cannot be switched to anything different from SSO for any user. | ||
|
|
||
| When provisioning is off, user management is performed in Wallarm Console → **Settings** → **Users** as described [here](../../../user-guides/settings/users.md). Mapping with SAML SSO solution uses the `email` attribute. |
There was a problem hiding this comment.
this must be said in the end of the setup flow because this is the next logical step after everything is configured
There was a problem hiding this comment.
These couple of paragraphs briefly describe the situation with provisioning "off," so everything related can be only here.
| For this to work, provide the attribute mapping: | ||
|
|
||
| 1. In G Suite application, via **Add new mapping**, map: | ||
|
|
There was a problem hiding this comment.
and as for regular sso? only email should be mapped?
There was a problem hiding this comment.
As we agreed, we describe only the main flow. The fact that with provisioning off (= "regular sso") we need only email, is mentioned where we describe "provisioning off".
| This article describes the generic flow of enabling and configuring Wallarm's [SAML SSO Authentication](intro.md). | ||
|
|
||
| You can also get acquainted with examples for [G Suite](sso-gsuite.md) and [Okta](sso-okta.md) SAML SSO solutions. | ||
|
|
There was a problem hiding this comment.
in this document, it is also useful to reflect info about disabling and removing sso integration, briefly
There was a problem hiding this comment.
| @@ -3,16 +3,7 @@ publish = "site" | |||
| command = """ | |||
| pip3 install --no-cache-dir -r requirements.txt && | |||
There was a problem hiding this comment.
do not forget to revert before merge
There was a problem hiding this comment.
and also do not forget about redirections
|
|
||
| When SSO is enabled for the user, authentication for [requests to Wallarm API](../../../api/overview.md#your-own-api-client) becomes unavailable for this user. To get working API credentials, different options depending on the SSO [mode](intro.md#sso-modes): | ||
|
|
||
| * If **Simple SSO** or **Strict SSO (legacy)** mode is used, you can enable API authentication for the SSO users with the **Administrator** role. To do this, select **Enable API access** from this user menu. The `SSO+API` auth method is enabled for the user which allows creating API tokens. |
There was a problem hiding this comment.
do we still use the (legacy) suffix?
|
|
||
| * If **Simple SSO (legacy)** mode is used, create user without SSO option under your company account, and create [API token(s)](../../../api/overview.md#your-own-api-client). | ||
|
|
||
| ### Cannot sign in issues |
There was a problem hiding this comment.
is the following only for strict sso?
There was a problem hiding this comment.
Only first row (fixed) of the table. The remaining are universal.
| @@ -1,4 +1,4 @@ | |||
| # Configuring SSO authentication for users | |||
| # Selecting SSO Users | |||
|
|
|||
There was a problem hiding this comment.
will these document be deleted?
No description provided.