MSS
MSS copied to clipboard
Open-MSS
user/profile creation by SAML2 should not have a password
currently the token is used for the password in our database for a user created by a SAML2 account. Using a SAML2 authority we should speak from a profile creation connected to an authority.
We should not store a password at all and also indicate that the account is managed by the SAML2 authority. There should be never a password recovery over our system possible.
When the authority gets invalid (various cases possible) the user should not get into the system without help of an admin.
currently the token is used for the password in our database for a user created by a SAML2 account. Using a SAML2 authority we should speak from a profile creation connected to an authority.
We should not store a password at all and also indicate that the account is managed by the SAML2 authority. There should be never a password recovery over our system possible.
When the authority gets invalid (various cases possible) the user should not get into the system without help of an admin.
I trust your explanation regarding scenarios where a user logs into the system via SAML2 authority. However, my concern is this: if a user, who already exists and has transitioned to SAML2-based login, attempts to log in using password-based login again, wouldn't they need to go through a 'password recovery' process? This implies that once a user migrates to SAML2-based login, they will no longer be able to access password-based login. right ?
I think there should become an server Admin involved. We maybe need a change in a mscolab cli script to be used on the server for this case.
When we look from the point of the natural person there are just too many possibilities why it can go wrong.
- the user changed the facility.
- User changed name.
- saml2 cert was not renewed in time
In all cases we have to know that the user we have has now new data and won't use the old data.