"Invite" users to tenant via email without password
-
This is a carryover from this issue: https://github.com/FusionAuth/fusionauth-issues/issues/484
The end use case I'd want is:
Add a user to the tenant with an email or username (depending on linking strategy)
Add user to a group
Add registration for user to the various applications (is there a way to do this via the Group > mechanism above?)This way when the user first logs in, they have access to the systems they need.
We do not want self registration, and self registration requires them adding a password which we do not want (no way to create a form without a password that I've seen so far).Thanks for clarifying your end use case.
You should be able to do this via a provisioning script:
add a user to a tenant with an email or username (depending on linking strategy) with a random password that they never need to know
add the user to a group
add a registration to the user for particular applications
When you present the login form link to the user, specify an idp_hint so they are never shown the password field. In fact, you could edit the theme to remove the login id and password fields as well.
You can not specify a registration via a group, only a role to be assigned after registration.Hope that helps. This has moved away from the issue and is probably more of a forum topic at this point. If you have additional feedback, let's discuss on the forum (feel free to paste a topic link here).
So this kind of works. But starts to be less than ideal as we make the use case extend to the full one:
The tenant is a mix of IdP and UN/PW users. Therefore, removing the prompt for all users won't work, but if we had a 100% IdP tenant, I can see the benefit of that and idp_hint.
When a user uses the self edit page from Fusion Auth they would be able to "change" this password, but since they don't know the original it would just be broken functionality. Is there a way to suppress this on the self editor page and/or detect that the user was an IdP managed user? We want to use that to allow them to enable MFA and (for users with passwords) change their password.
This is less of a concern with our internal employees (we can train them to avoid this part of the profile editor). But if we start to link 3rd party IdP to the system for our customers it may become a source of support issues ("why can't I change my password here?").
-
and/or detect that the user was an IdP managed user?
In the reconcile lambda from the IdP (here's the docs for the OIDC lambda), you can set whatever data you want on the
user.data
field, so you could setuser.data.idpUser = true
. Then you can access that value from the self edit page freemarker template and decide to show or hide the password field.I get that this isn't as straightforward as it would be if the original feature request was implemented . But I think there's a path forward here that doesn't wait on that.