Accès restreint de l’appelant aux Studio de workflow flux

Suivez les flux et les actions qui nécessitent l’accès à des ressources entre champs d’application. Autorisez ou refusez aux flux et aux actions l’accès aux ressources entre périmètres.

La table Privilèges d’accès restreint pour l’appelant comporte des types de source dédiés pour identifier les Studio de workflow sources d’appel.

Flux

Le système utilise le type de source de flux pour suivre les opérations exécutées par ServiceNow les actions principales. Les enregistrements avec privilèges d’accès restreint pour l’appelant permettent à un flux d’effectuer une opération spécifique sur une ressource entre champs d’application spécifique. L’approbation d’un flux pour exécuter une opération permet à toute autre action de cœur dans le même flux d’effectuer la même opération sur la même ressource entre périmètres.

Par exemple, supposons que vous ayez un flux qui exécute l’action Rechercher des enregistrements sur une table entre périmètres. Lorsque la restriction de l’appelant est activée pour la table entre périmètres, l’action Rechercher des enregistrements génère une demande pour effectuer une opération de lecture. Lorsque vous autorisez le flux à effectuer des opérations de lecture sur la table entre périmètres, toutes les autres opérations de lecture effectuées par les actions principales peuvent également s’exécuter. Par exemple, votre flux peut exécuter les actions Rechercher un enregistrement et Rechercher des pièces jointes sur la même table entre périmètres. Supposons que vous ajoutiez l’action Rechercher des enregistrements pour la même table entre champs d’application à un autre flux ou flux secondaire. Étant donné que cette opération de lecture provient d’un autre flux, l’action principale génère une demande de privilège d’accès distincte pour approbation. Si vous configurez l’action Rechercher des enregistrements pour accéder à une autre table entre périmètres, cela génère également une demande de privilège d’accès distincte pour approbation.

Action de flux

Le système utilise le type de source d’action de flux pour suivre les opérations exécutées par des actions personnalisées sur une ressource entre champs d’application spécifique. Les enregistrements avec privilèges d’accès restreints pour l’appelant permettent à une action personnalisée d’effectuer une opération spécifique sur une ressource entre champs d’application spécifique. L’approbation d’une action pour exécuter une opération permet à l’action personnalisée d’effectuer l’opération sur la ressource entre périmètres dans n’importe quel contexte.

Par exemple, supposons que vous créiez une action personnalisée qui exécute l’étape Rechercher des enregistrements sur une table entre périmètres. Lorsque la restriction de l’appelant est activée pour la table entre périmètres, l’étape Rechercher des enregistrements génère une demande pour effectuer une opération de lecture. Lorsque vous autorisez l’action personnalisée à effectuer des opérations de lecture sur la table entre périmètres, vous pouvez exécuter l’action personnalisée à partir de n’importe quel contexte. Par exemple, vous pouvez ajouter l’action personnalisée à plusieurs flux ou appeler l’action personnalisée à partir d’un script. Tant que l’action personnalisée effectue l’opération sur la ressource inter-périmètres cible autorisée, le système autorise l’exécution de l’action personnalisée. Si vous configurez l’action personnalisée pour accéder à une autre table entre périmètres, l’action personnalisée génère une demande de privilège d’accès distincte pour approbation.

Mettre à niveau les privilèges d’accès restreint pour l’appelant pour les flux et les actions

Autoriser les instances mises à niveau à partir de versions antérieures à générer des demandes de privilège d’accès San Diego restreint pour l’appelant pour les flux et les actions.

Avant de commencer

Si vous activez l’administration d’application pour l’application cible, seuls les administrateurs d’application de l’application cible peuvent définir l’accès à une application. Si l’administration d’application n’est pas activée, un utilisateur administrateur peut définir l’accès à une application.

Rôle requis : admin ou admin d’application

Remarque :

Pour en savoir plus sur les rôles d’administrateur spécifiques aux applications et le développement délégué, consultez Règles de contrôle d’accès dans les applications d’administration d’application et Développement délégué et déploiement.

Pourquoi et quand exécuter cette tâche

Dans San Diego les versions antérieures, la table Privilèges d’accès restreint pour l’appelant ne reconnaissait pas les flux et les actions en tant que types de sources. Les clients qui souhaitaient générer des enregistrements de privilèges d’accès restreint pour l’appelant pour les flux et les actions ne pouvaient le faire qu’indirectement. Ils peuvent utiliser un include de script ou une règle métier pour appeler un flux ou une action. Lorsque l’include de script ou la règle métier est exécuté, il génère une demande de privilège d’accès à la ressource entre périmètres pour approbation.

Avertissement :

La mise à niveau des privilèges d’accès restreint pour l’appelant pour suivre les flux et les actions peut entraîner des interruptions de service sur les instances qui suivaient auparavant l’accès entre périmètres à partir d’includes de script ou de règles métier. Après la mise à niveau, l’exécution de tous les flux et actions qui tentent d’accéder à des ressources restreintes est bloquée et génère à la place leurs propres demandes de privilège d’accès restreint pour l’appelant pour approbation. Quelqu’un doit approuver les demandes de privilège d’accès pour que les flux et actions entre périmètres puissent s’exécuter. Les clients qui autorisaient déjà le suivi indirect des flux et des actions à l’aide d’appels de script peuvent ignorer cette tâche et continuer à appeler des flux et des actions à partir de scripts. Les clients qui souhaitent remplacer leurs privilèges d’accès existants par les nouveaux types de sources Flux et Action de flux peuvent planifier une panne pour générer et approuver les nouvelles demandes de privilèges d’accès.

Procédure

1. Ajoutez une propriété système .
   Créez cette propriété.

   Champ	Valeur
   Nom	com.glide.hub.flow.restricted_caller_access.track_flows_as_source
   Type	true|false
   Valeur	VRAI

2. Définissez l’accès entre périmètres à une ressource d’application .
   Activez la restriction de l’appelant pour les tables auxquelles vous souhaitez que les flux et les actions demandent l’accès.
3. Si vous remplacez des autorisations d’accès basées sur un script, identifiez les flux et actions interpérimètre existants qui nécessitent des autorisations d’accès.
   Vous devez régénérer tous les privilèges d’accès existants pour les flux et actions entre périmètres. Les privilèges d’accès au flux et à l’action remplacent les privilèges d’accès à l’include de script et à la règle métier existants.
4. Générez des demandes de privilèges d’accès pour tous les flux et actions inter-périmètres existants.
   Vous pouvez exécuter des flux et des actions entre périmètres en utilisant ou en testant l’application entre périmètres.
   Les flux et actions entre périmètres génèrent des demandes de privilèges d’accès aux tables définies sur Restriction de l’appelant.
5. Autorisez les flux et les actions à accéder à vos ressources d’application .
   Identifiez les demandes de privilège d’accès avec ces types de sources.

   • Flux
   • Action de flux

   Définissez l’état sur Autorisé pour chaque opération que vous souhaitez qu’un flux ou une action effectue sur votre ressource d’application restreinte.

Résultats

Les flux et les actions qui tentent d’accéder à vos ressources d’application restreintes génèrent une demande de privilège d’accès.

Que faire ensuite

Examinez et approuvez les demandes de privilèges d’accès à partir de votre dossier d’application.