Authentik and social login

There are cases where an identity provider already exists, maybe built with keycloak, but its maintainers are beastly enough to refuse to make customizations for your applications: for example, they might have the brilliant idea of using preferred_username as the identification key and having it identical to the fiscal code or VAT ID (if we want to sound fancy), or they might decide to pass the name, the family_name, but not both together. This questionable behavior is quite terrible: what to do? Simple, you take our Authentik, federate it with the managed identity provider (which even my dog could set up better), and at that point, you act directly on the fields that our PC (politically correct) IDP provides. The highly technical schema is the following:

subCaneCloak [preferred_username, name, family_name]--> IdP_PC --> [manipulated_preferred_username, full_name (composed by manipulating name_family_name)]

Manipulations are extremely simple in Authentik because they can be achieved by using the Python language on the retrieved data.

Step 1: St. Francis talks to the animals

After putting on the cloak of St. Francis, you can interact with the sub-species in charge of managing the subCaneCloak, requesting Confidential access.

Pros:

• there is initial hassle equal to zero
• from this moment on, applications using your PC Authentik get valid credentials directly from the upstream IdP

Cons:

• I'll let you know as soon as I find one

At this point, let's go to our IdP.

Step 2: Configuring social login

Once you enter the admin interface, look intensely at the left menu: Directory --> Federation and Social Logins and create a new entry of type OAuth OpenID Source and fill it in properly:

• Name: subCaneCloak
• Slug: subcanecloak
• User matching mode: Link users on a unique identifier
• Group matching mode: Link users on a unique identifier
• User path: %(slug)s <-- This is where it creates the directory tree. You will find users under Directory --> Users --> dedicated section (in our case subCaneCloak)
• Protocol settings: here we slam the client_id and the secret provided by the beasts
• Scopes: profile openid email
• URL settings: these parameters must be filled with what is provided by the aforementioned simpletons
• PKCE Method: None
• Authorization code authentication flow: HTTP_BASIC

Now here's the catch: if we leave it like this, everything works, BUT we are not doing any manipulation on the fields. If we want to do that, we should proceed with... Warning: let's leave this window in standby, or complete it: but in Step 4 we will have to return to this to modify it.

Step 3: customizing fields: property mapping

We want a mapping such that when a user logs in via OAuth, their profile on Authentik is created with a correctly formatted full name (e.g., "Mario Rossi"), regardless of how the data arrives from the source. Without this mapping, Authentik might import names exactly as passed by the provider, risking a messy user list (e.g., some entirely in lowercase, others with only the first name and no last name). How to do it?

Look very, very intensely, Chuck Norris style and beyond (without kicking things to pieces), at the left menu: Customization --> Property Mappings --> Create and create a new OAuth Source Property Mapping and name it whatever we like:

• Name: subCaneCloak-mapping
• Expression:

given_name = info.get("given_name", "")
family_name = info.get("family_name", "")

return {
    "username": info.get("preferred_username"),
    "email": info.get("email"),
    # .title() converts "MARIO" -> "Mario" and "ROSSI" -> "Rossi"
    "name": f"{given_name.title()} {family_name.title()}".strip()
}

info.get() is the function that tells Authentik to extract fields from what is received from the upstream.

Step 4: modifying social login

Let's pick up where we left off in Step 3 (or if we completed it, go back to Directory --> Federation and Social Logins and edit it). Scroll down to OAuth attribute mappings and for both User Property Mappings and Group Property Mappings choose the mapping we just created. That's it.

Step 5: enabling social login

We have created the social login, but it is not active yet. To make it take effect, it must be associated with the login stage. So, to start with, let's figure out where that happens.

From the left menu: System --> Brands. Edit authentik-default and scroll down to the Default Flows section and check what is set as the Authentication flow: if you haven't made changes, it will be default-authentication-flow (Welcome to authentik!). Exit this screen and go to Flows and Stages --> Flows and edit the one we just saw, which is default-authentication-flow (Welcome to authentik!). In the Source settings section, move the social login created earlier into the Selected sources column and update. Now social login will be active.

[May the big mole be with you]

[EOF]

Discussion & Support

Discussion and support channel. To discuss configurations or other topics, join us on fluxer.dreadful.work.