Lorsqu’un utilisateur se connecte avec Jamf Connect ou Self Service+, son mot de passe est entré dans un champ texte sécurisé et n’est jamais écrit sur un disque en dehors du trousseau macOS.
Lorsque Kerberos est utilisé, le mot de passe est utilisé avec l’appel d’API gss_aapl_initial_cred(), qui authentifie l’utilisateur et obtient un ticket d’octroi de tickets (Ticket Granting Ticket ou TGT). Lorsque vous changez de mot de passe, le même processus est appliqué avec l’appel d’API gss_aapl_change_password(). Ces deux appels d’API tirent parti de l’implémentation de Heimdal Kerberos par Apple.
Toutes les actions Kerberos sont effectuées avec les API d’Apple. Le mot de passe n’est jamais mis en cache avec un « kinit » ou d’autres outils de l’interface de ligne de commande (CLI) Kerberos.
Lorsqu’il est intégré à Okta en tant que fournisseur d’identité (IdP), Jamf Connect et Self Service+ utilisent l’API d’authentification Okta. Pour plus d’informations relatives à l’API d’authentification Okta, consultez l’article Application types (Types d’applications) (okta Developer).
Lorsqu’il est intégré à d’autres fournisseurs d’identité (IdP), Jamf Connect et Self Service+ utilisent le protocole d’authentification OpenID Connect pour communiquer avec l’IdP.
Toutes les connexions réseau sont effectuées à l’aide de l’API de chargement d’URL macOS, URLSession. Toutes les communications sont sécurisées avec TLS pour s’assurer qu’elles ne sont pas corrompues.
Lorsque l’authentification directe est activée avec la fenêtre d’ouverture de session, les mots de passe des utilisateurs saisis dans la vue Web de la fenêtre d’ouverture de session sont temporairement écrits en mémoire et utilisés pour se connecter ou créer un compte local sur les ordinateurs. Lorsque Jamf Connect a terminé d’utiliser le mot de passe de l’utilisateur, la valeur est immédiatement remplacée par nil puis supprimée de la mémoire.
Pour plus d’informations relatives à OpenID Connect, consultez l’article What is OpenID Connect (Qu’est-ce qu’OpenID Connect ?).