Skip to content

ID-porten

Status: Opt-In Open Beta

This feature is only available in the Google Cloud Platform (GCP) clusters.

Abstract

ID-porten is a common log-in system used for logging into Norwegian public e-services for citizens.

The NAIS platform provides support for simple, declarative provisioning of an ID-porten client with sensible defaults that your application may use to integrate with ID-porten.

An ID-porten client allows your application to leverage ID-porten for authentication of citizen end-users, providing sign-in capabilities with single sign-on (SSO). To achieve this, your application must implement OpenID Connect with the Authorization Code flow.

This is also a critical first step in request chains involving an end-user whose identity and permissions should be propagated through each service/web API when accessing services in NAV using the OAuth 2.0 Token Exchange protocol. See the TokenX documentation for details.

Info

See the NAV Security Guide for NAV-specific usage of this client.

Refer to the ID-porten Integration guide for further details.

Configuration

apiVersion: "nais.io/v1alpha1"
kind: "Application"
metadata:
  name: nais-testapp
  namespace: aura
  labels:
    team: aura
spec:
  image: navikt/nais-testapp:66.0.0
  idporten:
    enabled: true
apiVersion: "nais.io/v1alpha1"
kind: "Application"
metadata:
  name: nais-testapp
  namespace: aura
  labels:
    team: aura
spec:
  image: navikt/nais-testapp:66.0.0
  idporten:
    enabled: true
    clientURI: "https://nav.no"
    redirectURI: "https://my.application.dev.nav.no/callback"
    frontchannelLogoutURI: "https://my.application.dev.nav.no/logout"
    postLogoutRedirectURIs:
      - "https://nav.no"
    accessTokenLifetime: 3600 # in seconds - 1 hour
    sessionLifetime: 7200 # in seconds - 2 hours
  ingresses:
    - "https://my.application.dev.nav.no"

Spec

See the NAIS manifest.

Access Policies

The following outbound external hosts are automatically added when enabling this feature:

  • oidc-ver2.difi.no in development
  • oidc.difi.no in production

You do not need to specify these explicitly.

Ingresses

Danger

For security reasons you may only specify one ingress when this feature is enabled.

The ingress specified will by default generate a redirect URL using the formula:

spec.ingresses[0] + "/oauth2/callback"

In other words, this:

spec:
  idporten:
    enabled: true
  ingresses:
    - "https://my.application.dev.nav.no"

will generate a spec equivalent to this:

spec:
  idporten:
    enabled: true
    redirectURI: "https://my.application.dev.nav.no/oauth2/callback"
  ingresses:
    - "https://my.application.dev.nav.no"

Redirect URI

If you wish to use a different path than the auto-generated one, you may do so by manually specifying spec.idporten.redirectURI.

Warning

Specifying spec.idporten.redirectURI will replace the auto-generated redirect URI.

The redirect URI must adhere to the following rules:

  • It must start with https://.
  • It must be a path within your ingress.

For example, if you have specified an ingress at https://my.application.dev.nav.no, then:

  • https://my.application.dev.nav.no/some/path is valid
  • http://localhost/some/path is invalid

Usage

Info

See the NAV Security Guide for NAV-specific usage.

Runtime Variables & Credentials

The following environment variables and files (under the directory /var/run/secrets/nais.io/idporten) are available at runtime:

Name Values
IDPORTEN_CLIENT_ID e89006c5-7193-4ca3-8e26-d0990d9d981f
IDPORTEN_REDIRECT_URI https://my.application.dev.nav.no/callback
IDPORTEN_WELL_KNOWN_URL https://oidc-ver2.difi.no/idporten-oidc-provider/.well-known/openid-configuration
{
  "use": "sig",
  "kty": "RSA",
  "kid": "jXDxKRE6a4jogcc4HgkDq3uVgQ0",
  "alg": "RS256",
  "n": "xQ3chFsz...",
  "e": "AQAB",
  "d": "C0BVXQFQ...",
  "p": "9TGEF_Vk...",
  "q": "zb0yTkgqO...",
  "dp": "7YcKcCtJ...",
  "dq": "sXxLHp9A...",
  "qi": "QCW5VQjO..."
}

Test Users for Logins

ID-porten maintains a public list of test users found here.

Internals

This section is intended for readers interested in the inner workings of this feature.

Provisioning is handled by Digdirator - a Kubernetes operator that watches a custom resource (called IDPortenClient) that we've defined in our clusters.

Digdirator generates a Kubernetes Secret containing the values needed for your application to integrate with ID-porten, e.g. credentials and URLs. This secret will be mounted to the pods of your application during deploy.

Every deploy will trigger rotation of credentials, invalidating any credentials that are not in use. In use in this context refers to all credentials that are currently mounted to an existing pod - regardless of their status (Running, CrashLoopBackOff, etc.). In other words, credential rotation should happen with zero downtime.

More details in the Digdirator repository.