Add option to request activation of 2FA for service

[phavekes]

This issue is imported from pivotal - Originaly created at Nov 13, 2019 by Raoul Teeuwen

Add option on service detail to allow SCV to request activation of 2FA for his/her institution for an already connected service . When changed, a Jira ticket is generated (as with other change requests) so SURFconext team can check and execute request.

Add an extra \'SSID/2FA\'-icon/tab on service detail screen for this where it is shown what the LoA is, and where, like consent, you can request a higher LoA.

Also, when requesting connecting a service, we need an extra option to specify with what LoA the requester wants to connect the service.

To enable users to see what services are connected at what LoA policy, we want to replace the current SSID Yes/No filter with "SP - LoA2", "SP - LoA3", "IdP - LoA2", "IdP - LoA3" and "No".

A user should NOT be able to demote LoA level: at most, a ticket requesting lowering LoA can be created by request.

[phavekes]

@raoulteeuwen we can add an extra tab. Only visible when the service is connected. This however does not provide the SCV with an overview of all services where a custom LOA is set for his / her institution. Maybe add an extra filter? There is already a filter "SURFsecureID enabled" so we need to think about naming. There is of course also the my-institute page where the information about which services are configured with a LOA level higher then default also can be displayed / edited.

Maybe think some more on how / where to implement this? (Okke Harsta - Nov 15, 2019)

[phavekes]

Must not be possible to disable it automatically. Check whether user understands that they can enable it but not quickly disable it again. (Thijs Kinkhorst - Nov 27, 2019)

[phavekes]

Updated story based on dialog with Henny and based on input from Okke and Thijs (Raoul Teeuwen - Nov 27, 2019)

[phavekes]

Ticket to disable seems also risky. High chance that the student team will just do it. (Thijs Kinkhorst - Nov 27, 2019)

[phavekes]

Do you have a suggestion of what mechanism would provide enough \'comfort\'/security/friction for a request to decrease the LoA? The best (?) mechanism is to only allow someone authenticated as LoA level n to be able to decrease LoA level n to LoA level n-x (x>=0)? Do we need to refrain from offering the change-LoA-option until we have a situation where people can authenticate with LoA >1? (Raoul Teeuwen - Nov 28, 2019)

[phavekes]

My proposal would be: only display the SURF secure ID tab / icon option if the Service is not in the list of Services which already have a higher LOA level configured. This way no LoA demotion requests can be submitted. The SCV is already informed about the Loa settings in the Service overview and in case a demotion is really required, then the SCV has other means to contact SURF. With the new facet filter - see attachment - in place the SCV can easily see which Services are configured with a higher LoA for his / hers IdP and we can take this (agile;-) step for step. Main motivation for now is to raise awareness about SURF Secure ID and not to aim for total self service. (Okke Harsta - Nov 28, 2019)

[phavekes]

Making a service more secure can be considered routine. Making a service that was protected with 2FA no longer protected seems rare and always custom case. I\'d recommend some consultancy with the PM of SSID to ensure it\'s legitimate and that the consequences are fully understood before such a setting is removed. So not automate it. (Thijs Kinkhorst - Nov 28, 2019)

[phavekes]

Therefore we only allow promotion of a LoA level for a service and not making it less secure. @raoulteeuwen the new filter SURF secure ID filter is deployed on test2. Note that the IdP settings are part of the user login info - and as such are cached - and therefore not runtime updated. SP info is. Tomorrow I\'ll finish the request for LoA promotions. (Okke Harsta - Nov 28, 2019)

[phavekes]

@raoulteeuwen Implemented and deployed on test2. You can review the text changes in https://github.com/OpenConext/OpenConext-dashboard/blob/master/dashboard-gui/src/javascripts/locale/en.js#L348 and https://github.com/OpenConext/OpenConext-dashboard/blob/master/dashboard-gui/src/javascripts/locale/nl.js#L348 (Okke Harsta - Nov 29, 2019)