SSID changes

This issue is imported from pivotal - Originaly created at May 12, 2021 by Raoul Teeuwen

At the moment, implementation of SSID features in the IdP dashboard is incomplete. This has been discussed at https://wiki.surfnet.nl/display/coininfra/SSID%2C+SURFconext+IdP+dashboard%2C+Manage . To fix this (ideally incorporated during the 2021 UI/UX redesign):

• Currently, IdPs can set a LoA for a connected SP. This only makes sense for institutions that have ordered SSID. To detect whether an IdP has ordered SSID, we can check whether the RA SP is connected to the IdP. Only if it is, we want to offer an IdP the option to set a LOA for an SP
• The IdP should not be able to set a LOA for the SSID RA SP (only SURF personnel should change those LOAs)
• When the user filters for services with SSID, show a text-box at the bottom of the result list with the text “The above list only includes services connected to SURFconext and are configured to use SSID for your institution. Maybe your institution also uses other MFA/2FA solutions and flows with services that are not listed here.”
• To include the “MFA-on-the-IdP” option SURFconext offers:
  o We want to add a facet filter under “SURFsecureID enabled”, “MFA on IdP”
  o Adding that filter makes the box title, “SURFsecureID enabled”, wrong. So change the title to “MFA/2FA”. Also, prefix all current SSID-filters with “SSID ”. So “IDP - loa2” becomes “SSID IDP - loa2” etc. Btw: afaik, the right way of writing IdP is IdP, not IDP
  o The current pop-up I help says “SURFsecureID second factor authentication is required.” > change to “Filter on several multi-/2-factor options.”

Start in the dashboard UI by locating the SSID filters, the IdP LOA controls, the SSID result-list message, and the existing “SURFsecureID enabled” help text. Review the linked SSID requirements and trace how connected services and RA SP access are determined. Done means the requested LOA restrictions, filters, labels, explanatory text, and MFA/2FA wording all appear correctly.