SSO Access Control | FastComments Docs

Qu'est-ce que le contrôle d'accès ?

Avec FastComments SSO Access Control, parfois appelé RBAC, les utilisateurs peuvent être restreints à n'accéder qu'à certaines pages, ou fils de commentaires. De plus, les utilisateurs ne peuvent @mention que d'autres utilisateurs du même groupe.

En détail

Nous pouvons placer Users et, éventuellement, Pages dans des groupes.

Lorsque des Users sont placés dans des groupes, et que Limit Comments by SSO User Groups est activé dans les Paramètres du widget, alors les utilisateurs ne verront que les commentaires d'utilisateurs appartenant aux mêmes groupes et pourront uniquement @mention des utilisateurs du même groupe.

De plus, les Pages peuvent être placées dans des groupes, et les utilisateurs ne peuvent alors accéder qu'aux commentaires des pages auxquelles ils ont accès.

Nous appelons cela des groupes « User-Level » par opposition aux groupes « Page-Level ».

Lequel vous convient ?

Utilisez des groupes User-Level si...

Vous voulez utiliser la même valeur urlId (URL de la page, ou ID de l'article), mais restreindre les commentaires par groupe.
Par exemple, vous voulez avoir des groupes « New User » et « Veteran User », et ils ne devraient jamais voir les commentaires l'un de l'autre sur les mêmes pages.

Utilisez des groupes Page-Level si...

Vos groupes ont des pages spécifiques.
Par exemple, les utilisateurs du groupe « Public Pages » ne devraient jamais consulter les articles « Top Secret ».

Comment cela fonctionne

Le contrôle d'accès FastComments fonctionne en attribuant des Pages et des Users aux groupes souhaités.

Un groupe est simplement un identifiant de chaîne, comme GREEN ou abc-123.

Les Users et les Pages ne sont pas limités à un seul groupe. Ils sont limités à 100 et 1000 groupes, respectivement.

Accès aux pages non autorisées

Si un utilisateur tente d'accéder à une page à laquelle il n'a pas accès, il verra un message d'erreur, comme ci-dessous :

Exemple d'échec d'autorisation

Le texte du message peut être personnalisé.

La spécification

Définir la façon dont plusieurs utilisateurs interagissent, et le tester, est compliqué. Voici la spécification suivante que nous suivons pour le contrôle d'accès, que vous pouvez utiliser pour tester votre implémentation:

Page avec IDs de groupe null, utilisateur avec IDs de groupe null - devrait avoir accès.
Page avec IDs de groupe null, utilisateur avec des IDs de groupe - devrait avoir accès.
Page avec des IDs de groupe, utilisateur avec IDs de groupe null - devrait avoir accès.
Page avec des IDs de groupe, utilisateur avec une liste vide - NE devrait PAS avoir accès.
Page avec des IDs de groupe, utilisateur avec des IDs de groupe - intersection existe - devrait avoir accès.
Page avec des IDs de groupe, utilisateur avec des IDs de groupe - l'intersection n'existe pas - NE devrait PAS avoir accès.
Page avec une liste vide d'IDs de groupe (personne n'a accès), utilisateur avec null - NE devrait PAS avoir accès.

Utilisateur SSO A = Aucun ID de groupe défini (null = accès complet).
Utilisateur SSO B = Aucun ID de groupe défini (null = accès complet).
A peut @B.

Utilisateur SSO A = Aucun ID de groupe défini (null = accès complet).
Utilisateur SSO B = IDs de groupe définis.
A peut @B.

Utilisateur SSO A = IDs de groupe définis.
Utilisateur SSO B = Aucun ID de groupe défini (null = accès complet).
A peut @B.

Utilisateur SSO A = IDs de groupe = [a].
Utilisateur SSO B = IDs de groupe = [b].
A NE peut PAS @B.

Utilisateur SSO A = IDs de groupe = [a].
Utilisateur SSO B = IDs de groupe = [a, b].
A peut @B.

Implémentation

Mentionner des utilisateurs dans d'autres groupes

Si deux utilisateurs appartiennent à deux ensembles de groupes différents, et qu'il n'y a aucune intersection, ils ne pourront pas se @mention mutuellement.

Si un utilisateur saisit manuellement un @mention et soumet son commentaire, cela restera du texte brut. L'autre utilisateur ne sera pas mentionné.

Gestion des groupes

Les Groups sont définis en utilisant respectivement les ressources API Pages et SSOUsers.

L'API Pages peut être invoquée pour définir l'ensemble des groupes autorisés à accéder à la page. Par défaut, tous les groupes, ainsi que les utilisateurs qui n'appartiennent à aucun groupe, ont accès.

De même, l'API SSOUsers peut être invoquée pour définir les groupes associés à chaque utilisateur.

Pour les deux ressources, il n'y a pas de limitation quant au moment où les groupes peuvent être définis ou mis à jour.

Si l'on souhaite uniquement empêcher que les utilisateurs se @mention mutuellement, alors les Pages n'ont pas à être prises en compte.

Remarque !

La définition et la mise à jour des groupes d'utilisateurs SSO ne nécessitent pas l'utilisation de l'API, et peuvent à la place être mises à jour automatiquement en définissant les ids de groupe dans le payload SSO transmis au widget de commentaires. Cependant, pour de longues listes de groupes, cela n'est pas recommandé car l'utilisateur devrait soumettre ce payload à chaque chargement de page.

Exemples d'appels d'API

Here we'll walk through calling the FastComments API to setup access control.

Avant de commencer, notez que nous n'avons pas besoin de créer explicitement une structure Group. Les groupes sont simplement des identifiants ajoutés aux Users et aux Pages. L'ajout d'un groupe à un user ou à une page "crée" automatiquement le groupe.

First, let's create two users, User A and User B, we'll start them out in Group X:

Exemple cURL : Création de l’utilisateur A

Copy

curl --request POST \
  --url 'https://fastcomments.com/api/v1/sso-users?tenantId=demo&API_KEY=DEMO_API_SECRET' \
  --header 'Content-Type: application/json' \
  --data '{
    "id": "user-a",
    "username": "User A",
    "email": "usera@example.com",
    "groupIds": ["GROUP-X"]
}'

Exemple cURL : Création de l’utilisateur B

Copy

curl --request POST \
  --url 'https://fastcomments.com/api/v1/sso-users?tenantId=demo&API_KEY=DEMO_API_SECRET' \
  --header 'Content-Type: application/json' \
  --data '{
    "id": "user-b",
    "username": "User B",
    "email": "userb@example.com",
    "groupIds": ["GROUP-X"]
}'

Now let's create a Page. We'll call it our Confidential Page, and so far none of these users will have access to it as it will be in the group CONFIDENTIAL:

Exemple cURL : création de page

Copy

curl --request POST \
  --url 'https://fastcomments.com/api/v1/pages?tenantId=demo&API_KEY=DEMO_API_SECRET' \
  --header 'Content-Type: application/json' \
  --data '{
    "title": "Confidential Page",
    "url": "https://mysite.com/confidential",
    "urlId": "https://mysite.com/confidential",
    "accessibleByGroupIds": ["CONFIDENTIAL"]
}'

Users A and B currently DO NOT have access to the new page. However, since they are in the same group, GROUP-X, they can @mention each other.

Let's update User B so they can now access the page:

Exemple cURL : Mise à jour de l’utilisateur B

Copy

curl --request POST \
  --url 'https://fastcomments.com/api/v1/sso-users?tenantId=demo&API_KEY=DEMO_API_SECRET' \
  --header 'Content-Type: application/json' \
  --data '{
    "groupIds": ["GROUP-X", "CONFIDENTIAL"]
}'

User B now belongs to both groups. Our users can still @mention each other, but only User B can view our confidential page.

Let's make it so User B can only view the confidential page:

Exemple cURL : Mise à jour de l’utilisateur B

Copy

curl --request POST \
  --url 'https://fastcomments.com/api/v1/sso-users?tenantId=demo&API_KEY=DEMO_API_SECRET' \
  --header 'Content-Type: application/json' \
  --data '{
    "groupIds": ["CONFIDENTIAL"]
}'

Now they can view the confidential page, but neither of our users can @mention each other, as they are in different groups.

However, any user that is not part of access control will be able to access our page. To prevent this, ensure no SSO Users have their groupIds set to null. For example, let's create User C, which has access to everything:

Exemple cURL : Création de l’utilisateur C

Copy

curl --request POST \
  --url 'https://fastcomments.com/api/v1/sso-users?tenantId=demo&API_KEY=DEMO_API_SECRET' \
  --header 'Content-Type: application/json' \
  --data '{
    "id": "user-c",
    "username": "User C",
    "email": "userc@example.com",
    "groupIds": null
}'

By setting groupIds to null, we say they are not limited by access control.

Now, let's create a page that everyone has access to:

Exemple cURL : création de page

Copy

curl --request POST \
  --url 'https://fastcomments.com/api/v1/pages?tenantId=demo&API_KEY=DEMO_API_SECRET' \
  --header 'Content-Type: application/json' \
  --data '{
    "title": "Public Page",
    "url": "https://mysite.com/public",
    "urlId": "https://mysite.com/public",
    "accessibleByGroupIds": null
}'

By setting accessibleByGroupIds to null, we say this Page is not controlled via access control, and both users can access it.

This completes our API walk-through for Access Control.

Langue 🇫🇷 Français (France)

Contexte

Implémentation

Qu'est-ce que le contrôle d'accès ?

En détail

Utilisez des groupes User-Level si...

Utilisez des groupes Page-Level si...

Comment cela fonctionne

Accès aux pages non autorisées

La spécification

Implémentation

Mentionner des utilisateurs dans d'autres groupes

Gestion des groupes

Remarque !

Exemples d'appels d'API