Suomi.fi e-Identification: Frequently asked questions
This page contains FAQs related to the Suomi.fi e-Identification. You will also receive support from the activation support of Suomi.fi e-Identification.
Schedule for production environment metadata installations
- Apply for the access licence well in advance.
- All changes must be submitted no later than Sunday of the previous week. All metadata submitted after this date will be included in the following week’s installation.
- Dynamic metadata of the production environment is checked early in the week.
- Metadata production installation is carried out on Wednesdays at 9.00.
No extra metadata installations are carried out.
Test environment metadata is checked and taken to the test environment each weekday between 13.00 and 16.00.
Public holidays and holiday periods affect the metadata installation schedules.
Read more at Schedule for metadata installations.
We recommend that you use the metafile template found here and complete the details of the environment you want to register in the template.
- If you receive an error message, we recommend that you check the following:
- the metafile is valid XML
- the entityID is configured
- the contact person’s first name, last name and email address are specified
- the email addresses are in the right format the environment name is defined in three languages (DisplayName elements)
- the certificate is valid and in PEM format
- the return address of the identification response has been specified.
This can be due to a number of issues. We recommend that you check the following:
- the request is valid XML
- the entityID of the identification request is the same as in the environment metadata. Note that the entityID is case-sensitive.
- the secret key used to sign the request matches the certificate specified in the environment metadata.
- there is no discrepancy in the request timestamp and your server clocks have been synchronized.
It is recommended that you check the following issues:
- The identification response return address is set correctly in the environment metadata (AssertionConsumerService element).
- Check that the return address and HTTP method are correct (GET/POST).
- The secret key used for decryption matches the certificate specified in the environment metadata.
Contact information is managed through environment metadata. Identify yourself using strong identification in Suomi.fi Service Management, download the current metadata to your computer, make the necessary changes and update the environment. For more detailed instructions on updating metadata, see here.
SAML certificates used by the e-service are managed through environment metadata. Please note that changing the certificate also requires actions in your e-service. For more detailed instructions on changing certificates, see here.
If these kinds of checks need to be made more frequently, the Digital and Population Data Services Agency provides a change information service through which it is also possible to obtain information on changes in personal identity codes. You can find additional information about the service hereOpens in a new window..
A person whose personal identity code has changed can obtain an extract from the Population Information System, which shows the new and old personal identity code and can be used to prove the change in the personal identity code. In other words, if this is an individual case, you could ask for this extract from the person concerned if you want a confirmation of the change of personal identity code.
It is not possible to remove the environment itself from Suomi.fi Service Management. Log into Suomi.fi Service ManagementOpens in a new window. (check the third page of the report) to ensure that the environment no longer receives successful identifications and request that the environment be removed from activation support at the address tunnistus-kayttoonotot@dvv.fi.
If there is an error in the configuration between the e-service and Suomi.fi authentication, the authentication will end up on an error page. The error code (&m=X) in the error page URL indicates the nature of the error. The table below lists the codes and their explanations:
back | Browser back button was used. |
|---|---|
3 | EndpointResolutionFailed event happens when the check between the AssertionConsumerServiceURL in an SP's request is not in the SP's metadata, so the IdP fails the request in accordance with the standard's requirement to validate the response location. |
5 | InvalidProfileConfiguration in Shibboleth usually means that the profile you’re trying to run (like SAML2/SSO, SAML2/POST, AttributeResolution, etc.) is misconfigured or missing required elements. This is Shibboleth’s way of saying “I can’t execute this profile because the configuration isn’t valid.” |
7 | A MessageAuthenticationError in Shibboleth usually points to a problem with SAML message integrity or trust validation. In other words, the IdP or SP received a SAML message (AuthnRequest, Response, LogoutRequest, etc.) that it could not verify or trust. |
8 | A MessageReplay error in Shibboleth means that a SAML message (AuthnRequest, Response, LogoutRequest, etc.) was received more than once with the same ID value. Shibboleth protects against replay attacks by keeping a short-term cache of message IDs, so if it sees the same message twice, it throws MessageReplay. |
9 | A MessageExpired error in Shibboleth means that the SAML message (AuthnRequest, Response, LogoutRequest, etc.) was received outside its validity window — basically, the IssueInstant, NotBefore, or NotOnOrAfter timestamps no longer allow it to be trusted. |
10 | A UnableToDecode error in Shibboleth means the IdP (or SP) received a SAML message but couldn’t parse or decode it into valid XML. Basically, the message transport layer worked, but the content wasn’t valid SAML. One possible reason is that a POST message was sent to a redirect endpoint. |
43 | The NoSuchFlowExecutionException means the IdP got a request that references a flow execution key (the state of a login/authentication flow), but the IdP couldn’t find it anymore. In plain terms: “That login session/flow is gone.” |
44 | A FlowExecutionRestorationFailureException happens when the IdP tries to restore an existing flow execution (login session), but the state is either missing, corrupted, or incompatible. |