After login at a service the service (SP) may be missing some information or requirements of the login, for example
- To few attributes sent from the IdP
- Assurance level is too low, expected SWAMID Assurance Level 2 (confirmed identity) but user has SWAMID Assurance Level 1 (non-confirmed identity)
- The service requires MFA capability of the IdP (SWAMID Person-Proofed Multi-Factor) but not supported by IdP (according to IdP Metadata)
- The IdP doesn't seem to support the forceAuthn SAML flag (either a SAML error from the errorURL or the AuthenticationInstant is not refreshed
There currently is no best-practice for how a service should inform users of non-technical shortcomings of logins. It would be convinient if IdP:s could supply url:s to different support pages that services could referer to depending on pre-defined problems with logins. Many login problems are not detected until after login.
If the IdP:s provided support URL:s for different types of login shortcomings the services could point users to the correct information on a per-IdP basis we could have this scenario:
- A user logins to the Swedish student documentation system, Ladok, using the UmU IdP
- Ladok detects that the user is logged in at SWAMID Assurance Level 1, Ladok is configured to require SWAMID Assurance Level 2 for login to the UmU part of Ladok
- Ladok displays information that users of the UmU part of Ladok requires users to be confirmed (SWAMID Assurance Level 2) but that the user logged in with a non-confirmed account (SWAMID Assurance Level 1), and that the user should go to www.support.umu.se/faq/confirmed-user-required.html to get UmU-specific information on confirmed user accounts. At that URL, UmU can publish UmU-specific information regarding confirmation of accounts. For example that the user needs to visit the Service Desk of UmU and provide their driving license to get their account confirmed.
These information URL:s could be configured internal in Ladok for every IdP, but then the URL:s have to be duplicated in each service and every service needs to implement their own logic and handling of different type of login shortcomings.
Proposed technical solution in federation IdP Metadata
A solution of the problem could be to define a number of error codes and add links to different information URL:s in the metadata of the IdP:s. That way the URL:s will be stored in a single place and the services can get the information URL:s from the user's IdP:s and then, where possible, link users to their own IdP:s information URL:s for different login shortcomings.
An already available Metadata attribute that could be used for this is the errorURL attribute:
An IdP’s metadata MUST include the errorURL attribute on its <md:IDPSSODescriptor> element. The content of the errorURL attribute MUST be an https URL resolving to an HTML page.
The errorURL HTML page should be suitable for referral by SPs if they receive insufficient attributes from the IdP to successfully authenticate or authorize the user’s access. The page should provide information targeted at the end user explaining how to contact the operator of the IdP to request addition of the necessary attributes to the assertions.
If a successful authentication response lacks sufficient or appropriate SAML Attributes (including subject identifiers) for successful SP operation, the SP MUST display a meaningful status message to the user. This message MUST direct the user to appropriate support resources offered by the SP or, alternatively, to the errorURL attribute in an IdP’s metadata.
There are many reasons an SP may be unable or choose not to provide service to a user based on an given authentication response. IdPs failing to release the necessary SAML Attributes is the most prevalent interoperability issue encountered in larger, general purpose federations, which is why this scenario is singled out here.
errorURL is added in the IDPSSODescriptor tag, for example:
Since services often know what the problem with the login is, the syntax of the URL could include a tag that the service, if applicable, could replace with some specific pre-defined problem-ID known to the IdP:s. That way, the information could be more accurate with the problem the user has to resolve. For example, make the tag SWAMID-SP-ERROR replacable in the URL:
The IdP should have a complete information page at the specified errorURL if the service does not have support to replace the tag depending on the login error. The IdP should also have an information page for all known tag values, or a fallback in case of unknown tag values.
Example of errorURL:s following this pattern, with different methods of dynamic information tagging.
For example, in the scenario above, the user would be redirected to https://www.servicedesk.umu.se/faq/idp-error.php?error=AL2-REQUIRED allowing the IdP to give the user instructions on how to get his or her account confirmed at the UmU IDP.
For other services that have not implemented the tagged errorURL method, they can still send the user to the general https://www.servicedesk.umu.se/faq/idp-error.php?error=SWAMID-SP-ERROR URL.
In the examples above, BTH has not implemented the tagged errorURL and services should redirect users to https://www.bth.se/login-problems.html for all login errors.