The People Planner Windows Application

The Windows Application starts by connecting to the Security Service specified in the Windows Application Configuration file (see the Deltek People Planner Technical Installation Guide for more information) using either Windows Authentication or Microsoft AzureAD authentication.

The Security Service uses the configuration file parameters ServerDataConnectionFile and ClientDataConnectionFile to identify the People Planner System (database). It is strongly recommended to use the same Data Connection file for the two parameters, and that the Data Connection file specify only one People Planner system (database). If you are using the recommended configuration, you can ignore the paragraphs that are shown in italics (below). If you need the People Planner Windows Application to be able to connect to different People Planner systems you should simply install a Security Service for each of those systems, in which case the Windows Application prompts you to choose which system before starting.

Based on the People Planner system (database) specified in the ServerDataConnectionFile setting, the Security Service returns a list of supported authentication methods. As of Release 3.8.6, the People Planner Windows Application supports Windows Authentication and Azure Authentication.

If more than one People Planner system is specified, the one named default is used, and if the default does not exist, the first is used.

If the Azure Authentication parameters in the People Planner database are set for the specified system, the returned list includes Azure Authentication (and the required information to reach the Azure AD). The Windows Application uses Azure if supported; otherwise, it uses Windows Authentication (which is always supported) for all subsequent communication with the Security Service.

Next, the Windows Application queries the Security Service for which People Planner system (database) to use. Normally, this is the same as the one used to get the supported authentication methods, and the Windows Application now connects using the preferred authentication method as described above.

If the ClientDataConnectionFile contains multiple connections, the Windows Application shows a Data Connection selection dialog before connecting.

Note: If the ClientDataConnectionFile contains multiple connections (multiple People Planner Databases) there is a risk that these systems are not configured to use the same authentication method, and hence not work as expected. For example:

• Security service uses Azure authentication, but the Windows Application uses Windows authentication:

  You are prompted for Azure credentials to communicate with the security service, but you will use Windows credentials (silently) to communicate with the People Planner Database.

• Security service uses Windows authentication, but the Windows Application uses Azure authentication:

  You are not prompted for authentication to communicate with the security service, but will be prompted for Azure credentials to communicate with the People Planner Database.

• Security service uses Azure authentication for "Tenant A," but the Windows Application uses Azure authentication for "Tenant B" (that is, two different People Planner Databases):

  You are prompted for Azure credentials for "Tenant A," and will try to use the same Azure credentials to communicate with "Tenant B."

This scenario will not work!

If Azure Authentication is not configured--meaning that the Azure Login URL, Server Resource Id, Tenant Domain, and People Planner Application Id are all specified--it uses Windows Authentication instead.

When using Windows Authentication, the People Planner Windows Application gets the identity of the current Windows user from the Windows Account or the UPN. The Use UPN for Authentication setting determines which is used.

The retrieved identity (user name and domain name) is validated against the User table of the People Planner database as follows:

• The user name is validated against the NetworkUserName property.
• If a match is found, the domain name is then validated against the NetworkDomainName and NetworkDomainAlias fields. If either of these is a match, the user is logged in. Otherwise, the login fails.

When using Azure authentication, the People Planner Application always displays an Azure Login Popup. Execution of the People Planner code is suspended until the user finishes interacting with the login popup.

The People Planner application receives the identity of the user from Azure. The email address that represents this identity is validated against the Email and AzureUPN fields in the User table in the People Planner Database. If a match is found in either of these, the user is logged in; otherwise, the login fails.

The People Planner Windows Application always reauthenticates every time it is restarted. However, no re-authentication is performed for the entire session during which the client remains open.