The Agilicus AnyX platform uses external Identity Providers (typically Microsoft Azure, Google Workplace) rather than creating ‘parallel’ identities for users to remember. This provides increased security and reduced risk for all three constituents (Agilicus Customer, Customer Partners, and, partner end-users.

This approach to Identity is called Federated Authentication. In this model, each company manages their own users identity. This includes identity attestation (this person works for me). This is a normal part of their human resources workflow (new employee, create entry in Active Directory of Google Workplace), and, includes offboarding (remove user from Identity Directory). The Agilicus AnyX Customer is able to select individual users (identities) from each of their Partner’s and then perform a shared Authentication to prove the identity. This Authentication is performed against the existing Single-Sign-On system: the end-user sees the same web interface, same username, same password.

A federated Chain of Trust is built: Customer ‘trusts’ Microsoft Azure to attest to a user’s Identity. Partner-1 manages the Users. Customer manages which Identities are allowed to flow across the interface (e.g. it is not allowing ALL users, only specific ones), and, what actions they can do (Authorisation).

The Customer then allows access to specific resources, for those users, according to the desired Authorisation.

Example

Assume there are 3 companies.

• City of EGov. They operate the Agilicus AnyX platform.
• MSPco. They are a managed-service provider who performs desktop assistance on behalf of many customers, including City of EGov.
• HVACco. They perform remtoe-maintenance on air-conditioning, building management systems.

The City of EGov uses Microsoft Office 365. As a consequence their direct employees can authenticate (sign-in) to systems with an identity that looks like ‘user@egov.city’).

MSPco uses Azure Active Directory in their own tenant. As a consequence their direct employees can authenticate (sign-in) to systems with an identity that looks like ‘user@msp.co’.

HVACco uses Google Workplace. Their direct employees authenticate (sign-in) to systems with an identity that looks like ‘first.last@hv.ac’.

Assume that the City of EGov has two resources (netwok addressable systems). One is a remote backup system, it has a web-interface which allows two main functions: reporting (e.g. checking that each backup has been performed), and, an administrative function that allows adding new enpoints. The second resource is a Building Management System, supporting checking of alarms, door locks, temperatures, etc.

Assume these people have these roles:

Identity	Company	Backup-Report	Backup-Admin	BMS
jane@egov.city	City of Egov	✓	✓	✓
joe@egov.city	City of Egov	✓
sally@msp.co	MSPco	✓	✓
fred@msp.co	MSPco	✓
lisa@hvac.ac	HVACco			✓

Here we can see that the ‘identity’ (left column) is entirely owned by the company the user works for.

The authentication (proving that someone is who they say they are) is performed by a combination of the company they work with and the City of Egov. The City of Egov has not linked e.g. ‘edward@msp.co’ or ‘fred@gmail.com’, so they cannot authenticate.

The City of Egov, alone, owns authorisation (e.g. sally@msp.co can both see backup reports and also add endpoints but cannot use the building management).

No shared accounts are present (e.g. there is not a mspco@egov.city account). This means there is no concern about someone leaving their organisation (e.g. sally leaves MSPco).

In this example, each user, on their own device, is challenged with an initial Sign-In screen similar to at right. When sally@msp.co selects ‘Sign-In with Microsoft’, she is presented with HER normal Azure sign-in. E.g. Sally would see next her branded screen (something like below). This would in turn force her companies policies to apply (multi-factor, saved password, etc).

jane@egov.city would also select ‘sign-in with Azure’. She might see the below screen, assuming her organisation has not branded the Azure sign-in experience.

In both cases, the user has a single-sign-in experience.

Consent Flow

Depending on the configuration of the Azure Active Directory (or ADFS), the first user of an organisation signing-in might be presented with a ‘Approval required’ message similar to below.

As an Azure administrator, you can control which applications triggers a ‘consent’ flow, and, which users can answer it. For more information see “Configure how users consent to applications” in the Azure Product Documentation.

It is important to read the permissions requested. The most basic level (sign-in and read-profile) is granting permission to:

1. The requesting system (Agilicus AnyX) can allow shared authentication, can trust a sign-in
2. The requesting system (Agilicus AnyX) can see the user’s First Name, Last Name, Email Address

No permission is granted to read Active Directory, access Azure or Office 365 resources, etc. This permission is only granted on a valid user signing in (e.g. no permission is granted on other users, just the one that caused this flow).

The chain of trust is created from the Agilicus Multi-Tenant Application Registration (which is in the Azure catalog as a verified publisher). Granting the permission allows the City of Egov from the example above to authorisation their own resources using the MSP.co Azure Active Directory.

No permission exists absent a currently signing-in user (e.g. the Agilicus AnyX system cannot independently read the user email, nor can it read a different user email).

The consent can either be granted on the first use (as in the example above), or via the Azure console pro-actively. If using the Azure console you can grant this consent on smaller groups of users or groups.

Benefits

The Federated Identity with shared Authentication provides a set of key security and usability benefits to each of the three main constituents.

By providing a consistent user-experience on sign-in, it is easier to train users to phishing attempts. This in turn reduces the risk to each organisation.

By providing a single username/password across all systems, there is reduced risk of password re-use and sharing, leading to lower risk of breach.

By allowing the Agilicus AnyX customer to enforce authentication policies such as multi-factor, it can increase their compliance and lower their risk. This in turn can reduce the cost of Errors & Omissions Cyber Security Insurance.

For the end-user, a single-sign-on experience reduces sign-in-fatigure, simplifying their task flow.

Using a web-based authentication allows disparate directory systems: there is no requirement that the Partner devices are attached to the directory of the Customer.

Absent a system like this, many Customer would create a shared account in a VPN (e.g. mspco@egov.city). This is highly risky, the password is known by multiple individuals and difficult to rotate, and, impossible to provide multi-factor for (since you would need to share a device amongst the users). The Agilicus AnyX obviates this need.

Each company (Partner, Customer) can individual control their users, manage their own HR workflow in a natural fashion, without concerning themselves of their business partners.

There is no need for the Partner companies to install a VPN per Customer, since the entire system is web-based.

To Agilicus AnyX Customer

• Increased compliance. Multifactor for all partners
• Individual audit, per user, no shared accounts. Each action is attributable to a single individual, and individually controllable

To Agilicus AnyX Customer Partner

• simplified HR workflow, no need to notify customers
• simplified IT on desktop, no VPN per customer
• Reduced financial risk (no breach attributable to your user not obeying best practices with multi-factor or shared accounts)
• Reduced risk of spear-phishing since all users see same login flow for all systems, internal or external

To End User

• reduced sign-in fatigue
• reduced password memorisation load
• no concern about unlike sytems with unlike password rules