Integration with The Portal Connector
When it comes to user authentication, The Portal Connector relies on Sitefinity to handle that aspect of the application. In fact, The Portal Connector does not become involved with user authentication until after the user has successfully authenticated with the given provider. Once the user has authenticated, if they are registering for the first time with the application, The Portal Connector will fire an authentication event handler that will wire up the Sitefinity User Profile to a new or existing contact and portal user in the Dynamics CRM Instance.
By default, this authentication handler will map the Sitefinity user to a CRM contact based on the email address. Although the entire User Handler can be customized to fulfil any special custom authentication requirements, such as linking to a contact based on their phone number or a special UPN. This can be accomplished by either extending the DefaultTpcExternalAuthUserHandler or creating your own implementation of the ITpcExternalAuthUserHandler interface. Often this would be used in conjunction with claim-to-field mappings in the authentication provider. For more information on how to extend The Portal Connectors External Authentication User Handler, please see the following documentation: https://www.crmportalconnector.com/developer-network/documentation/developing-for-tpc/extending-portal-connector-oauth-registrations.
Dynamics CRM Authentication with The Portal Connector
The Portal Connector has a variety of ways that can be used to authenticate with a Dynamics CRM instance. By default, the following authentication mechanisms are supported.
- Online / On-Premise (Username and Password)
- OAuth
- Client Secret
The Online and On-Premise connection types use a simple username and password flow, which may be required by some On-Premise instances of Dynamics CRM, although we would always recommend the use of either the OAuth or Client Secret connection types where possible as they are designed specifically for app-to-app communication using OAuth protocol. When using username and password, you are prone to issues with conditional access, and multi-factor authentication. For more information on setting up the authentication between The Portal Connector and Dynamics CRM, please see the following documentation:
Client Secret Authentication - https://www.crmportalconnector.com/developer-network/documentation/how-tos/mvc-based-widgets/set-up-client-secret-connection
OAuth Authentication – https://www.crmportalconnector.com/developer-network/documentation/how-tos/mvc-based-widgets/set-up-oauth-2.0-connection-to-dynamics
Traditional Configuration
The last authentication flow we will examine is the authentication between Sitefinity and the database. The Database connection in Sitefinity can be stored in a few different locations. The most common location is where it is stored by default, which is in the DataConfig.config file under App_Data/Sitefinity/Configuration/DataConfig.config. Another common location to store the connection string is in the web.config file of the web application. When you are deploying a Sitefinity instance to Azure, usually you use the web.config in conjunction with Web App Application Settings to secure the connection string.
When running the application on-premises, the username and password of the connection are stored in plain-text. If you are concerned about the credentials to the database being exposed, there is a way to encrypt the connection string inside the web.config that is used to connect to Sitefinity. If you are interested in learning how to encrypt the Sitefinity database connection string, please see the following documentation: https://knowledgebase.progress.com/articles/Article/Encryption-of-Sitefinity-connection-strings.
Managed Identities
If you have deployed your Sitefinity application to a cloud environment, there is a way to secure the authentication between the application and database even further. This can be accomplished by using Managed Identities. At a high-level, when you use managed identities the application itself becomes the identity rather than using credentials to connect. This is the best practice for high-security environments such as the government cloud. If you are interested in implementing managed identities to secure the communication between Sitefinity and the Database, please check out the documentation below.
Managed Identities - https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
Managed Identities with Sitefinity - https://community.progress.com/s/article/advice-on-setting-up-a-managed-identity-on-azure-sql.
Conclusion
When it comes to authentication with Sitefinity and The Portal Connector, the sky is the limit. Throughout these blog posts we looked at some of the simplest scenarios where we were able to utilize common authentication protocols like OpenId Connect or built-in fully fledged providers like ADFS out-of-the-box to implement authentication in a matter of hours. In complex situations, Sitefinity and The Portal Connector provide the extensibility to handle virtually any complex custom authentication scenario you could throw at it. Hopefully these articles have provided a high-level overview of what you can expect with authentication using Sitefinity and The Portal Connector, and some resources in case you find yourself working on your own custom authentication implementation in the future.
-Thanks for reading