#ver subscripcion seleccionada
az account show 

# ver todas subscripciones disponibles
az account list 

# seleccionar suscripcion
az account set --subscription {id} 

see & manage resource-groups

az group list
az group delete --name {name} 

Azure Backup Vault atascada

Se me ha quedado un backup atascado que no me dejaba borrarlo por la web. Con CLI hay que desregistrarlo y luego ya se puede borrar

# we should be able to see the resource
az backup container list -g learn-with-ai -v vault-xx00xxxx --backup-management-type AzureStorage

# unregister
az backup container unregister -g learn-with-ai -v vault-xx00xxxx --backup-management-type AzureStorage

23 Apr, 2025

Azure AD B2C - Notes

In Azure AD B2C you’ve two ways to provide identity UX:

user flows - predefined, built-in, configurable policies so you can create sign-up/in and policy editing UX in minutes.
custom policies - enable you to create your own user journeys for complex identity experience scenarios.

User Flows

For the most common identity tasks. Things like:

Account types used for sign-in, such as social accounts or local accounts.
Attributes to be collected from the consumer.
MFA
User interface customization
Set of claims in a token your app receives

Custom Policies

They’re config files that define the behaviour of your Azure AD B2C tenant UX. They can be fully edited by an identity developer to complete many different tasks.

It’s fully configurable and policy-driven.

Federate with other identity providers
Third party MFA
Collect any user input
Integrate with external systems using REST API communication

Each user journey is defined by a policy. You can build as many or as few policies as you need.

Defined by several XML files that refer to each other in a hierarchical chain.

Starter Pack

The starter pack comes with pre-built policies.

LocalAccounts - Enables the use of local accounts only.
SocialAccounts - Enables the use of social (or federated) accounts only.
SocialAndLocalAccounts - Enables the use of both local and social accounts. Most of our samples refer to this policy.
SocialAndLocalAccountsWithMFA - Enables social, local, and multi-factor authentication options.

Each starter pack includes:

a base file that contains most definitions. To help with troubleshooting and long-term maintenance of your policies, try to minimize the number of changes you make to this file.
an extension file holds the unique config changes for your tenant. This file is derived from the base file. Use this to add new functionality or override existing functionality. e.g. to federate with new identity providers.
a relying party (RP) file is the single task-focused file that’s invoked directly by the relying party application, such as web, mobile or desktop app. Each unique task such as sign-up/in, password reset etc requires its own relying party policy file. This file is derived from the extensions file. You can add more relying party policies. (e.g. delete my account, change a phone number…)

The basics

Claim

A claim provides temporary storage of data during an Azure AD B2C policy execution. It can store info about the user, such as first name, last name… or any other claim obtainer from the user or other systems. The claim schema is the place where you declare your claims.

When a policy runs, B2C sends and receives claims to and from internal and external parties, then sends a subset of these claims to your relying party app as part of the token.

Claims are saved, read, or updated against the directory user object.
Claims are received from an external identity provder.
Claims are sent or received using a custom REST API service.
Data is collected as claims from the user during sign-up or edit profile flows.

Claims transformation are predefined functions to convert a given claim into another one, evaluate a claim or set a claim value.

User Journey

They allow you to define business logic with path through which users will follow to gain access to your application. The user is taken through this journey to retrieve the claims that are to be presented to your app.

A user journey is built from a sequence of orchestration steps.

How you can add orchestration steps to social and local account starter pack.

Orchestration Steps

A user must reach the last step to acquire a token. Orchestration steps can be conditionally executed based on preconditions. After an step completes, B2C stores the outputted claims in the claims bag. This bag can be used by any further orchestration steps in the user’s journey.

Reference(s)

https://docs.microsoft.com/en-us/azure/active-directory-b2c/user-flow-overview
https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-overview

22 Apr, 2025

Azure AD B2C - JWK

JSON Web Key (JWK) represents a set of public keys as a JSON object. This format is used to represent bare keys.

The following is a key example:

{
  "jwk": [
    {
      "alg": "EC",
      "crv": "P-256",
      "x": "{x_value}",
      "y": "{y_value}",
      "use": "enc",
      "kid": "1"
    },
    {
      "alg": "RSA",
      "mod": "{mod_value}",
      "exp": "AQAB",
      "kid": "2011-04-29"
    }
  ]
}

It’s possible to go from PEM format to JWK and from JWK to PEM.

Azure AD B2C creates and validates user flows with keys. It automatically rotates them, but they’re created as JWK and not PEM.
To validate the JWT we need to:

Go to the keys endpoint:
Copy JWK.
Convert to PEM.
Validate it with PEM public key.

As the documentation states the client needs to check periodically for new JWK keys, as they rotate them. A good period check is every 24 hours.

Reference(s)

https://openid.net/specs/draft-jones-json-web-key-03.html#anchor1
https://stackoverflow.com/questions/50816301/msal-access-token-invalid-signature
https://docs.microsoft.com/es-es/azure/active-directory-b2c/tokens-overview

21 Apr, 2025

Azure AD B2C

Azure AD B2C is Identity as a Service. It allows you to login into apps or use Twitter, Google or other authenticators. They can sign up or sign in. OpenID, OAuth, SAML.

Customers get to use their preferred accounts to sign up or create a regular user / pwd. You can customize the login experience.

App Types

This is best for the following types:

Server-based web apps work perfectly. They use OpenID Connect for all UX.
Mobile apps. They use OAuth2 auth code flow.
Web services and APIs. OAuth2.

This doesn’t work together with Azure AD B2C.

Daemons.
Web API chains.

Configure Azure Active Directory B2C

Create new resource -> B2C -> Create new tenant -> enter general information

Notice for the initial domain name, the full domain will be *.onmicrosoft.com

Once a tenant is provisioned, click to manage it. A new tab opens, this is because the B2C tenant is separate from your Azure subscription’s tenant. Your Azure subscription has an Azure Active Directory Tenant associated with it and this new B2C one is distinct and separate. It’s its own directory.

Inside we have the following modules or tabs:

Applications: websites or web APIs or Apps
Identity provider: lists all identity providers such as Facebook or Github and your users may log in through them.
User attributes: you can see all metadata you collect from users.
Users: you can see and edit all users who have created accounts.
User flows: Heart and soul of Azure AD B2C as it guides users through the sign in or sign up, or password resets.
Audit Logs: Authentication of various apps or administrative events.

Link Azure AD B2C Tenant

Before being able to use the B2C instance, you also have to link the B2C directory back to the main subscription. This makes it a service for you to use.

Create new resource -> Azure Active Directory B2C -> Create -> Link existing Azure AD B2C Tenant to my Azure subscription -> select the one you just created -> put it into a resource group

User flow

The flows are reusable. They controls when social accounts can be used to sign in.
The attributes to collect from the user. (you can collect standard or custom ones). To use MFA or not.
User interface customization. Information inside the token that’s returned from B2C. It can be used across B2C apps. They’re entirely reusable.

Azure AD B2C Application - it’s not your web or API. It’s models apps that have authentication added. It makes sure only your users can sign-in.

Redirect URI - where to redirect response after the user’s been authenticated. As a test, put https://jwt.ms to see what’s inside the JWT token.

Built-in User Flows

There’re 3 recommended to have, but you can create custom ones:

Sign-in/up.
Profile editing.
Password reset.

Everything that controls the journeys of the users is located under Policies.

Social network provider are called identity providers (IdP). In order to use them, you have to configure them first. You will get a key which you enter into B2C and the authentication will happen seamlessly.

B2C Application Deep Dive

A B2C app models the real world. Every real-world app needs a B2C app.

reply URL: URL where responses will be returned to your webapp. App ID: unique ID that identifies your B2C app.
They obey standards like OAuth 2.0 or OpenID Connect.
When you want to interact with it, you specify your user flow.

Everything from Sign in to get Resource token happens inside Azure, not your app.

Tokens

They’re the way that B2C uses to transmit claims about a user calling Apps. They’re all JWT tokens.

ID token: contains claims user to identify user. (e.g. user’s object ID in AD). You must always validate it. Access token: Claims used to identify API permissions. Validate it. Refresh token: It should be a black box to your app. Both others tokens expire.

How server-based apps authentication works with B2C. Underlying authentication protocol is OpenID Connect.

Custom Policies

Individual steps into a user’s journey:

They’re XML files
have a Schema definition (which will be used to return the tokens)
Content definition - Things like how to render pages. Technical profiles - they’re the endpoints and how to communicate with identity providers. Orchestration - steps that are contained within the custom policies

Policy Files

In order to work with custom policies we’ll need to handle three files:

base file - contains most definitions. make minimal changes. you shouldn’t ever have to change this file. Starting point that every B2C tenant would use. Contains the common elements for everything.
Extensions file - unique config for tenant. Make changes here that overrides anything in the base file. These changes apply to the entire tenant.
Relying party file - single task focused that’s invoked by app. This is the file that your app invokes. Use this file to make any final tweaks to the user’s journey.

Reference(s)

User flows and custom policies in Azure Active Directory B2C - Azure AD B2C | Microsoft Learn

27 Aug, 2022

Azure Functions - Fundamentals

Files that compose an Azure Function:

a Readme file
function.json -> this is an important file. it defines each Azure function in a function App. It specifies things like what event triggers this function, HTTP methods, auth, etc.
run.csx

How to create an Azure Function

Create a resource -> Compute -> Function App.

The function name has to be unique.
Create new resource group.
You can choose the OS.

Storage:
Create a new recommended storage.
It offers to create an application insight instance for us. This stores logs and diagnostic information. This is really recommended.

On Configuration > Application settings you can create sys envs which will appear in your code.

There’s a storage explorer where you may see the contents for your function in real time.

Understanding Triggers and Bindings

There’re a lot of trigger types

Timers, HTTP requests
Queue messages, blobs, Comsos DB

Input / Output Bindings

Connect to external resources
Reduce amount of code

To work with Azure Functions, you may work with Visual Studio. There’s an option to enable “Azure Development” with which you’ll be able to project and run your functions locally.

26 Aug, 2022

Azure Functions - Introduction

Azure Functions are based in serverless programming. They integrate easily with other Azure services. You provide Code to execute and an event that triggers it.
For example to run background tasks every hour.

They’re brilliant for:

experiments and rapid prototyping.
automating development processes.
decomposing or extending monolithic apps.
independent scaling.
adapters for integrating systems.

Azure Functions vs other similar services

Azure Functions is built on top of the web jobs SDK and it’s hosted on the app service platform.

Virtual Machines (IaaS)

With VM you can install whatever you want: web servers, services etc. This is known as IaaS (infrastructure as a service). You can choose OS and have complete control of the server, but you’re responsible for it: Patching, maintaining, scaling, operational overhead.

25 Aug, 2022

Azure CosmosDB Query Examples

This are examples of queries to use for Azure CosmosDB, as this database uses a restricted version of SQL and it doesn’t allow all queries or joins.

Partial queries

To be used with the main, partial query. This query starts with something such as SELECT * FROM c

WHERE c.ts LIKE "%2022/03/10%" 
ORDER BY c.ts DESC

WHERE c.type = "Writeable" 
AND c.ts LIKE "%2022/03/10, 15:2%" 
ORDER BY c.ts DESC

Full queries

Normal SQL queries to be used as custom queries. Note that CosmosDB doesn’t support a 100% of all SQL statements.

(count number of entries)

SELECT COUNT(1) FROM c 
	WHERE c.ts LIKE "%2022/03/10%" 
	ORDER BY c.ts DESC

Posts Tagged - azure

Azure Meta

Azure Functions

CosmosDB

Azure AD B2C

Naming Strategy

Reference(s)

Azure Backup Vault atascada

User Flows

Custom Policies

Starter Pack

The basics

Claim

User Journey

Orchestration Steps

Reference(s)

Reference(s)

App Types

Configure Azure Active Directory B2C

Link Azure AD B2C Tenant

User flow

Built-in User Flows

Social Providers

B2C Application Deep Dive

Tokens

Custom Policies

Policy Files

Reference(s)

How to create an Azure Function

Understanding Triggers and Bindings

Azure Functions vs other similar services

Virtual Machines (IaaS)

Partial queries

Full queries