Vaststellen bevoegdheid

In the paragraphs below is an example implementation of all the functionality which a MR must support, this is not the required implementation, other implementations are allowed as long as they deliver the same result.

Process to find applicable authorisation

1: Check LOA levels

1A: If the level of assurance is included in XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance

• • The LOA of the authentication means in the AD assertion MUST BE equal or greater than the LOA which is requested included in the XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance
  • The LOA which is included in the DC MUST BE equal or greater than the LOA which is requested included in the XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance.
  • The LOA of the Machtiging (machtigen) MUST be equal or greater than the LOA included in XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance.

1B: If the level of assurance is NOT included in XACMLAuthzDecisionQuery → request → Resource → Level of assurance.

• • Continue the process with the LOA which is specified in the Service Catalog.

2: Check ServiceUUID

2A: If the requested service is NOT a portal service:

• • The ServiceUUID at XACMLAuthzDecisionQuery → request → Resource → ServiceUUID MUST match the serviceUUID (of the ServiceDefinition) which is part of the Machtiging (machtigen).

3: Choose (Dienstafnemer)

3A Generate List of Dienstafnemers for which the user has Authorizations (Machtigingen)

3B Remove Authorizations that are for other DV

3B1 In case of a specific service request (ServiceID Index > 0): Remove the Dienstafnemers where the user does not have an Authorization for the requested Service.

3B2 In case of a Portaalfunctie request (ServiceID Index = 0): Remove the Dienstafnemers where the user does not have an Authorization for any service of the Dienstverlener

3C Filter based on ECTA

3C1 In case of a specific service request: Filter the Dienstafnemers where the available EntityConcernedTypes of a Dienstafnemer cannot fulfill any ECTA set of the requested service

3C2 In case of a Portaalfunctie request: Remove the Dienstafnemers from the list where the available EntityConcenedTypes of a Dienstafnemer cannot fulfill any ECTA set of any service of the Dienstverlener. Note: Here a Dienstverlener/Dienst combination can occur that later when filtering on Service Restriction turns out not to be usable.

3D Alternative flow: No Dienstafnemers

If the user does not have any authorizations left, the MR MUST inform the user and offer the option to cancel the login process (link to cancel flow)

3E Let user select the Dienstafnemer he wants to represent

Note: MR MAY skip this step is the user can represent exactly one (1) Dienstafnemer.

4. In case of a Chain authorization and multiple Intermediairy organizations, let user select the Intermediary organization.

5. Determine the list of services

5A if the request is for a portal service

5A1 create a list of all services of the DV

5B If the Dienstafnemer selected is a Location (the authorization is limited to a Location), remove the services that do not indicate that they can respect restricted authorizations.

Note that there is multiple negative logic here. If the service specifies ServiceRestriction=Vestigingnummer it indicates that it can handle restricted authorisations and unrestricted authorizations.

6. Alternative flow : no applicable services

If the user does not have any authorizations left (the services list is empty), the MR MUST inform the user and offer the option to cancel the login process (link to cancel flow).

7. Determine the LoA

7A If the request is for a specific service

Select the specific authorization of the highest LoA.

7B If the request is for a portal service, from the list of services take the lowest LoA of all authorizations.