LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Delegation configuration
  • Switching delegations
  • Delegated tokens
  • Delegation types
  • Audit Requirements

Was this helpful?

  1. Products
  2. Island.is Authentication Service

Delegations

PreviousScopes and TokensNextConfiguration

Last updated 5 months ago

Was this helpful?

IAS includes a delegation system which allows individuals and organisations to grant others access to digital services on their behalf. For example, guardians can sign in on behalf of their wards, and employees can sign in on behalf of the company they work for.

In addition to explicit delegation grants (where identity A creates delegation grants for user B), we support implicit delegation grants from external delegation registries. We currently support these kinds of implicit delegations:

  • Legal guardians for underage users. (Source: Þjóðskrá)

  • Procuring holders for companies. (Source: Fyrirtækjaskrá)

  • Personal representatives for represented users. (Source: Talsmannagrunnur)

Delegation configuration

Clients can configure what kinds of delegations they support. This controls which delegations the user can choose when authenticating with the client.

Scopes configure what kind of delegations the respective API supports. It affects which API scopes can be added to access tokens when acting in a delegation.

Switching delegations

When a user signs into a client which supports delegations, IAS prompts the user with a choice to authenticate without a delegation, or authenticate with a specific delegation.

Delegated tokens

Delegations are reflected in the ID and Access Tokens, where the chosen identity becomes the subject of the token and the authenticated user is the actor.

Example Access Token for a delegation (trimmed):

This design reduces the information shared with the client. The client only sees the delegations which the user chooses.

It also means resource servers can easily validate access tokens and return resources for the chosen delegation.

To prevent impersonation attacks, resource servers MUST validate the scope claims. If they support delegations they SHOULD also audit both identities from the token.

Delegation types

The delegationType property in the ID and Access tokens indicates what kind of delegation the token represents. It is an array of strings, as delegation can be merged. For example a legal guardian can also have a custom delegation from its child. The property can contain the following values:

  • LegalGuardian - Legal guardian of a underage user based on National Registry.

  • ProcuringHolder - Procuring holder of a company based on Company Registry.

  • PersonalRepresentative - Personal representative of a represented person based on Félags- og vinnumarkaðsráðuneytið.

  • Custom - Explicit delegation created by the user in island.is delegation system.

Audit Requirements

SPs which integrate with delegations SHOULD keep an audit log which tracks both subject and actor identities.

We RECOMMEND including these fields in your audit log:

  • subject - The national id of the active identity from the access token. Can be the authenticated user, a company or another person. This can be national_id claim.

  • actor - The national id of the authenticated user. This is the actor.national_id claim if the actor claim is defined, otherwise it is the root national_id claim, same as the subject.

  • client - IAS clients involved with the request. This SHOULD be an array to audit a chain of clients using token exchange.