Después de publicar el blog en Hugo, en este post vamos a ver como usar una Azure Static Web App con autenticación personalizada para poner on-line nuestro sitio de Hugo.
Aunque no es el propósito de este entrada, sólo mencionar que también podrías publicar tu sitio en una storage account. Basta con crear un contenedor llamado $web y activar la opción de servir contenido estático en la cuenta de almacenamiento. Las opciones son limitadas, poco más que establecer el documento por defecto y una página de error, pero para probar algo rápido cumple su función. Puedes encontrar más información aquí.
Con una Azure Static Web App, publicar nuestro sitio de Hugo será coser y cantar. Básicamente (y durante la creación del recurso en Azure), el wizard nos pedirá la siguiente información:
- Organización
- Repositorio
- Rama
A partir de ahí (y asumiendo estamos usando las rutas por defecto que sugiere Hugo), la Static Web App se encargará de crear en nuestro repositorio un workflow y un secreto para publicar el sitio en cada push o pull-request.
name: Azure Static Web Apps CI/CD
on:
push:
branches:
- main
pull_request:
types: [opened, synchronize, reopened, closed]
branches:
- main
jobs:
build_and_deploy_job:
if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
runs-on: ubuntu-latest
name: Build and Deploy Job
steps:
- uses: actions/checkout@v2
with:
submodules: true
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_<A_RANDOM_NAME> }}
repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
action: "upload"
###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
# For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
app_location: "/" # App source code path
api_location: "" # Api source code path - optional
output_location: "public" # Built app content directory - optional
###### End of Repository/Build Configurations ######
close_pull_request_job:
if: github.event_name == 'pull_request' && github.event.action == 'closed'
runs-on: ubuntu-latest
name: Close Pull Request Job
steps:
- name: Close Pull Request
id: closepullrequest
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_<A_RANDOM_NAME> }}
action: "close"
A golpe de click podemos publicar Hugo en una Azure Static Web App.
Donde se complica un poco la cosa es si queremos hacer privado nuestro sitio y no queremos usar el flujo de invitaciones. La verdad es que las invitaciones funcionan bien y están integradas (de nuevo a golpe de click) con los proveedores de autenticación más habituales (GitHub, Facebook, Twitter, Google, etc.). Sin embargo hay un gran pero, por ahora sólo se pueden hacer 25 invitaciones. Por eso, usando autenticación personalizada te puedes olvidar de esta limitación y dar acceso a todos los usuarios de un proveedor (por ejemplo un tenant de AAD).
Para activar la autenticación personalizada tenemos que crear y configurar un App registration.
La clave está en añadir una plataforma en autenticación con la “correcta” URI de redirección y seleccionar qué tipo de token hay que emitir.
En cuanto a la URI de redirección, será https://<URL_DE_NUESTRA_STATIC_WEB_APP>/.auth/login/aad/callback
Para el token, hay que activar ID tokens (used for implicit and hybrid flows) en la sección “Flujos de concesión implícita e híbridos”.
Con el App registration ya configurado y con un secreto que hayamos creado, es hora de configurar nuestra aplicación.
Lo primero sería crear un fichero staticwebapp.config.json en la raíz del repositorio. Con este fichero podemos configurar nuestra Static Web App.
{
"routes": [
{
"route": "/*",
"allowedRoles": [
"authenticated"
]
}
],
"responseOverrides": {
"401": {
"redirect": "/.auth/login/aad",
"statusCode": 302
}
},
"auth": {
"identityProviders": {
"azureActiveDirectory": {
"userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"registration": {
"openIdIssuer": "https://login.microsoftonline.com/<YOUR_TENANT_ID>",
"clientIdSettingName": "CLIENT_ID",
"clientSecretSettingName": "CLIENT_SECRET"
}
}
}
}
}
Después, tendremos que crear un par de variables de configuración en nuestra aplicación, CLIENT_ID y CLIENT_SECRET.
Ahora sí, la autenticación personalizada con AAD debería funcionar.
Por defecto, cualquier usuario del AAD podrá entrar a nuestra aplicación, pero si queremos limitar su acceso, podemos hacerlo activando la siguiente opción en la configuración de nuestro Service Principal:
y después asignado grupos y/o usuarios del AAD desde:
Por último, otra característica muy útil de las Static Web App es que crearán nuevos entorno automáticamente por cada pull-request. De esta forma, podemos ver como quedaría nuestro sitio de Hugo en vivo antes de publicarlo en producción. Para que funcione la autenticación personalizada en los nuevos entornos, tendrás que agregar URIs de redirección adicionales a tu App registration.
Un saludo!