I’m evaluating your solution for one of our projects and there is one thing that doesn’t fit with out requirements – using the mobile phone number as username.

The default username validator requires that the username contains at least one letter effectively disallowing the use of phone numbers.
I could certainly work around this by inheriting the UserAccountService and overriding the ValidateUsername method but I’m wondering if there is a good reason behind requiring at least one letter (like guarding against brute force attacks)?

In a future release may I suggest you think about making the validation even more flexible, i.e. allowing us to build our own ‘AggregateValidator’s.

If this is already documented somewhere, please point me in the right direction. Thanks!

hello,
I am new to identity management, but would like to know if it is possible to exposes the methods of MR as a Rest service so that I can use it from different applications. in fact I am writting a rest service that will be used by different plugin using the rest api, I will also have a asp.net web app that will connect and use this rest service.
regards

Are there any plans to have MR end up inheriting / be built on top off and extend the new ASP.Net Identity introduced with MVC 5? Or is your idea to be a competitor of sorts with asp.net identity? I’ve been playing with MR and I’m pretty happy with it btw, nice work.

We are needing to allow outside companies the ability to lookup users in our system and authorize them to login to their system. Sort of like how one would use Facebook to login to another web site. Do you have any samples or guidance for using MembershipReboot as a service over the web?

Sorry for the newbie questions but we’re upgrading from ancient methods of a web form calling an action page that runs a sql query. The Thinktecture IndentiyServer looks promising but does it work with or instead of MembershipReboot?

They serve different purposes. MembershipReboot is for managing a database where you have to store users’ passwords and identity data. IdentityServer is for centralizing your identity so your users can have single sign-on across multiple apps. IdentityServer can use MembershipReboot to store users’ identity data.

So just to clarify, I would pass my users to the login page if IS but use pages on MR to do management of the account (password reset, remind, etc.). I can’t use a login page on MR and still create a token. So, to be less confusing to my users, I’ll style the pages the same. Can they live in the same domain but just be different apps in different sub folders?

Your STS issues tokens for signing in. Where you do management of your users is up to you and depends on requirements. If you want self-service, then doing this in the STS can work, or you can create a new app to do this as well (which would share the DB with the STS).

It’s still not clear to me how I can have my cake and eat it too. How do I integrate all the brute force, etc. protections for user login while issuing a security token for SSO? You’ve created a great product, but the documentation is very weak for those of us just entering this world. I would be very grateful for better documentation as this is now looking like more work than writing from scratch.