What it's about

XCALLY gives the possibility to use Modern Authentication for Email Accounts using Office365 as provider. 

Modern authentication is an umbrella term for a combination of authentication and authorization methods between a client and a server. It includes:

• • Authentication methods: Multi-factor authentication (MFA); smart card authentication; client certificate-based authentication
  • Authorization methods: Microsoft's implementation of Open Authorization (OAuth)
  • Conditional access policies: Mobile Application Management (MAM) and Azure Active Directory (Azure AD) Conditional Access

Very simplistic we can say, that with modern authentication, the client is talking to the service and getting redirected to Azure AD for authentication with the username and password or other methods like MFA.

How to set up

To activate the Modern Authentication for a new Email Account on XCALLY using Office365 as provider, you need to: 

A. Register an application in the Azure Portal, so the Microsoft identity platform can provide authentication and authorization services for your application and its users.

B. Configure a new Cloud Provider on XCALLY by choosing Microsoft Azure as a service and Outlook365 as the type.

C. Associate the Cloud Provider with the email accounts on XCALLY. 

Azure AD application registration 

Registering your application establishes a trust relationship between your app and an application in the Azure Portal, the Microsoft identity platform . The trust is unidirectional: your app trusts the Microsoft identity platform, and not the other way around.can provide authentication and authorization services for your application and its users.

App Registration

Follow these steps to create the app registration:

1. Sign in to the Azure portal.

2. If you have access to multiple tenants, use the Directories + subscriptions filter  in the top menu to switch to the tenant in which you want to register the application.

3. Search for and select Azure Active Directory (AD).

4. Under Manage, select App registrations > New registration.

5. Enter a display Name for your application. Users of your application might see the display name when they use the app, for example during sign-in. You can change the display name at any time and multiple app registrations can share the same name. The app registration's automatically generated Application (client) ID, not its display name, uniquely identifies your app within the identity platform.

6. Specify who can use the application, sometimes called its sign-in audience.

   Supported account types	Description
   Accounts in this organizational directory only	Select this option if you're building an application for use only by users (or guests) in your tenant. Often called a line-of-business (LOB) application, this app is a single-tenant application in the Microsoft identity platform.
   Accounts in any organizational directory	Select this option if you want users in any Azure Active Directory (Azure AD) tenant to be able to use your application. This option is appropriate if, for example, you're building a software-as-a-service (SaaS) application that you intend to provide to multiple organizations. This type of app is known as a multitenant application in the Microsoft identity platform.
   Accounts in any organizational directory and personal Microsoft accounts	Select this option to target the widest set of customers. By selecting this option, you're registering a multitenant application that can also support users who have personal Microsoft accounts.

7. Don't enter anything for Redirect URI (optional). You'll configure a redirect URI in the next section.

8. Select Register to complete the initial app registration.

   
   

   

When registration finishes, the Azure portal Portal displays the app registration's Overview pane. You see the Application (client) ID. Also called the client ID, this value uniquely identifies your application in the Microsoft identity platform.

Your application's code, or more typically an authentication library used in your application, also uses the client ID. The ID is used as part of validating the security tokens it receives from the identity platform.

Image Removed

The Application (client) ID and Directory (tenant) ID values will be needed during the Cloud Provider Configuration phase. 

Image Added

Authentication- Redirect URI

The authorization server sends the code or token to the redirect URI, so it's important you register the correct location as part of the app registration process.

A Redirect URI, or reply URL, is the location where the Microsoft identity platform redirects a user's client and sends security tokens after authentication.

Follow these steps to add a Redirect URI:

1. In the Azure Portal, under Manage, select Authentication (from the left Menu)
2. Under Platform configuration, select Add a platform
3. Under Configure platforms, select Web Applications 
4. Enter the following Redirect URI:

http://motionserverhost/api/cloudProviders/oauth2/microsoft/callback

(Replace "motionserverhost" with your motion server host value)

The Redirect URI will be needed during the Cloud Provider Configuration phase. 

Image Added

Credentials- Client Secret

Credentials allow your application to authenticate as itself, requiring no interaction from a user at runtime.

Image Added

Credentials are used by confidential client applications (apps that run on servers) that access a web API. 

Sometimes called an application password, a client secret is a string value your app can use in place of a certificate to identity itself.

Client secrets are considered less secure than certificate credentials. Application developers sometimes use client secrets during local app development because of their ease of use. However, you should use certificate credentials for any application you have running in production.

1. In the Azure portal, in App registrations, select your application.
2. Select Certificates & secrets > Client secrets > New client secret.
3. Add a description for your client secret.
4. Select an expiration for the secret or specify a custom lifetime.
   • Client secret lifetime is limited to two years (24 months) or less. You can't specify a custom lifetime longer than 24 months.
   • Microsoft recommends that you set an expiration value of less than 12 months.
5. Select Add.
6. Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page.