Notes de mise à jour d'Okta Identity Governance

Fonctionnalités et améliorations

Correctifs

• Les applications qui n'avaient aucun droit n'étaient pas répertoriées comme un élément de révision dans les campagnes des utilisateurs. (OKTA-1120669)

• Une remédiation manuelle était nécessaire lorsque les réviseurs révoquaient l'accès d'un utilisateur aux groupes issus d'Active Directory au sein d'une campagne. (OKTA-1167090)

Correctifs

Correctifs

Correctifs

Fonctionnalités et améliorations

Certifier les collections de ressources - Campagnes utilisateurs

Exécutez des campagnes de certification d'accès destinées aux utilisateurs pour certifier l'accès des utilisateurs aux collections de ressources. L'exécution de campagnes utilisateur qui incluent des collections vous permet de réduire le volume d'éléments à réviser par les réviseurs et d'accélérer la finalisation des campagnes. À l'aide des paramètres Informations contextuelles, vous pouvez également fournir aux réviseurs le contexte nécessaire pour les aider à prendre des décisions éclairées et plus précises. Consultez Créer des campagnes utilisateurs.

Il s'agit d'une version en accès anticipé. Consultez la section Activer les fonctionnalités en libre-service.

Correctifs

Vous pouvez sélectionner des utilisateurs désactivés ou suspendus dans le menu déroulant Demander au nom de. (OKTA-1095701)

Le bouton Modifier l'accès n'était pas mis à jour pour gérer l'accès. (OKTA-1107686)

Les contrôles d'accès de sécurité sont généralement disponibles dans les environnements de production

Les contrôles d'accès de sécurité constituent un nouveau type de contrôle d'accès utilisateur axé sur la sécurité, qui peut être déclenché automatiquement par des événements. Ces contrôles offrent une vue d'ensemble des accès d'un utilisateur, ainsi que des informations contextuelles sur son historique d'accès, notamment un résumé généré par l'IA, ce qui vous permet d'enquêter et de prendre immédiatement des mesures de correction, telles que la révocation des droits d'accès. Vous avez également la possibilité d'activer ou de désactiver le résumé de l'IA à partir de l'onglet Gouvernance IA de la page Paramètres. Consulter Contrôles d'accès de sécurité.

La fonctionnalité Access Requests pour les groupes AD est généralement disponible dans les environnements de production

Vous pouvez maintenant gérer les demandes d'accès pour les groupes provenant d'Active Directory (AD) directement à partir d'Okta. Cela vous permet d'utiliser des groupes AD lors de la configuration des conditions de requête d'accès et permet aux utilisateurs de demander une appartenance directement depuis leur tableau de bord Okta. Lorsqu'une requête est approuvée, l'accès du demandeur est accordé sur AD. Il est également supprimé lorsqu'il expire (s'il est lié au temps). De plus, si vous sélectionnez le responsable de la ressource en tant que destinataire de la tâche dans une séquence d'approbation, la tâche est attribuée au responsable du groupe provenant d'AD. Cette fonctionnalité élimine le besoin de groupes Okta en double ou de workflows personnalisés et prend en charge la création d'une posture de sécurité forte avec un accès limité dans le temps. Consulter Gouvernance des accès pour les groupes AD.

La possibilité de faire remonter des tâches est en disponibilité générale dans les environnements de production

Les administrateurs des requêtes d'accès et les destinataires des requêtes peuvent rediriger l'accès aux tâches bloquées au sein d'une requête vers le responsable du chargé de requêtes. Les demandeurs peuvent également faire remonter des tâches dans leurs Requêtes d'accès si vous avez activé le commutateur Autoriser les demandeurs à faire remonter les tâches sur la page Paramètres. Cela permet d'accélérer la résolution des requêtes, d'éviter les goulots d'étranglement, d'améliorer la productivité et de réduire le recours à des solutions de contournement risquées. Faire remonter des tâches est un processus sécurisé, auditable et automatisé qui vous aide à adopter des modèles de demande d'accès basés sur le temps en prenant en charge à la fois des opérations efficaces et des postures de sécurité strictes. Consulter Transmettre les tâches et Autoriser les demandeurs à réattribur des tâches.

Modifications apportées au rapport de synthèse sur les campagnes

Si une permission de l'utilisateur prédéfinie est sélectionnée pour une campagne de ressources, la colonne permission de l'utilisateur du rapport de synthèse sur la campagne indique désormais, en fonction de la sélection, Utilisateurs sans activité récente ou Utilisateurs avec des conflits SOD.

Nouvelle interface pour les notifications par e-mail des demandes d'accès

Les notifications par e-mail des requêtes d'accès ont une nouvelle interface, y compris des mises à jour de l'alignement du texte, des couleurs utilisées, de l'emplacement du logo Okta et l'ajout d'un arrière-plan gris.

Modifications de la fonctionnalité relative aux propriétaires de groupe dans les séquences d'approbation

Pour les séquences d'approbation, vous pouvez désormais sélectionner l'option Propriétaire de la ressource si vous souhaitez attribuer la tâche au propriétaire du groupe indiqué dans le champ Niveau d'accès de la condition de la requête d'accès. Toutes les séquences d'approbation existantes qui avaient des tâches attribuées à une combinaison de propriétaire du groupe et de groupe demandé ont été automatiquement mises à jour en Propriétaire de la ressource. Vous pouvez continuer à utiliser l'option Propriétaire du groupe pour attribuer des tâches aux propriétaires d'autres groupes (non précisés dans le niveau d'accès de la condition de la requête d'accès). En outre, les modèles de séquences d'approbation suivants ont été renommés :

• Justification et approbation du propriétaire du groupe est désormais Justification + Approbation du propriétaire de la ressource

• Approbations du responsable, des membres du groupe et du propriétaire est désormais Approbations du responsable, des membres du groupe et du propriétaire de la ressource

Consultez Configurer une séquence d'approbation.

L'appartenance à un groupe d'applications n'était pas reflétée correctement lorsque les groupes d'app étaient inclus en tant que ressources dans la permission de la campagne. (OKTA-1080290)

Certifier les comptes de service

Vous pouvez désormais créer des campagnes de gestion des ressources afin de vérifier et de certifier les droits d'accès tant pour les comptes d'applications SaaS que pour les comptes de service Okta. Cette fonctionnalité étend votre stratégie de gouvernance aux identités non humaines, vous assurant ainsi de conserver la visibilité et le contrôle sur les accès aux compte de service critiques. Consultez Certifier des comptes de service.

Il s'agit d'une version en accès anticipé. Consultez Activer les fonctionnalités en libre-service.

Governance for Workflows

Vous pouvez désormais utiliser Okta Identity Governance pour gérer l'accès aux rôles Workflows . Cela vous aide à vous assurer que l'accès à Workflows est accordé de manière cohérente et en conformité avec les exigences de votre entreprise. Voir Governance des Workflows.

Il s'agit d'une version en accès anticipé. Consultez Activer les fonctionnalités en libre-service.

La fonctionnalité Access Requests pour les groupes AD est généralement disponible dans les environnements d'aperçu

Vous pouvez maintenant gérer les requêtes d'accès pour les groupes provenant d'Active Directory (AD) directement à partir d'Okta. Cela vous permet d'utiliser des groupes AD lors de la configuration des conditions de requête d'accès et permet aux utilisateurs de demander une appartenance directement depuis leur tableau de bord Okta. Lorsqu'une requête est approuvée, l'accès du demandeur est accordé sur AD. Il est également supprimé lorsqu'il expire (s'il est lié au temps). De plus, si vous sélectionnez le responsable de la ressource en tant que destinataire de la tâche dans une séquence d'approbation, la tâche est attribuée au responsable du groupe provenant d'AD. Cette fonctionnalité élimine le besoin de groupes Okta en double ou de workflows personnalisés et prend en charge la création d'une posture de sécurité forte avec un accès limité dans le temps. Consulter Gouvernance des accès pour les groupes AD.

Cette fonctionnalité est généralement disponible dans les environnements d'aperçu et est une version en accès anticipé pour les environnements de production.

La possibilité de faire remonter des tâches est en disponibilité générale dans les environnements d'aperçu

Les administrateurs des requêtes d'accès et les destinataires des requêtes peuvent rediriger l'accès aux tâches bloquées au sein d'une requête vers le responsable du chargé de requêtes. Les demandeurs peuvent également faire remonter des tâches dans leurs Requêtes d'accès si vous avez activé le commutateur Autoriser les demandeurs à faire remonter les tâches sur la page Paramètres. Cela permet d'accélérer la résolution des requêtes, d'éviter les goulots d'étranglement, d'améliorer la productivité et de réduire le recours à des solutions de contournement risquées. Faire remonter des tâches est un processus sécurisé, auditable et automatisé qui vous aide à adopter des modèles de demande d'accès basés sur le temps en prenant en charge à la fois des opérations efficaces et des postures de sécurité strictes. Consulter Transmettre les tâches et Autoriser les demandeurs à réattribur des tâches.

Cette fonctionnalité est généralement disponible dans les environnements d'aperçu et est une version en accès anticipé pour les environnements de production.

Les étiquettes de ressources sont désormais disponibles dans les environnements de production

Définissez des étiquettes pour les ressources dans Okta afin d'améliorer la visibilité, le filtrage et l'automatisation au sein d'Access Certifications lors de la définition de la portée et de la gestion des campagnes. Consulter Étiquettes de ressources.

Mises à jour des flux délégués

Les flux délégués incluent désormais un champ de saisie Appelant. Cela vous permet de transmettre plus d'informations à un flux qui a été appelé depuis un autre produit Okta. Par exemple, le champ requestID de Demandes d'accès est désormais transmis au flux délégué. Voir Créer un flux délégué.

Modifications de l'approbation des requête d'accès par e-mail

Lorsque vous approuvez ou refusez des requêtes par e-mail, vous disposez désormais de cinq secondes après avoir cliqué sur Approuver ou Refuser pour annuler votre décision si vous vous êtes trompé. Après cela, votre décision sera automatiquement appliquée.

Modifications de la fonctionnalité d'aperçu utilisateur

Sur la page Utilisateur de l'assistant de campagne, Aperçu utilisateur s'appelle désormais Aperçu de la portée d'expression. Lorsque vous prévisualisez un utilisateur, Okta valide uniquement l'utilisateur par rapport à l'expression du Okta Expression Language que vous avez spécifiée. Un utilisateur qui correspond à l'expression, mais qui n'est affecté à aucune ressource dans la campagne, ne sera pas inclus dans la campagne.

Les règles relatives à la séparation des responsabilités et les avertissements concernant les conflits d'intérêts n'empêchaient pas les demandeurs de soumettre des demandes susceptibles d'entraîner un conflit au regard de ces règles. (OKTA-1076749)

Les groupes Active Directory n'étaient pas inclus en tant que ressources dans la portée de la campagne. (OKTA-1080290)

Certains administrateurs ne parvenaient pas à créer ou à lancer des vérifications de la sécurité depuis Admin Console dans les environnements de production. (OKTA-1053960)

Les contrôles d'accès de sécurité sont généralement disponibles dans les environnements d'aperçu

Les contrôles d'accès de sécurité constituent un nouveau type de contrôle d'accès utilisateur axé sur la sécurité, qui peut être déclenché automatiquement par des événements. Ces contrôles offrent une vue d'ensemble des accès d'un utilisateur, ainsi que des informations contextuelles sur son historique d'accès, notamment un résumé généré par l'IA. Cela vous permet d'enquêter et de prendre des mesures correctives immédiates, comme révoquer un accès. Vous avez également la possibilité d'activer ou de désactiver le résumé de l'IA à partir de l'onglet Gouvernance IA de la page Paramètres. Consulter Contrôles d'accès de sécurité.

Les modifications apportées aux contrôles d'accès de sécurité sont généralement disponibles dans les environnements d'aperçu

• Pour les ressources qui nécessitent une remédiation manuelle, les réviseurs peuvent désormais sélectionner Révoquer l'accès ou Restaurer l'accès. Lorsqu'un évaluateur sélectionne ces éléments, Okta enregistre cette action dans l'historique des évaluations afin qu'un administrateur puisse prendre des mesures de correction manuellement. Okta déclenche également un événement access.review.action dans le System Log . Consulter Passer en revue l'accès.

• Vous pouvez désormais mettre à jour le réviseur et la date de fin d'une révision d'accès de sécurité après son lancement. Consulter Gérer les contrôles d'accès de sécurité.

L'historique des droits est généralement disponible dans les environnements d'aperçu.

Les administrateurs peuvent désormais consulter l'historique des droits d'un utilisateur. Cette fonctionnalité améliore les tâches d'audit et de conformité, ainsi que la visibilité pour le dépannage des problèmes d'accès. Consulter Afficher les droits des utilisateurs.

Les propriétaires de ressources sont généralement disponibles dans les environnements de production

Attribuez des propriétaires à des groupes, des applications, des droits et des ensembles de droits. Cette fonctionnalité vous permet de rediriger automatiquement les étapes des requête d'accès et les révisions des campagnes d'Access Certification vers les bonnes parties prenantes, améliorant l'efficacité et la précision de vos processus de gouvernance. Cela permet également de s'assurer que les bonnes parties prenantes sont toujours impliquées dans les décisions d'accès sans nécessiter de mises à jour manuelles de vos configurations.

• Access Requests : lors de la configuration des séquences d'approbation dans les conditions des requêtes d'accès, vous pouvez désormais attribuer des approbations, des tâches ou des questions directement aux propriétaires des ressources. Configurer une séquence d'approbation.

• Access Certifications : lors de la création de campagnes de certification, vous pouvez désormais sélectionner le propriétaire de la ressource comme réviseur désigné. Voir la section Examens des campagnes de certification.

Consulter Propriétaires de ressources.

La fonctionnalité de sécurité renforcée pour l'application Web Okta Access Requests est généralement disponible dans les environnements de production

L'application Web Okta Access Requests effectue désormais des évaluations de stratégie avant d'accorder de nouveaux jetons d'accès.

La fonctionnalité permettant d'exporter les rapports Okta Identity Governance au format PDF est généralement disponible dans les environnements de production

Vous pouvez désormais exporter les rapports Okta Identity Governance au format PDF. Lors de l'exportation, vous pouvez également sélectionner des colonnes spécifiques à inclure dans le rapport.

Universal Logout pour l'application Web Okta Access Requests

L'application Web Okta Access Requests prend désormais en charge Universal Logout. Cela permet aux administrateurs de déconnecter automatiquement les utilisateurs de cette app lorsque Universal Logout est déclenchée.

La fonctionnalité de sécurité renforcée pour l'application Web Okta Access Requests est généralement disponible dans les environnements d'aperçu

L'application Web Okta Access Requests effectue désormais des évaluations de stratégie avant d'accorder de nouveaux jetons d'accès.

• Lors de la modification d'un type de requête ou de l'utilisation d'une requête gérée par des types de requête, les libellés des menus déroulants et des champs ne s'affichaient pas correctement et leurs info-bulles ne s'affichaient pas au survol. (OKTA-993083)

• Les utilisateurs disposant des rôles Requête d'accès et Administrateur d'application pouvaient voir l'onglet Requête d'accès sur la page de profil de diverses applications, même si le rôle d'administrateur d'application était doté de permissions limitées à une application particulière. (OKTA-1030035)

• L'onglet Requête d'accès était affiché sur la page de profil de l'application pour les applications de services API . (OKTA-1035925)

• Le rapport Modifications de l'accès aux ressources – Lancement de la campagne vers campagne terminée comprenait des détails sur les utilisateurs qui n'étaient pas inclus dans la permission de l'utilisateur de la campagne. (OKTA-1038132)

• Les API Access Request – V2 ne prenaient pas en charge le flux d'authentification par identifiants client. (OKTA-1044065)

• La section Historique du panneau Détails des révisions n'affichait pas la décision du réviseur si les informations relatives au créateur de la campagne étaient manquantes pour les campagnes récurrentes avec des révisions à plusieurs niveaux. (OKTA-1046833)

• Le flux des identifiants du client pour les applications de services API ne fonctionnait pas pour certaines requêtes API de gouvernance. (OKTA-926552)

• Les administrateurs ne pouvaient pas exporter les rapports sur les requêtes d'accès passées au format PDF. (OKTA-997865)

L'exportation des rapports Okta Identity Governance au format PDF est généralement disponible dans les environnements d'aperçu.

Vous pouvez désormais exporter les rapports Okta Identity Governance au format PDF. Lors de l'exportation, vous pouvez également sélectionner des colonnes spécifiques à inclure dans le rapport.

L'historique des droits est généralement disponible dans les environnements d'aperçu.

Les administrateurs peuvent désormais consulter l'historique des droits d'un utilisateur. Cette fonctionnalité améliore les tâches d'audit et de conformité, ainsi que la visibilité pour le dépannage des problèmes d'accès. Consulter Afficher les droits des utilisateurs.

Les propriétaires de ressources sont généralement disponibles dans les environnements d'aperçu

Attribuez des propriétaires à des groupes, des applications, des droits et des ensembles de droits. Cette fonctionnalité vous permet de rediriger automatiquement les étapes des requête d'accès et les révisions des campagnes d'Access Certification vers les bonnes parties prenantes, améliorant l'efficacité et la précision de vos processus de gouvernance. Cela permet également de s'assurer que les bonnes parties prenantes sont toujours impliquées dans les décisions d'accès sans nécessiter de mises à jour manuelles de vos configurations.

• Demandes d'accès

  Lors de la configuration des séquences d'approbation dans les conditions des requêtes d'accès, vous pouvez désormais attribuer des approbations, des tâches ou des questions directement aux propriétaires des ressources. Configurer une séquence d'approbation.

• Certifications d'accès

  Lors de la création de campagnes de certification, vous pouvez désormais sélectionner le propriétaire de la ressource comme réviseur désigné. Voir la section Examens des campagnes de certification.

Consulter Propriétaires de ressources.

Les étiquettes de ressources sont généralement disponibles dans les environnements d'aperçu

Définissez des étiquettes pour les ressources dans Okta afin d'améliorer la visibilité, le filtrage et l'automatisation au sein d'Access Certifications lors de la définition de la portée et de la gestion des campagnes. Consulter Étiquettes de ressources.

Le package de rapport d'audit est généralement disponible dans les environnements de production.

Utilisez cette fonctionnalité pour générer automatiquement des rapports de campagne de certification d'accès, qui sont personnalisés pour répondre aux exigences des auditeurs. Ces rapports accélèrent et simplifient la préparation des audits de conformité en réduisant le temps et les activités manuelles requis pour assembler et exporter les données de campagne et d'accès des utilisateurs. Consulter Package de rapports pour l'auditeur.

Les délégués de gouvernance sont généralement disponibles dans les environnements de production

Vous pouvez définir des délégués pour les utilisateurs ou autoriser les utilisateurs à désigner un autre utilisateur comme délégué qui effectuera des tâches de gouvernance à leur place. Les tâches Governance comprennent les éléments de révision des campagnes de certification d'accès et les approbations des demandes d'accès, les questions et d'autres tâches. Une fois qu'un délégué est spécifié, toutes les tâches Governance futures (approbations des demandes d'accès et révisions des certifications accès) sont affectées au délégué au lieu de l'approbateur ou du réviseur d'origine. Cela permet de s'assurer que les processus Governance ne se bloquent pas lorsque les approbateurs sont indisponibles ou que les tâches doivent être redirigées vers d'autres parties prenantes pendant une longue période. Cela permet également de réduire le temps passé à réaffecter manuellement les requêtes et les révisions. Consulter Délégués dans Governance.

Nouvel événement dans le journal système

L' événement governance.settings.update du System Log est déclenché lorsque les super-administrateurs modifient les paramètres de délégation afin d'autoriser ou d'empêcher les utilisateurs de désigner leur propre délégué.

Modifications des notifications de demande d'accès

Afin de garantir l'affichage cohérent des conversations sur toutes les plateformes, les messages envoyés dans une demande d'accès depuis l'app Web apparaissent désormais automatiquement pour l'expéditeur du message dans le clavardage correspondant de Slack ou Microsoft Teams. Cela réduit la confusion pour l'expéditeur du message autour des messages associés à une requête.

Modifications apportées au Rapport sur les requêtes d'accès antérieures (conditions)

La colonne Objet de la requête a été supprimée du rapport sur les requêtes d'accès antérieures (conditions).

• Les administrateurs auxquels les rôles d'administrateur des applications et des requêtes d'accès ont été récemment attribués ne pouvaient pas voir l'onglet Requêtes d'accès sur la page de l'instance de l'application. (OKTA-1020342)

• Les e-mails de révision en attente étaient composés pour tous les réviseurs, qu'ils aient ou non des révisions en attente. Ce problème entraînait l'envoi d'e-mails ne contenant aucun élément de révision. (OKTA-1020491)

• Il arrivait parfois que certaines campagnes ne soient pas lancées. (OKTA-1020732)

• Après avoir été attribués à Salesforce et s'être vu attribuer un ensemble de droits via un workflow dans Okta, certains utilisateurs n'ont pas été transférés ni synchronisés, et n'étaient donc pas visibles dans Salesforce. (OKTA-1021934)

• Le champ de description des droits n'a pas été importé dans Okta via SCIM 2.0. (OKTA-935291)

Suppression de l'approbation automatique des délégués pour les requêtes d'accès

Les délégués ne peuvent plus approuver les requêtes faites à leur nom, ce qui garantit une séparation correcte des tâches.

• Les notifications par e-mail de l'Access Certification concernant une modification de la date de fin d'une campagne affichaient par erreur la mention En attente de révision dans l'objet. (OKTA-1007068)

• L'état de l'utilisateur dans Okta Identity Governance n'était pas correctement renseigné dans une campagne Certifications d'accès pour les utilisateurs désactivés. (OKTA-991451)

• Les administrateurs auxquels les rôles d'administrateur des applications et des requêtes d'accès ont été récemment attribués ne pouvaient pas voir l'onglet Demandes d'accès sur la page de l'instance de l'application. (OKTA-1020342)

Version 2025.09.0

Fonctionnalités et améliorations

Modifications de l'interface utilisateur d'Access Certification

L'onglet Campagnes de la page Access Certification a été renommé Campagnes de certification. Le bouton Créer une campagne a été déplacé dans l'onglet Campagnes de certification.

Il s'agit d'une version en accès anticipé. Consultez Activer les fonctionnalités en libre-service.

Modifications des limites d'Access Certification

Les limites suivantes ont été mises à jour pour les campagnes de ressources :

• Le nombre maximum de ressources incluses dans une campagne est passé de 50 à 250.

• Le nombre maximum d'applications qui examinent les droits est passé de 10 à 20.

Pour les campagnes utilisateur, le nombre maximum de ressources exclues est passé de 50 à 100. Vous pouvez exclure jusqu'à 100 apps ou groupes, ou une combinaison des deux.

Modifications de l'interface utilisateur des campagnes de ressources

Lorsque vous sélectionnez des applications à inclure dans une campagne de ressources, les résultats de recherche pour les applications disposant de droits d'accès sont désormais suivis de la mention Droits entre parenthèses.

Délégués de la Governance

Vous pouvez définir des délégués pour les utilisateurs ou autoriser les utilisateurs à désigner un autre utilisateur comme délégué qui effectuera des tâches de gouvernance à leur place. Les tâches Governance comprennent les éléments de révision des campagnes de certification d'accès et les approbations des demandes d'accès, les questions et d'autres tâches. Une fois qu'un délégué est spécifié, toutes les tâches Governance futures (approbations des demandes d'accès et révisions des certifications accès) sont affectées au délégué au lieu de l'approbateur ou du réviseur d'origine. Cela permet de s'assurer que les processus Governance ne se bloquent pas lorsque les approbateurs sont indisponibles ou que les tâches doivent être redirigées vers d'autres parties prenantes pendant une longue période. Cela permet également de réduire le temps passé à réaffecter manuellement les requêtes et les révisions. Consultez Délégués dans Governance.

Le rôle Propriétaire de groupe est désormais appelé Propriétaire de ressource

Le rôle de Propriétaire de groupe a été renommé Propriétaire de la ressource.

Amélioration de l'expérience utilisateur pour les demandes d'accès

La page de détails de la requête d'accès et les notifications par e-mail ont été améliorées pour une meilleure visibilité sur les tâches des approbateurs et les réponses des demandeurs. Si vous avez intégré Slack à Demandes d'accès, des modifications similaires ont été apportées au message de demande d'accès que les approbateurs reçoivent. En outre, le responsable de requêtes a été supprimé des notifications Slack et par e-mail, tandis que le nom et l'adresse de l'expéditeur de la notification par e-mail ont été modifiés. Le nouveau nom de l'expéditeur est Okta Demandes d'accès et l'adresse e-mail est noreply@at.okta.com. Consulter Conception repensée de l'interface d'approbation d'Access Requests.

Examen des accès de sécurité

Les Examen des accès de sécurité constituent un nouveau type de contrôle d'accès utilisateur axé sur la sécurité, qui peut être déclenché automatiquement par des événements. Ces contrôles offrent une vue d'ensemble des accès d'un utilisateur, ainsi que des informations contextuelles sur son historique d'accès, notamment un résumé généré par l'IA, ce qui vous permet d'enquêter et de prendre immédiatement des mesures de correction, telles que la révocation des droits d'accès. Consultez la section Examen des accès de sécurité .

Il arrivait parfois que des droits attribués par stratégie soient inclus par erreur dans les campagnes des utilisateurs, même si la permission des ressources de la campagne était configurée pour n'inclure que les droits attribués individuellement. (OKTA-1001535)

Les résultats de la recherche étaient effacés lorsque les utilisateurs actualisaient le catalogue de ressources dans l'End-User Dashboard après avoir recherché un élément. (OKTA-1006498)

Lorsqu'un réviseur tentait de récupérer une campagne qui comprenait un mélange de campagnes activées et désactivées par l'auto-évaluation, une erreur se produisait et aucune campagne ne s'affichait. (OKTA-1012083)

Le nombre d'éléments de révision en attente affiché dans les notifications par e-mail aux réviseurs était incorrect. (OKTA-962525)

Certains réviseurs ne recevaient pas de notification par e-mail lorsque la campagne était lancée et que les révisions leur étaient attribuées. (OKTA-994146)

Améliorations de l'interface utilisateur pour les vignettes du catalogue de ressources

Les vignettes du catalogue de ressources pour les types de requêtes et les collections de ressources incluent désormais des descriptions. Concernant les vignettes comportant des descriptions détaillées, il suffit de positionner le pointeur de la souris sur le texte pour afficher la description intégrale.

Dans certains cas, les administrateurs pouvaient affecter à eux-mêmes le rôle d'approbateurs pour leurs propres demandes d'accès. (OKTA-793993)

Délégués de la Governance

Les super administrateurs et les utilisateurs peuvent affecter un autre utilisateur en tant que délégué à des tâches Governance à leur place. Les tâches Governance comprennent les éléments de révision des campagnes de certification d'accès et les approbations des demandes d'accès, les questions et d'autres tâches. Une fois qu'un délégué est spécifié, toutes les tâches Governance futures (approbations des demandes d'accès et révisions des certifications accès) sont affectées au délégué au lieu de l'approbateur ou du réviseur d'origine. Cela permet de s'assurer que les processus Governance ne se bloquent pas lorsque les approbateurs sont indisponibles ou que les tâches doivent être redirigées vers d'autres parties prenantes pendant une longue période. Cela permet également de réduire le temps passé à réaffecter manuellement les requêtes et les révisions. Consulter Délégués dans Governance.

Il s'agit d'une version en accès anticipé. Consultez Activer les fonctionnalités en libre-service.

Expérience de requête unifiée

Utilisez cette fonctionnalité pour créer une expérience cohérente et unifiée pour le lancement des requêtes dans le tableau de bord de l'utilisateur final, Slack et Microsoft Teams, que la requête soit gérée par des conditions ou par type de requête. Cela vous offre la possibilité d'utiliser l'une ou l'autre de ces méthodes, ou les deux conjointement, pour gérer l'accès aux ressources sans modifier l'expérience de l'utilisateur.

• Les types de requête apparaissent désormais sous forme de vignettes dans le catalogue de ressources du Okta End-User Dashboard, en même temps que d'autres ressources. Vos paramètres d'audience d'un type de requête continuent de déterminer quels utilisateurs peuvent voir le type de requête sur leur tableau de bord et demander un accès.

• Les utilisateurs de Teams peuvent désormais demander l'accès à des ressources régies par des conditions de requête d'accès, et l'expérience de requête pour les ressources gérées par des types de requête a également été mise à jour.

De plus, dans l'app Okta Access Requests, la page Requêtes d'accès a été renommée Catalogue de ressources. En cliquant dessus, les demandeurs sont redirigés vers le catalogue de ressources sur le tableau de bord de l'utilisateur final. La section Types de requêtes de l'app Web est visible uniquement par les administrateurs et les membres de l'équipe qui possèdent le type de requête. Consulter Créer des requêtes.

Il s'agit d'une version en accès anticipé. Consultez Activer les fonctionnalités en libre-service.

Exporter les rapports Okta Identity Governance au format PDF

Vous pouvez désormais exporter les rapports Okta Identity Governance au format PDF. Lors de l'exportation, vous pouvez également sélectionner des colonnes spécifiques à inclure dans le rapport.

Il s'agit d'une version en accès anticipé. Consultez Activer les fonctionnalités en libre-service.

Les modifications concernant les personnes attribuées aux types de requêtes sont accessibles dans les environnements de production

Lorsqu'une tâche ou une question d'un type de requête est affectée à un groupe pour être exécutée, l'utilisateur qui a soumis la requête initiale est alors automatiquement exclu de l'affectation, même s'il est membre de ce groupe. Cela empêche le demandeur d'effectuer une action sur sa propre requête dans une capacité de gestion des requêtes.

Okta attribuait automatiquement le dernier utilisateur à la réalisation d'une tâche dans la requête en tant que responsable de requêtes. (OKTA-959802)

Pour les campagnes d'Access Certification, la case à cocher Numéro d'employé est désormais affichée dans la section Informations contextuelles de la page Paramètres. Consulter Contexte de révision personnalisable.

Parfois, les réviseurs recevaient des erreurs lorsqu'ils approuvaient ou révoquaient l'accès d'un utilisateur à une ressource. (OKTA-917776)

L'app Okta Access Requests Resource Catalog a été renommée

L'app Okta Access Requests Resource Catalog a été renommée Okta Identity Governance. Cette application est automatiquement attribuée à tous les utilisateurs et ne nécessite aucune gestion. Les utilisateurs verront le nouveau nom lorsqu'ils cliquent sur Requête d'accès dans le tableau de bord de l'utilisateur final. Cette modification ne touche pas les applications existantes Okta Access Certification Reviews et Okta Access Requests utilisées par les réviseurs de campagnes et les approbateurs de requêtes.

Les modifications apportées aux requêtes d'accès gérées par type de requête sont accessibles dans les environnement de production

Si une demande d'accès est gérée par type de requête, vous ne pouvez pas l'utiliser pour affecter des groupes qui accordent des rôles administrateur à Okta. Vous ne pouvez pas ajouter les groupes qui accordent des rôles administrateur à Okta à une liste. Okta invalide également les types de requêtes qui touchent ces groupes lorsque vous créez ou modifiez le type de requête. Les utilisateurs obtiennent une erreur s'ils demandent un groupe qui accorde le rôle administrateur Okta. Consultez Requêtes d'accès pour les rôles administrateur.

Les modifications apportées aux applications Okta sont accessibles dans les environnements d'aperçu

Vous ne pouvez plus afficher ou attribuer les applications suivantes aux utilisateurs :

• Okta Access Certifications

• Administrateur Okta Access Requests

• Okta Entitlement Management

En outre, les stratégies d'authentification pour ces applications seront par défaut la stratégie d'authentification existante que vous utilisez pour Okta Admin Console.

Certains événements de requête d'accès n'étaient pas enregistrés dans le System Log. (OKTA-955700)

Les modifications apportées aux requêtes d'accès gérées par type de requête sont maintenant accessibles dans les environnement d'aperçu

Si une demande d'accès est gérée par type de requête, vous ne pouvez pas l'utiliser pour affecter des groupes qui accordent des rôles administrateur à Okta. Vous ne pouvez pas ajouter les groupes qui accordent des rôles administrateur à Okta à une liste. Okta invalide également les types de requêtes qui touchent ces groupes lorsque vous créez ou modifiez le type de requête. Les utilisateurs obtiennent une erreur s'ils demandent un groupe qui accorde le rôle administrateur Okta. Consultez Requêtes d'accès pour les rôles administrateur.

Les modifications concernant les personnes attribuées aux types de requêtes sont maintenant accessibles dans les environnements d'aperçu

Lorsqu'une tâche ou une question d'un type de requête est affectée à un groupe pour être exécutée, l'utilisateur qui a soumis la requête initiale est alors automatiquement exclu de l'affectation, même s'il est membre de ce groupe. Cela empêche le demandeur d'effectuer une action sur sa propre requête dans une capacité de gestion des requêtes.