The People Planner MyPlan Web Application
The MyPlan Web application supports Windows Authentication, Azure Authentication, and People Planner SSI authentication.
When using Windows Authentication, the user validation is the same as described for the People Planner Windows Application. However, if the Use UPN for Authentication setting is used, the validation fails. This is a known issue.
When using Azure authentication, MyPlan redirects to an Azure Login Page and receives the identity of the user from Azure. The email address that represents this identity is validated against the Email and AzureUPN fields of the User table in the People Planner Database. If a match is found in either of these, the user is logged in; otherwise, an error page is displayed.
To use People Planner SSI Authentication, an SSI token parameter must be passed as part of the URL. If no token is passed, and 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.
Maconomy calls the People Planner API Web service to request to get an SSI token for the current Maconomy user. When Maconomy later calls the embedded People Planner Web application, it then includes the SSI token in the URL.
The current Maconomy user is identified by the Maconomy UserRoleInformation.NetworkUserName and UserRoleInformation.NetworkDomainName in the Maconomy database.
The request to get an SSI token is encrypted, and People Planner must first be able to decrypt it to see which Maconomy user the request is for. If this is successful, the People Planner API returns a valid SSI token, with User name and Network domain name in it. If it is not successful, it returns an empty SSI token instead. The failure is logged in the People Planner API's own log file. Regardless of the success or failure, the returned SSI token is also encrypted.
When Maconomy launches MyPlan, the SSI token is appended to the MyPlan URL. MyPlan decrypts the token to get the user name and network domain name.
It then validates this against the user-table 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.