Identityserver4: Add registration workflow for ASP.NET sample UI

[brockallen]

We would like a UI for self-registration and it would need to be in a separate feature folder different from the "Account" (or any of the others).

If you're interesting in helping/contributing this feature, please contact us first.

[Harmindersingh05]

Hey Brock, I am interested in implementing this feature as I am in need of this as well.

Following is the current workflow of my application. Let me know if this was something you'd like for Sample UI. Any changes are most welcome.

Workflow:
Registeration will occur from the login page using a new button called "register".

1: When the register button is clicked by the user. The user will be redirected to account/register action method along with the RedirectURL. Note (account/register action method will reside in a Registration Controller)

2: The registration form will include the following 4 fields.
• User Name
• Email Address
• First Name
• Last Name
• Password

3: When the user submits the registration form.
1. A new TestUser will be added to the TestUserStore.
a. In order to achieve this, a new method called "RegisterTestUser" will be added to the TestUserStore.
b. User will be signed in and redirect to the Return URL. - For sign in I will be using the code from the login httppost action method of the account controller.

Cheers,
HS

[leastprivilege]

Comment on 3:

• this is for ASP.NET Identity - so the user must be created in the database.
• before the user can be activated, the email address must be confirmed

Email confirmation should work like this:

• user enters his data
• email gets sent to user (ASP.NET Identity has interfaces for that)
• user gets and email with confirmation link
• user has to re-enter password
• user gets activated

[brockallen]

2: The registration form will include the following 4 fields.

I would prefer just email address as the only thing a user enters on the first registration page, then everything else filled out on the page that confirms the email (this would also be the point at which the password is collected). This workflow solves the problem of 1) the wrong email being entered and having that irrevocably paired with the desired username, and 2) a password being forgotten prior to the email being confirmed.

[TomCJones]

Your assumption seems to be that the email is that db key. This is not the way that the MSFT identity pages work. For them the key is just some guid. They allow the user to change the email (and get verification if desired) at any time. This way more than one email is possible.

[brockallen]

Your assumption seems to be that the email is that db key

Only that the email is unique across all accounts. For ASP.NET Identity, you can use the email as the username, which is treated as unique. Why would two different people have the same email in the user database?

[TomCJones]

It is true that the default method of MSFT identity is to copy the email address into both the email and the username fields. I find that a bad security/privacy practice and disable it in all of my implementations. The reason I do that is because on a blog/wiki entry the user name appears. Most people I know would prefer that not be their email address. I would discourage the practice of using an email addr as a user name for this reason.

[Harmindersingh05]

I store the email address in the username as well. This is because all my customers prefer sign in using their email address. In addition to this, I extend ASPNET identity to include two new columns, First Name and Last Name. First name and last name fields are displayed on all views instead user name.

PS:
Before I start on any implementation I will again post the final design here based on the feedback I've received.

Thanks @brockallen @leastprivilege @TomCJones

[TomCJones]

please at least leave two separate fields for each as MSFT does. That way others can do the right thing.

[brockallen]

It is true that the default method of MSFT identity is to copy the email address into both the email and the username fields. I find that a bad security/privacy practice and disable it in all of my implementations. The reason I do that is because on a blog/wiki entry the user name appears. Most people I know would prefer that not be their email address. I would discourage the practice of using an email addr as a user name for this reason.

The display name doesn't have to be the username. Think how twitter does it -- those are separate, yet display name is still unique.

[TomCJones]

Technically correct. I have found that a large number of the places I use these fields, like wiki, they tend to be the same. Note that legal name is yet another field in most of the sites I build. That does not need to be unique as it is not in real life. I find that a single unique field called user name generally works well.

[Harmindersingh05]

Workflow + Question.

1: User click on the register button on login page and user is taken to a registration page.
2: User enter a email address and clicks "Continue" a confirmation email is sent to the user with a link to confirm their
email address and continue the registration process.
3: User clicks on the link in his email and is then presented with a registration page.
4: On the registration page the user enters the following details.
First Name, last name and password.
5: User's details are updated and user is activated.

Changes that will be made.
• This workflow will be implemented inside IdentityServer/IdentityServer4.AspNetIdentity repo.
• Sendgrid email provider will be used for sending emails.
• 2 new fields will be added to the ApplicationUser class - FirstName and LastName
• New registration controller for this workflow

Question:
When a 3rd party client redirects the user to identity server for authentication and if the user triggers the registration workflow. Should we save the redirectUrl and redirect the user back to the client after registration is completed? The reason behind this is so that the user is not left stranded on the identity server after registration is completed.

[brockallen]

• Sendgrid email provider will be used for sending emails.

I'd put it behind an interface so it can be replaced or stubbed out for testing. Is sendgrid free for demo code like this? For now, I'd stub it out to just write to the log system.

And yes, somehow the return URL might want to be remembered. But it's possible that the reg process takes so long that the client has forgotten about the pending login (meaning the nonce is no longer valid). So it's tricky with no clear answer.

[Harmindersingh05]

@brockallen
Send grid will be stubbed and you can send 100 free emails per day.

Questions:
What is your take on using claims for first name and last name instead of two new columns in user table?

[brockallen]

What is your take on using claims for first name and last name instead of two new columns in user table?

that depends on if the app ever needs to query/filter based on those values. also, are they mandatory?

it's hard for a generic sample to know how it will actually be consumed.

[Harmindersingh05]

They are not mandatory. I will just create two new columns for them 👍

[TomCJones]

if you ever plan to be an international offering I would suggest Family-name and Given-name

[Harmindersingh05]

Thanks @TomCJones the column names will be Family-name and Given-name as this aligns with claim types as well.

[molaie]

Hi all.
Is there any sample code to what is discussed here?
or any progress on ASP.NET sample UI Repo?

[topfunet]

This is how we do it, hope can help you!
Because when we click a action with [Authorize] we will be redirected to identityserver's Login page with a lot of parameters, so we can't just go to Register page, there is no parameter such as state and nonce.
So, how about we add a parameter like op=register when we redirect to /connect/authorize, then if identityserver found this parameter it will redirect to Register otherwise redirect to Login.
And all parameters are there, you can do whatever you want.

[ChrisDinhNZ]

And yes, somehow the return URL might want to be remembered. But it's possible that the reg process takes so long that the client has forgotten about the pending login (meaning the nonce is no longer valid). So it's tricky with no clear answer.

Hi @brockallen
I know this is an old issue but your comment is the closest I found at describing the problem I have right now. Would you have a suggestion on the UX flow regarding the return url back to the client? I am not sure what is the common method?
Should I pass it along with the confirmation url in the confirmation email?
What if the confirmation url is too long? Can I store the return url as a user claim and if the confirmation is successful I can use that claim to redirect the user back?

[leastprivilege]

We decided that we will not provide/maintain a UI based on ASP.NET Identity that supports the full account management lifecycle.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.