Single Sign On (SSO) with Azure AD (AAD)
Simplify the login flow for your users, while increasing security and control by implementing Single Sign On (SSO) with Azure AD (AAD). All you need is an Azure AD subscription...which sounds a bit complicated...but you've probably already got one as it comes bundled in with Office 365 (or can be setup separately).
Before you begin
Before we start setting up integrated logins, you will need:
- A Prospect Account. If your organisation has a Prospect subscription but you don't have a login, contact your administrator. If your organisation hasn't signed up yet, then sign up for free at www.prospectsoft.com/register.
- An Azure AD Account. If you use Office 365 then you already have an Azure AD Account. If you don't use Office 365, you can create an Azure AD Tenant by visiting https://account.windowsazure.com/organization.
To start using integrated logins on a personal level you don't need any more than an account on each, but to set up full integration for all your users, you'll also need to be an administrator for both products.
What is Single Sign On (SSO)?
Single Sign On allows you to log into multiple applications using a single sign on account. Essentially, in the case of Azure AD SSO, we trust Microsoft to validate your identity on our behalf. Through strong encryption and tight security standards, we can be sure that Microsoft logged you in, and on that basis we log you into our application without asking for another password. The benefits are of course less clicks and less typing of passwords, but with less passwords to manage, users are more likely to use stronger passwords and change them more regularly. And, as an IT administrator you have greater control in being able to centrally block users from applications, centrally enforce security standards and best practice (e.g. password length or even two factor authentication), etc. For more information please visit docs.microsoft.com/en-us/azure/active-directory/.
Personal Single Sign On
Without setting up any integration or using administrative privilege, any user can start using SSO. Just so long as your Prospect user ID, i.e. your email address, matches the primary email address in Office 365, then you can use your Office 365 credentials to log into Prospect.
Simply visit the Prospect Login page and click 'Sign in using Office 365'. You will be redirected to the Microsoft login. If you are already logged into Office 365 you will be bounced straight back to Prospect. If your login details match, then you will be logged in automatically. If not, it will tell you the email address supplied by Microsoft and you will need your administrator to update your user record in Prospect to match before being able to use Single Sign On.
Setting up Account-Wide Single Sign On
For the best experience, an Administrator should link your Prospect subscription to your Office 365/Azure tenant. This requires administrator privilege on both solutions but ultimately allows you to enforce SSO for a whole domain and ensure that all users must use SSO to access your Prospect data.
This setup is performed via the Admin Portal at admin.prospect365.com.
- Login to the Admin Portal using an account with the administrator role (typically the user that you signed up with).
- Navigate via the menu to Setup/Your Domains.
- Here you can add the domains that your users use for their Azure/Office 365 login - typically this will be just one domain (e.g. yourcompany.com) but in a more complex organisation this could be multiple domains. In which case you will add them one at a time.
- The wizard will take you through the necessary steps to validate ownership of the domain and to authorise Prospect to use your Azure/Office 365 login information. More help on these steps are provided below.
- Once the domain setup is complete, and assuming you have accepted the default to enforce SSO, the next time any of your users login, they will either click the 'Login with Office 365' logo, or, if they enter a login email address that uses the given domain, they will be automatically redirected. e.g. if you add yourcompany.com to the domains table, and a user tries to login using a user id of email@example.com, then SSO will be enforced and the user will be redirected to the Microsoft login page.
Validating ownership of your domain
This is the trickiest step, but a vital one. It is essential that we validate domain ownership, so that someone else can't start setting up SSO for your domain and that you cannot setup SSO for someone else's. The most reliable way to determine domain ownership is for you to add some unique text to your DNS record using a standard TXT entry. Most DNS console's make this fairly easy but if you don't know how to do this then you will need to contact your DNS provider.
The necessary TXT entry is provided during the verification process.
To verify ownership of the domain click the copy to clipboard button to copy the value display in the box.
This value then needs to be added as a TXT record against your domain name in your domains DNS records.
The method on doing this differs per domain provider. The links below provide help files for some of the common providers:
Once the DNS TXT record has been added, the user can click the "Verify" button to verify ownership of the domain.
On the next page, select the SSO provider (at the time of writing, Office 365/Azure is the only option, but eventually others will become available).
By default, "Enforce Single Sign-in" is checked. This is the recommended setting. Without this, users will still be able to login either with SSO, or with their email and passwords. This reduces security and centralised control in that you cannot use your Azure settings to control password strength, disable users etc. Only uncheck this option if you want users to be able to use mixed logins.
The final step is to Authorise Prospect to access the information provided to us by Azure:
Having completed this final step, you are all almost ready to go.
Don't forget, you can go back to the beginning and add additional domains if some of your users login with different domains.
Matching User ID's
Finally, SSO relies upon being able to match an Azure identity to a ProspectSoft identity. In order for this to work, the email addresses in the Prospect user accounts need to exactly match the primary email address in Azure. If necessary, you can update a user's email addresses in the Admin Portal.