Patriot supports integration with Microsoft logins, for operators and ICA users.
Integration with Microsoft Windows Active Directory (here after referred to as AD) allows an automatic sign on to the Patriot client program using the operators windows user credentials. Program access and rights (see below) can be controlled within AD, thus making it easier to manage security access across an organisation.
Security Groups are setup in AD for the various Patriot access levels required. These are then assigned to each operator's user in AD. Thus control of access is performed within AD and not within Patriot. The specific rights that each group has is still configured within Patriot itself.
A system setting dictates if Single Sign On is enabled or not. Patriot will only support its own internal security model or single sign on, not both at the same time. So once single sign on is enabled, internal Patriot operators will no longer have access to the program.
Integration with Microsoft Azure Active Directory (here after referred to as AAD) allows ICA users to sign in automatically using their Microsoft Work or School account. Mixed mode authentication is supported for ICA, allowing selected users to sign in using AAD while still supporting traditional username/password authentication for external users or customers.
Each user is assigned an application role (see below), which controls which ICA features they can control. Access control for ICA users is therefore also managed through Azure. The specific rights allowed for each role are still configured from within Patriot.
Note: AAD can be optionally linked together with your organisations existing AD system, giving users one consistent login for both the client and ICA. However this is not required, and Single Sign On can be enabled for each system separately.
One way to setup the security groups is to set them up in Patriot first. Note that the name of the Security Group is important and will be used to setup groups in AD also. As group names are unique in AD, you must use names that are not already used. It's suggested you prefix the name Patriot in front of all group names to ensure uniqueness. Setup the groups, and also configure the access rights for each group as required. You may use the existing Patriot security groups, or create new ones, as long as the name is not already in use in AD. Instructions for setting up Patriot groups are here.
Next create an Organisational Unit in AD to contain all the Patriot Security groups you require. This organisational unit should be reserved for Patriot use only, and must be named 'Patriot'.
Then create groups in this organisational unit for each Patriot security group. The name of the group in Patriot must match the name of the AD group exactly. If an AD group is used which doesn't exist in Patriot, it will be created in Patriot with no access rights.
Another approach is to set-up all the security groups you need in AD within the ‘Patriot’ Organisational Unit first and make a patriot administrator a member of all these groups. You will need to have at least one matching administrator group already set-up in Patriot with full rights (to allow full access to the administrator when they login for the first time). When the AD Patriot administrator subsequently logs into patriot all additional Patriot groups already set-up in AD will be automatically created within Patriot but by default will have no permissions – the patriot administrator can then proceed to grant permissions to the groups as desired.
Next, assign one of the groups within the Patriot organisational unit to each person who requires access rights to the Patriot client application.
Access to Patriot can easily be removed by ensuring the user is not assigned to any of these groups.
Ensure you have at least one Patriot administrator account setup in Patriot. Once single sign on is enabled, the only way to login to Patriot is using a correctly configured AD user, or a Patriot administrator account. Any existing non Patriot administrator operators will not be allowed access.
Login to Patriot using one of the existing standard Patriot operators. Then go into System -> System Settings -> System Wide Settings -> Security. Enable active directory single sign on.
When an operator starts the Patriot client, an attempt to auto login using single sign on will be performed. If the windows user is valid, the AD groups (within the Patriot organisational unit) assigned to this user will be synchronised with the Patriot security groups, then the operator will be given the appropriate access. If the auto login process fails, the standard Patriot login window will be displayed.
When an AD User successfully logs into Patriot, a Patriot Operator record will be automatically added to Patriot. This operators name, password, operator groups won't be able to be edited from within Patriot, as these details should be maintained within AD. Deleting this operator won't stop the operator from gaining access, this must also be performed from AD.
To display the Login window and allow the connection settings to be configured, a /NOSSO command line switch may be added to the Patriot client shortcut.
If you wish to remove a security group, delete the group from AD, not just from Patriot, otherwise the group will be recreated in Patriot the next time an AD user logs in with that group assigned.
You will require a Microsoft Azure subscription to enable ICA single sign on. If you are also using single sign on for logging into the Patriot client, then it is recommended to use Azure AD Connect to link your standard Active Directory together with your Azure Active Directory system.
Open the Azure management portal at https://manage.windowsazure.com/ and select Active Directory.
Select the directory that you want to use for signing in.
Under Applications, select to add a new application, then select 'Add an application my organisation is developing'.
Enter a valid name and select Web Application/Web API as the application type.
Enter your ICA website server address as the sign-in URL. If you have multiple ICA addresses, enter the main one as additional addresses can be added later.
For your App ID URI, enter your Azure Directory tenant name, followed by PatriotICA. For example, www.monitoringstation.com/PatriotICA
In your new application, select the Configure tab.
Make a note of the Client ID (e.g. 4c44d827-b656-4fa1-ad19-369a72f8f90b)
Make sure that 'User Assignment is required to access the app' is turned on.
If your ICA web server has multiple addresses, you can add the extra addresses under the 'Reply URL' section.
Each user in Azure will be assigned a role, which controls the features and options they have access to within ICA. Examples of roles are: 'Residential User', 'Dealer/Bureau', 'Monitoring Staff'
Role creation within Azure requires editing the application manifest file. It is not possible to edit the available roles through the Azure web interface.
From the application settings in Azure management portal, select Manage Manifest and download manifest file.
Open the manifest file in a text editor and locate the 'appRoles' section.
For each role that you wish to add, paste in the following text inside the [] of the appRoles line:
{
"allowedMemberTypes": [
"User"
],
"description": "Residential Users can view basic information about their sites, but not make changes.",
"displayName": "Residential User",
"id": "1fa615ac-811b-498d-91cd-ea50654543ec",
"isEnabled": true,
"value": "ICA_ResidentialUser"
},
Update the values as follows:
description: The friendly description of the role.
displayName: The name shown when assigning a user within the Azure portal.
id: A unique id for the role. You can use a website such as http://www.guidgen.com/ to create new ids.
value: The name of the ICA group as it will be displayed within Patriot. This value cannot contain spaces, but any underscores will be replaced with spaces when creating groups.
Repeat this for each role that you wish to create.
Save the manifest file, then return to the Azure portal and select 'Upload Manifest' from the Manage Manifest option.
See ICA Installation for general information on setting up ICA.
Edit the ICA web.config file and add the following keys:
SSOStationID:
<add key="SSOStationID" value="[Station ID]"/>
Replace "Station ID" with the site ID that should be used, e.g. '1000'. This should match the other settings like 1000DBConn.
SSOEnabled:
<add key="SSOEnabled" value="[YES / NO]"/>
Set this to YES to enable SSO, or NO to disable.
SSOClientID:
<add key="SSOClientID" value="[Azure Application ID]"/>
Set this to the Client ID from the Azure application Configure page, noted above. E.g. 4c44d827-b656-4fa1-ad19-369a72f8f90b
SSOTenant:
<add key="SSOTenant" value="[Azure Tenant Name]" />
Set this to your Azure tenant name, e.g. monitoringstation.com
From within the Azure Management portal, open the Patriot ICA application and select the users tab.
Select the user that requires access, and click 'Assign'. Select the role that the user should be assigned to, and click OK.
The user can now sign in to ICA using the 'Sign in with Microsoft' button on the ICA login page.
When the user signs in, a Patriot user will automatically be created for them.
Once the user is created, you can assign them to the required Patriot sites in the normal way. See the Users Tab for more information.
Patriot will also automatically create new ICA user groups to match the role assigned to the user. By default, this group will have minimal access rights.
See ICA User Setup for more information on customising the rights and features that the group will have access to.