Dev.to Security 🔐 Cybersecurity 👁 0 📖 4 min read

One application, many Swedish municipalities: connecting their identity providers

If you build an application for Swedish municipalities, employees should be able to sign in with their existing municipal work identities. As you add customers, you will encounter different identity platforms, protocols

One application, many Swedish municipalities: connecting their identity providers

If you build an application for Swedish municipalities, employees should be able to sign in with their existing municipal work identities. As you add customers, you will encounter different identity platforms, protocols and claims.

The application can keep one login integration while the municipal connections are configured separately.

I am the founder of FoxIDs and have helped customers configure connections to Swedish municipalities. I use FoxIDs as the concrete example below.

One application connection, several municipal identity providers

Connect your application to FoxIDs using OpenID Connect. Configure each municipal identity provider as an authentication method and allow your application to use the relevant methods.

The application uses OpenID Connect even when a municipality uses SAML 2.0. FoxIDs handles the protocol connection on each side. A municipality can have a dedicated connection, while several municipalities using Microsoft Entra ID can share a multitenant connection.

One application connects to FoxIDs through OpenID Connect. Dedicated municipal identity providers use SAML 2.0, while a shared Microsoft Entra ID connection uses OpenID Connect.

The arrows show protocol connections, rather than the order of browser redirects.

Each application supplier configures its own municipal connections in its own FoxIDs setup, normally working directly with municipal IT. This is not a preconfigured federation of all Swedish municipalities.

SAML 2.0 first, OpenID Connect as an alternative

Most Swedish municipalities prefer SAML 2.0 for these connections. OpenID Connect is an alternative when the municipality offers it.

The following identity platforms cover most Swedish municipalities and have been verified with FoxIDs by customers:

  • MobilityGuard
  • F5 BIG-IP
  • Svensk e-identitet
  • PhenixID
  • Nexus Group
  • Microsoft Entra ID

Start with the municipality's IT team: which protocol do they offer, which claims can they supply, and who will configure their side? Knowing the platform helps, but the actual connection still needs to be agreed and configured.

Keep employee authentication with the municipality

The municipality's identity provider handles its MFA policy and the electronic identification methods it offers employees. These may include BankID, Freja+ (Freja eID+), Freja OrganisationsID or SITHS.

The municipality maps the authenticated person to the employee's identity and supplies the agreed claims through SAML 2.0 or OpenID Connect. For this setup, neither the application nor FoxIDs needs a direct integration with those electronic identification services.

Set up the first connection

Agree the identity and claims

Agree a stable user identifier and the attributes the application needs, such as name, email address and organisational information. Confirm which claim names and values the municipality supplies and how you will distinguish identities from different municipalities.

Your application must associate the authenticated user with the correct municipality and enforce access to that municipality's data.

Exchange metadata or client details

For SAML 2.0, configure the authentication method with the municipality's IdP metadata. Prefer its metadata URL when available, and ask municipal IT to use the metadata URL of your FoxIDs authentication method.

When both sides use metadata URLs and automatic metadata updates are enabled, renewed public signing certificates can be picked up through metadata. Exchanging a metadata file once does not provide this ongoing update mechanism.

For OpenID Connect, coordinate the client registration with municipal IT. Configure the authority and client details in FoxIDs, and provide the redirect URI shown for the authentication method.

The configuration steps are covered in the SAML 2.0 authentication method guide and the OpenID Connect authentication method guide.

Route users to the appropriate identity provider

Home Realm Discovery can select an authentication method using the user's email domain. A practical arrangement combines dedicated municipal connections with a shared Microsoft Entra ID connection.

For example, with fictional domains:

Email domain Authentication method Connection
municipality-a.example Municipality A SAML 2.0
municipality-b.example Municipality B SAML 2.0
* Shared Microsoft Entra ID OpenID Connect

Enter each municipality's domains on its dedicated authentication method. The shared method's HRD domain * provides the fallback for domains not configured on another method.

Allow the relevant authentication methods for the application and configure which Entra ID tenants you trust. See the multitenant Entra ID configuration and Home Realm Discovery guide.

The email domain entered during routing selects a login destination. It is not proof of identity or permission to access a municipality's data; those decisions must use the authenticated identity and the application's access rules.

If access should be controlled in FoxIDs

You can pre-create external users for the relevant authentication method using known email addresses. Require an existing external user and leave automatic user creation disabled.

Configure email as the redemption claim and a stable identifier as the link claim. At the first login, FoxIDs matches the email claim received from the municipality to the pre-created user and links it to the external identifier. Subsequent logins use the link value. Agree both claims with municipal IT; an email address should not be treated as a permanent identifier.

The external-user provisioning and redemption guide explains the setup. The application still enforces access to its functions and data.

Test the municipal login, then your application

Start with a test application in FoxIDs. Select Test authentication on the authentication method, then Start the test. After login, the test application displays the issued tokens and claims.

Share the test application's URL with municipal IT and selected users. A test account helps confirm the expected claims, while individual employees can check that they can sign in with their own accounts.

Then test your application: the user's municipality, the expected permissions and a user who should be denied access. If you use external users, include the first-login redemption and a subsequent login with the linked identity.

When the next municipality is added, the application's OpenID Connect integration remains the same. The work is in agreeing, configuring and testing that municipality's connection and access.

For the application side, start with the OpenID Connect application guide. The broader Swedish municipality integration article also includes examples of municipal login pages.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.