Authentication model

In this section, we describe the authentication model in the Flexibility Information System. This diagram shows the main concepts in the model and how they relate to each other.

../diagrams/auth_model.drawio.png

Identity

Any system or person interacting with the Flexibility Information System will always be authenticated as a legal og natural entity, possibly assuming the role of a market party. An entity might also interact with the FIS via a client (i.e., an application or system). The entity, party and client together make up the identity of the user.

The entity has very little functionality available in the system, most functionality will be available after assuming a party. The identity of the user is then the combination of the entity and the party they are acting as. As a result, in order to interact properly with the Flexibility Information System, an entity must assume a party.

Inspiration for this step is taken from Altinn, where one is presented with a list of parties upon login. The Elhub portal also has the same type of logical mechanism.

Altinn select party .

The concept is also inspired by AWS AssumeRole.

Assuming a party is done using Token Exchange or directly in authentication using JWT Bearer grant. To assume a party, the entity must be a member of the party.

Entity - individuals and organisations

The entity is the natural or legal person using the system. This is the "raw" identity of the user when it enters the system.

Natural entities are individuals identified by their national identity number (fødselsnummer) or D-number.
Legal entities are organisations identified by their organisation number (organisasjonsnummer).

In a production setting, the identity of the entity will be established through mechanisms such as IDPorten, Maskinporten or enterprise certificates.

Client - application or system

We follow the OAuth 2.0 definition of a client as "an application making protected resource requests". A client is basically a way for an entity to interact with the FIS API. A client can use different authentication methods. A client is restricted to a specific party and with assigned scopes.

Party - market actors

This is the market party like a system operator or service provider. Parties in the European energy sector are typically identified by a GLN or EIC-X. After being authenticated as an entity, the user can assume a party to interact with the system.

We have two extra party types in addition to the other market actors: end users and organisations. An end user is either a person or an organisation. The organisation party is a way for the user to have access to a special role to perform modifications on their own organisation entity. They can for instance give total or partial (via delegation mechanisms) access to what the entity owns and manages, to people from the same company.

We have the following party types in the Flexibility Information System:

Abbreviation	Code	Name	Norwegian name
BRP	balance_responsible_party	Balance Responsible Party	Balanseansvarlig
EU	end_user	End User	Sluttbruker
ES	energy_supplier	Energy Supplier	Kraftleverandør
FISO	flexibility_information_system_operator	Flexibility Information System Operator	Fleksibilitetsinformasjonssystem Operatør
ORG	organisation	Organisation	Organisasjon
SO	system_operator	System Operator	Systemoperatør
SP	service_provider	Service Provider	Tjenesteleverandør
TP	third_party	Third Party	Tredjepart

Common policies

In addition to these we also write policies and grant access that are common for all authenticated party types. This is referred to as Common, abbreviated as COM. All party types inherit the policies from Common.

The following sub-sections provides a brief description of each party type.

Balance Responsible Party

A party responsible for its imbalances.

Based on: Consolidated text: Commission Regulation (EU) 2017/2195 - Art.2 Definitions.

End User

Synonyms:

Final Customer (Sluttkunde)
Flexible Customer
System User

The entity at the lower end of the chain, willing to make their own technical resources available on the flexibility market.

Energy Supplier

Synonyms:

Balance Supplier
Supplier

A party delivering to or taking energy from a party connected to the grid at an accounting point.

Flexibility Information System Operator

Synonyms:

Flexibility Register Operator

We use this as an administrator role for the Flexibility Information System, as a last resort tool to have full authorisation on the system or perform special operations.

Organisation

This is not a market party as such but a party that represents the organisation entity.

System Operator

Synonyms:

Grid Owner

Sub-types:

Distribution System Operator
Transmission System Operator
Connecting System Operator
Requesting System Operator
Procuring System Operator
Impacted System Operator

A party responsible for operating, ensuring the maintenance of and, if necessary, developing the system in a given area and, where applicable, its interconnections with other systems, and for ensuring the long-term ability of the system to meet reasonable demands for the distribution or transmission of energy.

Based on: Consolidated text: Directive (EU) 2019/944.

Service Provider

Sub-types:

Balancing Service Provider
Flexibility Service Provider

A party that offers local or balancing services to other parties in the market, after having successfully passed a qualification process.

Third Party

A party that does not have an actual responsibility in the value chain, but can be delegated authority to, e.g., perform tasks or access data.

One prominent example is a third party market operator, e.g. NODES.

Roles

Parties in the Energy sector act in different "roles". For some examples, see the Elhub role model. This level is mostly used for delegation. As of now, this level is NOT part of the authentication or authorization model.

The word 'role' can be seen in the system

Our database and API service does sometime refer to something called "roles". This is just how we model parties and entities in the system and is not related to the conceptual authentication or authorization model as described here.

Anonymous users

Some data (like party lists) and actions (such as login) will be available for un-authenticated users. We refer to these as Anonymous, abbreviated as ANON.

An anonymous user has the following default scopes:

read:data - to be able to access open data (if any)
use:auth - to be able to log in etc

Policy inheritance

RLA policies for Anonymous/ANON are inherited by all authenticated users.