Released DNN Azure AD B2C Provider v1.2

Hello folks. After building some sites with the new DNN Azure AD B2C provider, some new features have been being added over the last months, so is time to package them into a new release. I’m excited to announce the v1.2 release of the B2C provider, with solutions for some interesting scenarios. All the code is available at GitHub, and here is the link to the release notes:

• Download DNN Azure AD B2C Provider 1.2

Release notes

New features

• Added support for multiple-portals scenario:
• Added a new "Use Global Settings" setting to allow all portals on the same instance to share the configuration settings and use the same B2C tenant
• Added a new "Redirect Uri" setting to allow customization of the redirection after a user login
• Added a Redirection Controller to handle the user redirection on multi-portal auth scenario
• Added support for the special user claim mapping "portalId", to use it as a filter per portal.
• Added new support for custom claim mappings: user mappings, user profile mappings and role mappings. All the mappings are stored on the database and can be customized per portal.
• New user management module allows to manage Azure AD B2C users directly from the DNN interface, including the force password reset attribute (check "Samples/CustomPolicies/SignInWithForcePasswordReset").
• Now the user and role prefix can be disabled, so user and role names are more friendly (works really well when using "emails" claim as "Id" on the User mappings).
• When using JWT auth, now the user is synced in the same way than when using the web UI, even if the user doesn't exist (the user is then created and synced).
• Added Spanish (human) and German (auto) localizations.

Fixes

• Cache is now correctly cleared out after a configuration change
• User cache is correctly cleared out after a login, so the sync is done correctly
• Other bug fixes

List of contributors

• David Rodríguez (@davidjrh)
• César Abreu (@cesarab)

Noteworthy Changes in v1.2

Claim and role mappings by portal

This is one of the biggest changes on this version, allowing to map not only the user profile attributes, but also the user properties (username, Firstname, Lastname, email and portalId) as well as mapping the role synchronization (map a B2C role with an existing DNN role). Note that when using claim mappings, you can use custom attributes by adding the “extension_” prefix to the claim value (i.e. “extension_LoyaltyNumber”).

In this version, all the mappings are now stored on the DNN database and can be setup per portal.

Multi-portal support

The provider now supports working with multiple portals and sharing the same Azure AD B2C scenario with the introduction of some new settings to simplify the maintenance and make it possible. The first important setting is the “Use Global Settings”, so when this setting is set, all the provider settings are stored at host level instead of per portal (even the claim mappings).

A special mention to the “Redirection Controller” with the endpoint https://mysite.com/api/DotNetNuke.Authentication.Azure.B2C.Services/Authorization/RedirectToPortal built for this scenario, and successfully redirecting the user to the right portal when the B2C tenant is being shared across the DNN instance.

To take advantage of the new multi-portal support, you just need to setup two things:

• Create a custom attribute called “portalId” of type “Integer” on the B2C tenant
• Setup the “portalId” user mapping

Then you optionally can use the two new settings mentioned on the previous paragraphs to make the whole configuration easier.

New User Management Module

There is a new user management module that allows to manage the B2C users directly from the DNN user interface. The module uses the MS Graph API under the hoods, so the advanced settings must be setup before using the module. Operations allowed on this version are: CRUD user operations (including specifying auto-generated or manually entered passwords), sending a welcome e-mail, modifying the role membership and force the password on the next logon.

To allow the “Force password reset” command to work, a B2C custom policy must be setup. The steps would be:

• Create a custom attribute called “mustResetPassword” of type “Boolean” on the B2C tenant
• Follow the setup instructions described at https://github.com/intelequia/dnn.azureadb2cprovider/tree/master/samples/CustomPolicies/SignInWithForcePasswordReset/LocalAccounts

Give it a try and if you found any issue, please fill an issue on GitHub! Pull requests are welcomed!

Mis notas del Microsoft Inspire 2019

Ya ha pasado una semana desde que acabó el Microsoft Inspire 2019 en Las Vegas, el evento anual de partners de Microsoft donde nos empapamos de las novedades tecnológicas de la compañía y cómo podemos trasladarlas a nuestros clientes.

En esta edición, y supongo que tras recibir el feedback de la edición pasada, Microsoft ha unido el evento de partners y el interno de la compañía (Microsoft Ready) haciendo coincidir no solo las fechas, sino también numerosas actividades por lo que al menos en mi experiencia, ha habido más relación entre partners y personal de la compañía que en ediciones anteriores.

IUR y requerimientos de competencias

Antes de centrarme en las novedades sobre el área que más me interesa –Microsoft Azure-, una de las acciones más aplaudidas fue cuando Gavriella Schuster, Corporate VP – One Commercial Partner, abrió la conferencia el primer día comentando la decisión de dar marcha atrás a la decisión de eliminar los IUR, derechos de uso interno de software y servicios que Microsoft ha venido ofreciendo desde sus inicios. Semanas antes, el anuncio de la eliminación de los IUR había causado mucho revuelo ya que no sólo se eliminaban estos derechos, sino que se endurecían enormemente los requerimientos para conseguir las competencias que hacen que un Partner destaque en un área concreta.

Aunque por supuesto también se puede leer entre líneas el aviso a navegantes: tarde o temprano, esto va a suceder, solo que se anunciará con más antelación para que cada compañía pueda actuar en consecuencia. Si en décadas anteriores ceder licencias de uso interno no suponía un gasto directo en las cuentas de Microsoft, con la transformación del software en servicios en línea sí que hay costes operativos de mantener los servicios. No hay más que hacer números: casi 70.000 partners con derechos de uso interno de hasta 100 usuarios, puede llevar a unos costes, solo en Dynamics 365 de unos 300 millones de euros al año, y eso tirando a la baja.

Respecto al endurecimiento de las competencias la intención de Microsoft es, en mi opinión, reducir el número de partners quedándose con los más competentes y con aquellos que quieran apostar por el partnership y la oportunidad que hay por delante. Y si bien no será del gusto de todos, es algo que aplaudo ya que le dará muchísimo más valor al ecosistema de partners.

Nuevo contrato Microsoft Cloud Agreement (MCA)

Otro de los grandes puntos que estaban presentes en casi todas las sesiones a las que asistí, es la introducción del nuevo contrato de Microsoft para servicios en la nube. Este contrato viene a resolver la problemática que ha existido entre las diferentes formas que un cliente puede adquirir los servicios de Microsoft: directamente (Self-Service); a través de un Enterprise Agreement; o a través de un partner de nuevo con diversos formatos, siendo el Cloud Solution Provider (CSP) el más extendido durante los últimos años.

La idea es la unificación de todos los canales en un mismo MCA que es el que firma el cliente final, con lo que el cliente se puede mover entre los distintos canales sin necesidad de hacer malabarismos. Hoy en día, por ejemplo, no se puede migrar el contenido de una suscripción EA a una CSP o viceversa, sin hacer complejas operaciones de migración. También permitirá por fin, ofrecer todas el software de terceros que existe en el marketplace de Azure a través de la red de partners y bajo el mismo contrato.

Obviamente la facilidad de que el cliente se pueda mover de un modelo a otro de forma trasparente, puede llevar a pensar que Microsoft quiere partners que den valor añadido, bien sea a través de servicios administrados, consultoría, etc. o cualquier otra acción que aporte valor en la cadena. Los partners que se dediquen exclusivamente a la reventa de suscripciones sin aportar nada adicional, podrían ver peligrar sus operaciones si continúan con ese modelo, por lo que es un buen momento para analizar qué servicio diferencial pueden ofrecer a sus clientes.

Este nuevo contrato ya está disponible en versión preliminar para que los asociados puedan revisarlo, y podrá comenzar a aplicarse de forma voluntaria a partir del 1 de septiembre de 2019, siendo de forma obligatoria a partir del 31 de enero de 2020.

Servicios profesionales en el Azure Marketplace

Y para facilitar la tarea de ofrecer valor, Microsoft abre en el Azure Marketplace dos nuevas categorías que cada partner puede ofrecer a sus clientes basados en servicios profesionales:

• Servicios administrados: los partners podrán publicar ofertas de servicios administrados a través del Azure Marketplace, de manera que cualquier cliente podrá contratar directamente los servicios de un partner a través del portal de Azure para que les ayude a administrar una carga de trabajo determinada (aquí la especialización también será un factor decisivo);
• Servicios de consultoría: si bien esto ya estaba disponible en algunas regiones (USA, Canadá, etc.), ahora se abre a cualquier partner para que pueda ofrecer distintos servicios de consultoría, workshops, formación, etc. directamente a través del portal de Azure.

Personalmente lo que se me antoja complicado es la visibilidad que puedan llegar a tener estas ofertas si tan solo la mitad de los 70.000 partners suben al marketplace sus ofertas de servicios profesionales. Me imagino que en varias iteraciones se irá afinando para que los clientes puedan descubrirlas a través de diversas utilidades como restricción geográfica y otros parámetros, como se hace hoy en día cuando un cliente busca un asociado en la MPN.

Azure Lighthouse

Y precisamente para apoyar todo el mensaje anterior, nace Azure Lighthouse, una herramienta para que hacer la vida más fácil a los que gestionamos suscripciones de Azure de distintos tenants y de distintos clientes.

Esta herramienta permite, si tener que estar cambiando de tenant en el portal de Azure, poder administrar las suscripciones y recursos de los tenants de los clientes a quienes éstos hayan concedido acceso de forma segura. Se acabó el tema de estar usando credenciales en cada cliente, o tener una lista de más de 100 tenants bajo el perfil de usuario. También abre la posibilidad de poder monitorizar desde un mismo dashboard recursos de diversas cuentas. Según nos comentaron, durante el periodo de prueba interno los que usaron la herramienta vieron incrementada su productividad un 70%. ¿Aún no he comentado que es gratuita?

Por otra parte, no es una herramienta exclusiva para asociados, por lo que si tienes un entorno con varios tenants, y tienes la misma problemática, seguramente vas a querer utilizarla.

Precios fijados en USD, facturados en moneda local

Y finalmente, otra de las cosas con las que tengo sentimientos encontrados, es la unificación global de los precios de Azure en un único listado de precios en dólares estadounidenses. Esto quiere decir que se equipara el formato con el de AWS, que ha evitado el tener que fijar precios en cada moneda local a lo largo y ancho del globo. La factura se realizará en cualquier caso, en la moneda local con el tipo de cambio que esté en ese mes.

“Based on customer and partner feedback, the new Azure experience in CSP will use a single pricelist, in USD, providing customers and partners with consistent pricing at a global scale. This will allow for a more transparent and simplified pricing reference, regardless of how the customer buys Azure from Microsoft.” https://blogs.partner.microsoft.com/mpn/expanding-partner-opportunities-with-azure-csp/

Esta es una de las acciones que más me hace pensar sobre varios escenarios:

• ISVs que hasta ahora tenían fijados unos costes operativos, puede que ahora estos costes sean variables si trabajan con moneda distinta al dólar estadounidense;
• Cómo vender a los clientes el hecho de que si bien ya es difícil hacer una estimación de consumo según pago por uso, ahora hay que añadir las posibles variaciones en el tipo de cambio de divisas
• Cómo se van a tomar esto los clientes que no han trabajado nunca con una moneda que no sea la propia

Lo que está claro es que eso para los clientes de AWS nunca ha sido un problema, y lo que Microsoft quiere en este sentido, aparte de simplificar enormemente sus operaciones internas, es la de que sea más fácil comparar peras con peras. ¿Empujará esto el uso de instancias reservadas para así hacer los pagos upfront y evitar posibles cambios en la conversión de divisas?

Conclusiones

La verdad es que esta edición del Microsoft Inspire ha sido muy…inspiradora :) No solo por tener de nuevo la oportunidad de ver y oír a Satya Nadella introduciendo el futuro que tenemos y vamos a construir (pulsa en la imagen para ver la Corenote completa);

no sólo por la oportunidad de ver en directo a Simon Sinek con su charla “The Infinite Game” que por cierto, creo que la parte de las preguntas y respuestas me gustó incluso más que la propia charla; no solo por la oportunidad de poder a ver a Queen + Adam Lambert en directo…que también! Sino también por la oportunidad de conectar con una red global de asociados demostrando que es el sitio para hacer negocios en torno a tecnologías Microsoft.

No quisiera terminar sin también destacar el buen trabajo del equipo a cargo de la delegación española que hizo que todo saliera a la perfección, no solo eligiendo unas actividades en sitios “refrescantes” (los 47ºC que llegué a ver en un termómetro no son para tomárselo a broma), sino manteniéndonos constantemente informados de todo lo que iba a suceder. Chapó!

¡Nos vemos en Microsoft Inspire 2020!

New Azure Active Directory B2C provider for DNN Platform

Hello folks! Today I’m happy to announce the release of a new auth provider for DNN Platform, that leverages all the power of Azure Active Directory B2C to any DNN based website. In short, this allows you to use a common and centralized identity service across all your customer facing applications, including the integration of your DNN website.
And is Open Source and available on GitHub!

• Project home: https://github.com/intelequia/dnn.azureadb2cprovider
• Download v1.0: https://github.com/intelequia/dnn.azureadb2cprovider/releases/tag/v1.0

Azure AD and B2C

Some of you probably may be thinking about the difference between this new provider and the other DNN Azure AD Auth Provider already available. Let’s say that the previous one supports Azure AD and this new one supports Azure AD B2C. So what’s the difference?
From Tomasz Onyszko answer at StackOverflow:
“Azure AD is a directory service with the goal of serving organisations and their needs for identity management in the cloud. You develop against Azure AD, you can secure your applications with it - their users in Azure AD tenants can use it. Your application is targeted for a specific organisation or multiple organisations using Azure AD (Office 365).
Azure AD B2C is another service built on the same technology but not the same in functionality as Azure AD. Azure AD B2C target is to build a directory for consumer applications where users can register with e-mail ID or social providers like Google, FB, MSA, known as Federation Gateway. The goal for Azure AD B2C is to allow organizations to manage single directory of customer identities shared among all applications i.e. single sign-on.”
I recommend to  read his blog post about the differences between Azure AD, B2B and B2C for better understanding.
But in summary, if you:

• are planning a website where your users are part of your own O365/Azure AD tenant, so let’s say they are internal users accessing an intranet zone, you should be using the Azure AD Auth provider;
• are planning a website where your users are external users and optionally want to allow them to use the ability to login with 3rd party identity providers such as Facebook, Google, Microsoft accounts, etc. then use the Azure AD B2C provider;

BTW, the new DNN Azure AD B2C provider has some new powerful features that hasn’t been implemented yet on the DNN Azure AD provider, such as JWT auth, so you will be in any case interested on using the B2C in the most of your DNN based websites.

Features

For this initial release, the number of features is much greater than in the other provider:

• Provides DNN Platform - Azure AD B2C integration by portal, so each portal on a DNN installation can setup their own Auth settings
• Allows auto-redirection, so users are automatically redirected to the Azure AD B2C login without seeing the DNN login page
• Supports the following policies (user flows):
• Sign up/Sign in: users can register on Azure AD B2C and then login, or just login
• Profile: users can update their user profile when clicking on the DNN user profile link
• Reset password: users can initiate the reset password flow by clicking on the "forgot password" link available on the login screen
• When a user login on Azure AD B2C, the B2C profile and roles are synchronized with DNN profile and DNN roles. If a role doesn't exist, is created in the process
• Supports User profile picture synchronization as part of the profile synchronization
• Supports JWT authorization. If enabled, developers can get a JWT auth token directly from Azure B2C login using the "Resource Owner" policy, and then use that token to call any DNN WebAPI Controller with the Auth scheme "JWT".
• Supports for 3rd party WebAPI integration through API Resource and scopes implementation

Samples

And included with the release, there are some code samples to show some advanced integration features with other non DNN apps, such as mobile apps, JWT auth, etc.

• Hello sample: simple console App, that allows you to login with a username and password into Azure AD B2C, and then call a DNN WebAPI controller
• External Webpp and WebAPI with B2C: slight modified version of the sample available on the Microsoft Azure B2C repo samples, with a webapp and a webapi consuming Azure AD B2C. Modification to setup CORS, to allow the DNN module example work with the webapi.
• MVC/SPA DNN module with WebAPI client: a To-do list DNN module example, that calls an external WebAPI by using B2C JWT tokens.

This is the first release of the module, so expect new features coming soon. If you see any missing feature, let me know or just do a pull request. Any help is welcome!

Automating Azure Application Gateway SSL certificate renewals with Let’s Encrypt and Azure Automation

Let’s Encrypt is a FREE, automated and open Certificate Authority brought to you by the non-profit Internet Security Research Group (ISRG) and supported by big corps such as Google, Facebook, Microsoft, and many others, to have a more secure and privacy-respecting Web.

Many websites and services are already using it worldwide. If you can get SSL certificates issued by a well-known CA for free, there is no excuse to use HTTPS on your website and be secure by default. The process of issuing a Let’s Encrypt certificate can be automated by using a piece of software that uses the ACME protocol, which typically runs on your web host. These certificates normally expire in no longer than 3 months (something that increases the security of the system), so you need to automate the renewals to avoid the manual renewals.

A good example of this implementation is the Azure App Service Let’s Encrypt extension, that automates the renewals by using a webjob. You can read more about it at this Scott Hanselman’s blog post.

When using an Azure Application Gateway, one of the things you need to do is to install the SSL certificate on the gateway. You probably want to implement SSL offloading, so all the resources needed to secure the communication channel is handled by the gateway and not by the servers behind.

On this post I’m going to explain just this scenario, showing how you can automate the Let’s Encrypt SSL renewals on an Azure Application Gateway. Special mention to Ricardo León from Intelequia, who worked on the implementation shown below.

The renewal process explained

The idea behind this implementation is to avoid any modification on whatever infrastructure is behind the Application Gateway, to complete the renewal checks and validations made by Let’s Encrypt process. In summary:

1. an Azure Automation runbook will be executed in a schedule (i.e. once every two weeks) to renew and install the current Let's Encrypt certificate.  Let’s Encrypt needs to validate the domain ownership, so it returns a challenge code which is stored by the runbook on a storage account behind the application gateway;
2. a special rule on the Application Gateway redirects the validation check coming from Let’s Encrypt to the storage account, so the domain ownership check is successful
3. the Azure Automation runbook finally downloads the new certificate and install it on the Application Gateway

Note that with this implementation, there is no need to manipulate any other infrastructure behind the Application Gateway. 

Issuing and installing the Let’s Encrypt certificate the first time

I wanted to issue and automate the renewals of Let’s Encrypt certificates for “api.davidjrh.com”. Note that I had already a DNS record of Type A targeting my Application Gateway.

C:\>nslookup api.davidjrh.com
Servidor:  google-public-dns-a.google.com
Address:  8.8.8.8

Respuesta no autoritativa:
Nombre:  api.davidjrh.com
Address:  23.102.37.253

To implement the Let’s Encrypt renewal process to issue new SSL certificates on the Application Gateway, follow these steps:

Create a Storage Account

1. Create an Azure Storage account that will be used to host the challenge requests for the DNS domain ownership check. Use the cheapest parameters such as “Standard performance” and LRS.

2. Once the storage account is ready, create a “public” container with “public blob” permissions

3. Create the virtual directory “\.well-known\acme-challenge” using the Storage Explorer tool.

Modify the Application Gateway to redirect ACME challenge requests to the storage account

4. When you created the Azure Application Gateway, you probably specified a HTTP rule that was associated to an http listener. In this case, you need to delete that rule that will be replaced by a Path-based rule as shown in the next step

5. Create a new path-based rule that redirects the requests that will be made by Let’s Encrypt on the renewal process with the following configuration:

6. Set the parameters you had on the http rule, and click on “Add Configuration”

7. Specify the configuration parameters with the path “/.well-known/acme-challenge/*” with a redirection (Permanent), targeting an external site with the storage account container URL you created before:

9. Test the rule by creating a file called “test.html” on the storage account and browsing the URL /.well-known/acme-challenge/test.html">/.well-known/acme-challenge/test.html">http://<yourdomain>/.well-known/acme-challenge/test.html

If everything was setup correctly, when browsing the URL, the application gateway should redirect your browser to the storage account as shown below. Don’t continue until you have successfully setup the redirection rule.

Installing the Let’s Encrypt certificate by the first time on the Gateway

To install the Let’s Encrypt certificate on the gateway the first time, you have to issue it first. There are several ways to issue the certificate, but the easiest one is to use Certbot, a tool available on GitHub and built on Python that allows you to obtain certs from Let’s Encrypt. There are other clients, so you can probably share better ideas on the comments area of this post.

I normally use a Windows 10 PC as development environment, and the process to install the tool is described on this link, that basically shows how to install Python and then run “pip install certbot”. But since I had the Linux subsystem enabled on my Windows laptop running Ubuntu, so I followed this other approach:

1. Opened a bash console on the Linux subsystem
2. Installed Python with “sudo apt-get install certbot”
3. Executed the following command to only issue the certificate locally in manual mode, by registering an account with my e-mail address on Let’s Encrypt service and issuing a certificate for domain “api.davidjrh.com” agreeing to the Terms of Service:
   sudo certbot certonly --email davidj@intelequia.com -d api.davidjrh.com --agree-tos --manual
   
4. Followed the screen instructions and created the file on the storage account with the required contents
   
5. Successfully issued the certificate

davidjrh@DESKTOP-JQL0N5G:~$ sudo ls /etc/letsencrypt/live/api.davidjrh.com
README  cert.pem  chain.pem  fullchain.pem  privkey.pem

The certificate, chain and key are issued in .pem format, so to upload the certificate in .pfx, I used OpenSSL to convert from PEM to PFX:

Finally, I modified my current HTTPS listener to use the LetsEncrypt certificate. IMPORTANT: remember the name you are going to give to this certificate, since you will need to specify it as a parameter on the renewal process later

After applying the changes, you can check that the LetsEncrypt SSL certificate is working properly just by browsing a resource via HTTPS

Implementing the renewal process

Now that the LetsEncrypt certificate is installed and working properly, the next step is to automate the renewals. Let’s do it with an Azure Automation runbook.

Create an Automation Account

1. On the Azure Portal, create an Azure Automation account (or use an existing one) to host the runbook. Note that you can create this automation account and run up to 500 minutes per month for free.

2. Inside the Automation resource, open the Modules and browse the gallery to import the following modules: 'AzureRM.profile', 'AzureRM.Network' and 'ACMESharp'. Ensure you import the latest version of all of them and update the current ones already imported (for example, the AzureRM.profile is enabled by default, but we need the latest version available on the gallery).

3. On the Azure Automation account, create a PowerShell runbook called LetsEncryptCertificateRenewal

4. Edit the powershell runbook and paste the contents of the script available at GitHub on https://github.com/intelequia/letsencrypt-aw/blob/master/letsencryptaw_v2.ps1, and click on the “Publish” button to make it available for scheduling

You can test the runbook on the Test pane, and passing the required parameters (domain name, email address used on LetsEncrypt,  resource group names, storage account name, application gateway name and the name of the certificate you used when setting up the https listener). It takes around 15min to complete. When browsing the site again with https, you will notice that the certificate was updated correctly.

IMPORTANT: LetsEncrypt has its own weekly limits when issuing certificates for a specific domain in production (50 per week), so be aware when testing the PowerShell script.

5. Create an Azure Automation Schedule to renew the SSL certificate. In my case, I created a schedule for renewing it every 2 weeks

6. Setup the parameters to schedule the runbook with the schedule you created before.

And that’s all. Now you have setup the autorenewals of your Application Gateway SSL certificate with Azure Automation.

[Podcast] La nube, inteligencia artificial y otros temas en Ycoden Daute Radio

El pasado martes 4 de diciembre tuve el placer de disfrutar de unos minutos de radio en Ycoden Daute Radio en compañía de Narciso Ramos, en los que hablamos de la nube, inteligencia artificial y algunos otros temas. Les dejo con la grabación del programa por si alguno se lo perdió.

Un saludo y Happy Coding!