Skip to content

Documentation for Sigle Sign-On feature on commercial #7212

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
Jul 14, 2020
Merged
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion docs/commercial/organizations.rst
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,11 @@ The best way to think about this relationship is:

*Owners* will create *Teams* to assign permissions to all *Members*.

.. warning::

Owners, Members and Teams behave differently if you are using
:ref:`SSO with GitHub, Bitbucket or GitLab <SSO with GitHub, Bitbucket or GitLab>`.

Team Types
~~~~~~~~~~

Expand All @@ -44,4 +49,3 @@ Roadrunner would set up a *Team* called *Contractors*.
That team would have *Read Only* access to the *Road Builder* project.
Then he would add *Wile E. Coyote* to the team.
This would give him access to just this one project inside the organization.

90 changes: 90 additions & 0 deletions docs/commercial/single-sign-on.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
Single Sign-On
==============

.. note::

This feature only exists on `Read the Docs for Business <https://readthedocs.com/>`__.


Single Sign-On is supported on |com_brand| for Pro and Enterprise plans.
:abbr:`SSO (Single Sign-On)` will allow you to grant permissions to your organization's projects in an easy way.

Currently, we support two different types of Single Sign-On:

* Authentication *and* authorization are managed by the Identity Provider (e.g. GitHub, Bitbucket or GitLab)
* Authentication is managed by the Identity Provider (e.g. a ``@company.com`` verified email address)

.. note::

SSO is currently in **Beta** and only GitHub is supported for now.
If you would like to apply for the Beta, please `contact us <mailto:[email protected]>`_.

.. contents::
:local:
:depth: 2


SSO with GitHub, Bitbucket or GitLab
------------------------------------

Using an Identity Provider that supports authentication and authorization allows you to manage
"who have access to what projects on Read the Docs" directly from the provider itself.
In case you want a user to have access to your documentation project under Read the Docs,
that user just needs to be granted permissions in the GitHub, Bitbucket or GitLab repository associated with it.

Note the users created under Read the Docs must have their GitHub, Bitbucket or GitLab
Copy link
Member

@ericholscher ericholscher Jul 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think GitHub, Bitbucket or GitLab is a bit verbose, we should probably just say VCS provider or something, and explain that above:

GitHub, Bitbucket or GitLab ("VCS provider")

Maybe it's better to be explicit here though?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fine using "VCS provider" as a general concept here I think. We use "VCS account" already in other documents, https://docs.readthedocs.io/en/stable/connected-accounts.html. Probably better to stick with that term.

I think it makes sense to mention them explicitly at the beginning maybe and use the general term in the rest of the document. It's good to avoid confusions with projects imported from outside these three providers. However, they have to be imported manually which is not discoverable in .com

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some small changes for this. I left it explicit where I thought it makes sense to make it explicit and used "VCS social provider" or "VCS provider" as well.

account connected in order to make SSO to work.

.. note::

You can read more about `granting permissions on GitHub`_.

.. _granting permissions on GitHub: https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization


Grant access to read the documentation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By granting **read** (or more) permissions to a user under GitHub, Bitbucket or GitLab
you are giving access to read the documentation of the associated project on Read the Docs to that user.


Grant access to administrate a project
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By granting **write** permission to a user under GitHub, Bitbucket or GitLab
you are giving access to read the documentation *and* to be an administrator
of the associated project on Read the Docs to that user.


Grant access to import a project
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When SSO with GitHub, Bitbucket or GitLab is enabled in the organization only owners can import projects on the organization.
Adding users as owners of your organization will give them permissions to import projects.

Note that to be able to import a project, that user must have **admin** permissions in the GitHub, Bitbucket or GitLab repository associated.


SSO with a ``@company.com`` email address
-----------------------------------------

Using a ``@company.com`` email address allows you to
"grant **read** access to all the projects under your organization to users with a ``@company.com`` verified email address".


Grant access to administrate a project
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can add a user under an "Admin Team" to grant admin permissions to all the projects under that Team.
This can be done under :guilabel:`Teams` > :guilabel:`Admins` > :guilabel:`Invite Member`.


Grant access to import a project
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Making the user member of any "Admin Team" under your organization (as mentioned in the previous section),
they will be granted access to import a project.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They can only import projects into that team, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. In fact, if you are an admin, you can only import projects under the Admins teams you belong to. You cannot import projects on "Read" teams, even if you belong to --which is a bug, I'd say. See https://github.com/readthedocs/readthedocs-corporate/issues/929

I'm not sure if this has to be clarified here, since it's not related to SSO. It probably fits better on https://docs.readthedocs.io/en/stable/commercial/organizations.html


Note that to be able to import a project, that user must have at least **read** permissions in the GitHub, Bitbucket or GitLab repository associated,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems wrong, no? We can't set webhooks on these repos, and I think it isn't how it works currently right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. This is a mistake.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait... This is confusing.

Currently, without SSO, if the project is public and you have read permissions on it, you can imported it, see

self.is_locked = ko.computed(function () {
if (view.has_sso_enabled) {
return !self.admin();
}
return (self.private() && !self.admin());
});
. In that case, you will be able to import the project, but the webhook won't be connected, ssh key not setup and we will show these notifications:

Screenshot_2020-07-07_19-32-25

I changed that behavior to only make is_locked = !self.admin() only when SSO is enabled because it doesn't make sense to import a project that you are not able to modify later (GitHub SSO won't give you access to Admin tab if you don't have admin permissions in the GH repo).

Summarizing,

  • current behavior with RTD Auth, allows you to import public projects with only read permissions
  • GitHub SSO, allows you to import projects only if you admin on the GH repository
  • Verified Email, same as RTD Auth

I think, for corporate, it makes sense to always force to be admin on the GH repository to be able to import a project; because the reasons that you mentioned. After imported, you will end up with a half configured project. This would change the current behavior, tho.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this behavior to allow import projects only with admin permissions in the repository for Email SSO and VCS SSO.

I think, we should eventually do the same for RTD Auth and make all behave the same under corporate: "admin permissions on RemoteRepository are required to import a project".

and their social account connected with Read the Docs.