Authentication
  • 17 Jan 2024
  • 1 Minute to read
  • Dark
    Light

Authentication

  • Dark
    Light

Article Summary

General

Authentication is the process of identifying a user that connects to a Service; whoever connects to a Mail & Deploy service needs to provide evidence that he is a Mail & Deploy User. Mail & Deploy supports numerous authentication methods; however not all Services support all authentication methods.

Windows Authentication

When using Windows Authentication the user sends his windows account to the Mail & Deploy Service to which he wants to connect to. Mail & Deploy will then query its user database to find a User whose Has Windows Account property is enabled and whose Windows Account property is equal to the windows account that the user is trying to connect with. If such a user is found, the connecting user is authenticated as that found user.

Custom Authentication

When using Custom Authentication the user sends his custom username and password in a  Basic HTTP Access Authentication Header. Mail & Deploy will then query its user database to find a User whose Has Custom Credentials property is set to true, whose Custom Username property is equal to the username that has been sent in the authorization header and whose Custom Password is equal to the password that has been sent in the authorization header. If such a user is found, the connecting user is authenticated as that found user.

Azure AD Authentication

When using Azure AD Authentication the user is redirected to Microsoft's Azure AD authentication page and logs on with his Microsoft account (or, if the Microsoft account is already signed in, it will automatically be passed on to Mail & Deploy invoking Single Sign On). If that user has been synchronized to Mail & Deploy with an Azure AD User Directory that synchronized Mail & Deploy User is authenticated.

Access Key Authentication

When using Access Key Authentication the user has essentially two options:

  • The user can provide the access key in a query string parameter named AccessKey.
  • The user can provide the access key in an HTTP header named MailAndDeployAccessKey.
WARNING

Whoever has the access key for a Mail & Deploy user can have full API access; you should consider access keys to be as security critical as username/password combinations are and should only give them to people and organisations you want to give access to the API of Mail & Deploy.


Was this article helpful?

What's Next