We would like a UI for two-factor login workflow 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.
not sure what you are looking for. I am starting to write code for U2F. I am having a challenge figuring out how/where to integrate that with OpenID connect, especially where external authn is used, but U2F is separate from that. Have you some particular use case in mind.
Yea, it's for our ASP.NET Identity quickstart/sample UI.
ok, let me try that qs and see where it might take me
Here's the main code repo that we work from: https://github.com/IdentityServer/IdentityServer4.AspNetIdentity/
I'd want a new "feature folder" separate from all the existing ones. The intent is to minimize the differences between the ASP.NET Identity quickstart code and the one for our main in-memory TestUser "database".
sorry, but on your comment "it's for our ASP.NET Identity quickstart/sample UI."
Do you mean for it to be in:
didn't hear from you - so - I will just build a solution using the existing quickstart UI and the gut that and replace with U2F, then I can check in just the same three folders you show in the quickstart UI.
Not clear how to name a brand new folder - I guess just U2F-UI?
Here's the main code repo that we work from: https://github.com/IdentityServer/IdentityServer4.AspNetIdentity/
This is the code for our QS for ASP.NET Identity. We then take that code and put it here as the official quickstart: https://github.com/IdentityServer/IdentityServer4.Quickstart.UI.AspNetIdentity
Well, I have U2F code, now I am trying to decide where it goes in the flow. It could be anywhere, even in the client. It seems to be that the best place for it is when the user clicks "Yes, Allow" on the consent page. Which assumes that consent is required. But if not it could go else where.
The major point is to decide the duration of the 2nd factor. It seems to me it should match consent.
I think you're overthinking it. Just treat it as a 2nd factor after username/password (prior to consent). At least that's how I think of it.
well, that was the question, before or after consent. But think about it. the user enters the password, and the user record is obtained. then they are asked for two more interactions. Provide the second factor, select the list of data elements to be provided. It is possible for the choice of elements to be provided to include a choice of the second factor (or not). So there is a possible benefit to providing the second factor after consent is granted. In any case there is another round trip.
Again, I'd keep it part of the authN step. Consent might be disabled, so if you put the code there you'd miss your chance for 2fa.
another question - which is the priority? core2.0 or fast release
Here's the problem, some 2 factor packages, like https://github.com/brucedog/U2F_Core
have core 2.0 packages, but so far as i have been able to tell, they all have .net framework 4.5 or 4.6.x dependencies. I thought i could rework the package above, but that will take some time as there still are things, like crypto, that are not yet fully developed in 2.0. I can focus right now on one or the other.
I thought you were adding 2fa via ASP.NET Identity's support for RFC6238 authenticator apps?
the google authenticator is pretty lame as a 2nd factor, even google has moved on to U2F, but if the U2F stuff is not available on core 2.0 crypto at this point it makes sense to use it as a poc.
Yea, this is just sample code so people know how to fit such things into the UI workflow. It's not meant to be their actual 2fa architecture.
i got this working a few weeks ago, but had several blockers porting the code to your framework. I have some time again now so I can try that again. My questions are all about what you want to support, for example arguments, should I install some particular package, or eliminate checking. for example:
[Required]
[EmailAddress]
public string Email { get; set; }
porting the code to your framework
Can you elaborate if it's still blocking you?
My questions are all about what you want to support, for example arguments, should I install some particular package, or eliminate checking. for example:
All I'd want is something similar to what the ASP.NET Identity templates support for 2FA using their authenticator plumbing that implements RFC 6238. This involves seeding the authenticator device and the user entering a test value to confirm it. Then on the login page you'd check after username/password if the account requires 2fa and prompt for the authenticator value.
I have a working sample at https://github.com/TomCJones/IdentityServer4.AspNetIdentity
I would appreciate feedback.
I created a pull, but think some additional testing would be good.
Ok, I"ll try to have a look when I'm back home in a week or so.
Exactly what I was about to start to modify my local quickstart to handle 2FA until I saw this git issue.
I am hoping Brock can make time to review the pull and accept it. If not I am going to start following TomCJones' sample to implement 2fa in my identityserver4 project. Thanks TomCJones !!!
Brock, does this mean the IS4 middleware will also need to be updated to add new redirections to the 2FA pages ?
I let this fall off because of all the UI updates Microsoft has been doing to ASP.NET Identity. I don't have a good update for you on this -- I reviewed the code, and it seems fine. But I'm at the point where I am not sure if we should be responsible for this. @leastprivilege and I can chat to see how important it is for us to maintain our own version of how MFA should/could be done.
Thanks for the update. Appreciate all your work in making my job easier. I am using your oidc-client.js on my react app.
@TomCJones as I said on the PR -- I think having your sample linked from our docs would be the best, as opposed to having our template support it.
We decided that we will not provide/maintain a UI based on ASP.NET Identity that supports the full account management lifecycle.
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.
Most helpful comment
Again, I'd keep it part of the authN step. Consent might be disabled, so if you put the code there you'd miss your chance for 2fa.