Feature: Add 'Email' and 'Username' to application's registration fields

[gmpreussner]

Add 'Username' to registration fields

Problem

I have some applications that require an email address for registration, others require a username. There is also one (Tuleap) that doesn't work without providing both email and username. Currently, FusionAuth requires only one or the other via the 'Login Type' Self Service Registration settings.

Solution

Add 'Email' and 'Username' to the 'Registration fields'. If enabled, for login type 'Email' it should also show a 'Username' field, and for login type 'Username' it should also show an 'Email' field. If the external IdP does not provide a value for either one, the UI should request these values from the user. The values should then be forwarded to the application via the 'email' and/or 'profile' scopes.

Alternatives/workarounds

I have not tried this yet, but I think a viable workaround would be to:

1. Set login type to 'Email'
2. Require 'Full Name', or 'First / Middle / Last Name'
3. Use an 'Id Token Populate' lambda to derive a username from the real name
4. Inject the username into the JWT response

The downside of this is that the user may not be able to change the username later to the preferred value, unless the application allows for overriding it (some do).

Additional context

I have both self-registration in FusionAuth and registration via external IdP enabled. I'm using FusionAuth as the only registration/login method for my applications.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[gmpreussner]

After playing around with lambdas and testing it with some of my friends, I think that the "username Derivation from first/last name" workaround is not going to work. The problem is that there is no mechanism to guarantee a unique username - if two users end up generating the same username (but using a different email address), FusionAuth will pass, but the target applications requiring unique usernames will fail.

The email address could be used to generate a unique username, i.e. joe.schmo@example.com turns into joe.schmoe.example.com or something like that, but that makes for very ugly usernames that almost certainly nobody wants.

So, I think that having the ability to require both username and email upon registration - and enforcing their uniqueness within the FusionAuth user database - is going to be a mandatory feature.

[robotdan]

This may be the same workaround you're describing, but did you try this?

One “hack” - may be to set the self service registration to username, but instruct the users to enter either their email or username depending upon the application. I think this should work - the only downside is that FusionAuth won’t know this username is sometimes and email address, so we won’t be able to send an email to the user for example.

This would not be using the first / last name, but instead always using the username field for either email or username.

Regarding the longer term fix here - I don't have an ETA, but we'll get this into the schedule assuming we do not uncover any technical reasons why this couldn't work.

[gmpreussner]

Thanks @robotdan, I have not tried to use your suggested workaround. I think it's not workable in the general case, because the application may not allow non-alphanumeric characters in the user name. I know that some of my apps will not allow @ in usernames, for example, although they will allow .

[gmpreussner]

@robotdan I've thought about this some more, and I think that this feature needs further consideration. Having the option to configure the username as a required field and giving the user the opportunity to specify one if the external IdP doesn't provide one seems useful.

However, it doesn't actually solve the underlying problem that I'm really trying to solve, which is Single Sign-On. OAuth really only handles authentication, and while OpenID could, in principle, be used for SSO, most applications haven't actually been designed for that use case. For example, most of my apps allow usernames and/or email address to be modified after registration, even if OpenID is configured as the sole authentication source. As a result, FusionAuth cannot guarantee the integrity of authenticated user accounts across multiple independent applications.

I'm starting to think that I might need a different back-end altogether, i.e. LDAP.

[robotdan]

For example, most of my apps allow usernames and/or email address to be modified after registration, even if OpenID is configured as the sole authentication source.

I think this still fits nicely with how FusionAuth thinks about usernames and email addresses. I'm not sure if I completely understand what isn't working for you yet.

The self service registration is only a convenience option, you can always use your own registration form and call the Registration APIs directly.

Let's assume you build your own registration form, and collect whatever you need for a particular applications requirements and then call the FusionAuth Registration API. In this scenario, you could specify the username, email address or both if you like. Either of these unique values can be used to authenticate with FusionAuth.

For example, most of my apps allow usernames and/or email address to be modified after registration

This is supported in FusionAuth.

As a result, FusionAuth cannot guarantee the integrity of authenticated user accounts across multiple independent applications.

Can you expand on this a bit further, not sure I follow. Are you saying that in one application a username is bob and in another application the username is fred but these are the same user?

I'm starting to think that I might need a different back-end altogether, i.e. LDAP.

Could be, FusionAuth won't be a perfect fit for everyone. I don't know what LDAP would bring to the table that would make it a better fit in this case.

[gmpreussner]

The self service registration is only a convenience option, you can always use your own registration form and call the Registration APIs directly.

This is a great suggestion that I have not considered. I think this will solve my problem, and it will also integrate nicely with the rest of my web applications (I can redirect to a page on the homepage itself, using the same theme, branding, etc.).

Can you expand on this a bit further, not sure I follow

Sorry for the confusion. I was gobbling together two things, namely identity management (with the goal to keep all users and their associated application specific data in a single centralized database) and authentication (with the goal to provide single sign-on via a centralized authentication system). I did not fully understand in the beginning that these two aspects are really orthogonal.

I don't know what LDAP would bring to the table that would make it a better fit in this case

In the past couple days, I set up an LDAP database (via FreeIPA) with Keycloak on top just to get a better understand of what the capabilities and use cases are. One of my apps can use LDAP as the low-level user data storage, which is quite nice, but most apps integrate with LDAP only for authentication at best, and SAML or OpenID would be just as good. So you're right that a central LDAP database offers little benefits in my use case.

I'm going to further explore app-specific identity management with FusionAuth based single sign-on and registration via a custom web page.

Anyway, to close the loop on this issue, I think it would still be useful for FusionAuth to have the ability to require an email address field in username based authentication and vice versa.

[gmpreussner]

So, the solution was actually quite simple: I modified the existing Registration template in FusionAuth's UI settings to always render both email and username input boxes and set the login type to Email. It turns out that FusionAuth - intentionally or not - is already enforcing uniqueness on both fields, and it is also storing both values in the database.

[robotdan]

Thanks for the update @gmpreussner

It turns out that FusionAuth - intentionally or not - is already enforcing uniqueness on both fields, and it is also storing both values in the database.

Yes, FusionAuth allows a username or email address to be used during authentication. Because either may be used for authentication, they must be unique. I apologize if this was not clear from my earlier responses.

Anyway, to close the loop on this issue, I think it would still be useful for FusionAuth to have the ability to require an email address field in username based authentication and vice versa.

Agreed - I think the enhancement will be to be able to select email, username or "either" in the self service registration configuration. When selecting "either" both fields will be displayed and one of the two will be required, both will be guaranteed to be unique (this is the case today).

Does that sound good?

[gmpreussner]

Yep, that sounds great, thanks!

[pentatonicfunk]

So, the solution was actually quite simple: I modified the existing Registration template in FusionAuth's UI settings to always render both email and username input boxes and set the login type to Email. It turns out that FusionAuth - intentionally or not - is already enforcing uniqueness on both fields, and it is also storing both values in the database.

But its only one of them that marked as "required" you can register either without email or without password

[glen-84]

I think the user above meant "without email or without username" (not password).

I'm reproducing the same issue – when you add an email field while using usernames, then email is not required, even if the field is marked as required in the Form Fields section. Vice versa is likely also true.

@robotdan This seems like a bug?

Edit: I suppose this is because Form Fields is related to Advanced Registration Forms, and not used for Basic Forms. Would it be possible to add Username and Email to the Basic forms?

PS. I also expected that adding required=true to the input helper would output a required attribute in the HTML.

[robotdan]

If you think you have found a bug, please open a new GH issue so we can review it.

[glen-84]

As I mentioned in my edit, I think it was just a misunderstanding on my part. It seems Username and Email (together) are not available in Basic Forms.

[kasir-barati]

Hey guys,

JFI: based on my experience with FusionAuth you can specify both username and email in registration bu cannot update them, read this FusionAuth forum Q&A post.