# Identity, Authorisation, Access: Microsoft Dynamics

- Link: https://www.agilicus.com/identity-authorisation-access-microsoft-dynamics/
- Published: 2020-10-18T20:22:07+00:00
- Author: Don Bowman

## OVERVIEW

You are deploying Microsoft Dynamics. You have a set of choices to consider, relating
to:

 1. How it will be accessed (direct Internet access, VPN, private network only)
 2. Which constituents of users will authenticate to it
 3. How users will authenticate to it
 4. The authorisation or roles of those users
 5. Related products (e.g. CRM Portals/PowerApps)
 6. Multi-Factor Authentication

In “Zero Trust for the Digitally Disconnected” we propose a technique that means
all applications are directly Internet connected (regardless of whether deployed
as SaaS, in a DMZ, in a private cloud, public cloud, hybrid cloud, etc.). This gives
maximal security and maximal ease of access.

## User Constituent Considerations

 * Full-time badged staff @mydomain only?
 * 2 or more related entities (e.g. @city, @region, @county, @library, @fire)
 * External contractors (e.g. @theatre)
 * Temps, contractors, other non full-time staff?
 * Channel Integration Framework (e.g. @ice-facility)

The broader the base of constituents you can reach securely and simply, the more
value you can extract from the Microsoft Dynamics deployment.

If the sole use case is Full-time badged staff @mydomain, the simplest is to deploy
using Azure Active Directory (if Microsoft Office 365 is already deployed), or to
deploy Microsoft Active Directory Federation Services (ADFS) so that it is Internet
facing. Both options allow creating “Authentication Clients” which allow external
applications to do a set of claims-based identity authentication. Possible standards
to use are [OpenID Connect](https://openid.net/connect/) and [SAML](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html).
Of these, OpenID Connect is a more modern Internet-style standard supporting both
Identity and Profile, where SAML supports Identity and custom attributes to emulate
Profile.

I encourage you to think of other constituents and stakeholders for which a federated
identity would be more appropriate. These can be identified by e.g. User@gmail, 
User@Library, other Identity providers, and securely Authorised, Simply.

A video demonstrating what the user experience would be is [available](https://www.youtube.com/watch?v=EzoaecCpX48).

## User Authentication

I would propose that you have zero users manually configured in Dynamics. All users
would be available through a Federated login, with separated Authorisation. 

![Zero Trust Identity Flow: Secure access begins with user identity verification,
followed by device trust assessment, and continuous authorization enforcement for
granular resource access. Agilicus ensures secure, compliant, and user-friendly 
zero trust network access.](https://www.agilicus.com/www/21c6e9a2-identity-flow.
svg)

Two modes of operation are available (called IdP-initiated, and SP-initiated). In
the first, there is a single page for your organisation called ‘MyApps’, you sign
into it, and it then has links to e.g. CRM which you follow, no additional login
is shown.

In the latter (SP-initiated), the user navigates to CRM, is not logged in, is redirected
to the login experience, and returns.

Both support single-sign-on, and are seamless. The SP-initiated is how more users
are used to operating (e.g. go to gmail, go to google calendar, go to google docs)
since they think of the application first.

## Initial Configuration

In “[Initial Setup — Active Directory](https://www.agilicus.com/active-directory-trusted-identity-provider/)”
I show the initial setup steps that are required once Azure Active Directory or 
Active Directory Federation Services are deployed. 

Note: if you do not have Azure Active Directory and do not have Active Directory
Federation Services, there is still a simple method involving an Agent deployment
that requires no changes to internal infrastructure.

## Related Products

Other layered products may be built on or integrated into Microsoft Dynamics. An
example is CRM Portals (PowerApps). These in turn might have a wider group of constituents,
albeit with a more narrow role.

The most convenient and secure method is to enable OpenID Connect. This [post](https://dylanbeattie.net/2016/11/14/identityserver-openid-connect-and.html)
shows some of the details.

For each application, a new “Authentication Client” is configured, and appropriate
users & groups are given access by Role.