brockallen / BrockAllen.MembershipReboot

MembershipReboot is a user identity management and authentication library.
Other
742 stars 238 forks source link

Change password in identityserver3 and membershipreboot #577

Closed peymanebrahimi closed 8 years ago

peymanebrahimi commented 8 years ago

I have an IdentityServer3 with membershipreboot and EF -- single Tenant. A web Api2 as resource server with Claims Aware Authorization. The client application is a javascript app (angularjs) with implicit flow which uses OIDCTokenManager. Users are registered by admin in IdentityManager in LocalHost mode. I need to implement "Change Password" in client app. when a user clicks on login button on JS client, the oidcTokenManager will redirect her to login page on identityserver. My Question is "How should I implement Change Password?" Should I implement a controller such as "SingleTenantWebApp" example for changing password, and let the client call it? Or Am I at the right path at all? Thanks @brockallen and @leastprivilege for their wonderful job.

brockallen commented 8 years ago

Sounds like a web api that needs an access token to change the user's password.

peymanebrahimi commented 8 years ago

@brockallen Thanks for your reply, I'll use "SingleTenantWebApp" example to create ApiController. In the above mentioned system, when I create new user via IdentityManager, however in CustomConfig in MembershipReboot the Config.RequireAccountVerification = false; but the user can not login and In UserAccounts table, the isAccountVerified=0, and I have to manually make it true. Am I missing something?

brockallen commented 8 years ago

In IdMgr and in IdSvr you might be creating 2 different MR configs with different require account verification settings?

peymanebrahimi commented 8 years ago

@brockallen tnx man, that's the point, How should I combine these 2 extension methods? namespace IdentityServerIdmMemReb.IdSrv { public static class CustomUserServiceExtensions { public static void ConfigureCustomUserService(this IdentityServerServiceFactory factory, string connString, string idsrvSchema, IAppBuilder serverApp) { factory.UserService = new Registration<IUserService, CustomUserService>(); factory.Register(new Registration()); factory.Register(new Registration(r => CustomMRConfiguration.CreateCustomConfig(serverApp))); factory.Register(new Registration()); factory.Register(new Registration(resolver => new CustomDatabase(connString, idsrvSchema))); } } }

namespace IdentityServerIdmMemReb.IdMgr { public static class MembershipRebootIdentityManagerServiceExtensions { public static void Configure(this IdentityManagerServiceFactory factory, string connectionString, string idmSchema, IAppBuilder adminApp) { factory.IdentityManagerService = new Registration<IIdentityManagerService, CustomIdentityManagerService>(); factory.Register(new Registration()); factory.Register(new Registration()); factory.Register(new Registration()); factory.Register(new Registration()); factory.Register(new Registration(resolver => new CustomDatabase(connectionString, idmSchema))); factory.Register(new Registration(r => CustomMRConfiguration.CreateCustomConfig(adminApp))); } } } I wanted to different schema for MR and Idsrv related tables. To get a clue to the big picture. Also for customeEmailEvents I ended up with a new parameter as IAppBuilder. I wish I had deeper understanding of Factory &/| Service Design patterns. Any road map will be appreciated Sir.

brockallen commented 8 years ago

Well, if you want them to use the same MR settings, then factor out the code that creates the MR config into some common location and use that across both.

peymanebrahimi commented 8 years ago

Thanks I know It is very nice of you to answer. and It is not your job to answer following question. But I do not have any idea to register one common config in that Registration system. I noticed right now that all code between "< >" was excluded from above posts. and don't know why. There is one customDb, customConfig, customUser, and ... . but in the registration system, I think each one new up these classes for themselves.

brockallen commented 8 years ago

So you're real question is about the 2 different DI systems? This is a limitation of OWIN and Katana since there's no common DI system in the spec.

peymanebrahimi commented 8 years ago

No, no idsrv needs "factory.UserService = new Registration<IUserService, CustomUserService>();" and idm needs "factory.IdentityManagerService = new Registration<IIdentityManagerService, CustomIdentityManagerService>();" shame on me if it s obvious, but both of above follow other registration. therefore each will new up separate objects of customConfig, however it is 1 unique class.

peymanebrahimi commented 8 years ago

image

image

brockallen commented 8 years ago

Those are 2 different Registration classes -- check the namespaces. IdMgr and IdSvr aren't using the same implementation.

peymanebrahimi commented 8 years ago

I know. Does it mean registration has nothing to do with object instantiation? I emphasis that there is one unique customConfig which "RequireAccountVerification" is sat in. and "config.EmailIsUsername = true;"

brockallen commented 8 years ago

So you will build a new API that changes the password. In that code you will connect to MR. This API has nothing to do with IdMgr. To secure this API you need an access token with a scope. This scope represents the user management feature and it's only issued to your client app that the user uses to manage their account. You get tokens for this app the way you would any app you build that uses IdSvr.

I guess this is all obvious to me and it's not clear what else I can suggest. Perhaps just the concept that the feature needs to be it's own app is what you need.

peymanebrahimi commented 8 years ago

I will try webApi for change password. But the question was the users which created by the admin in localhost, are not able to login till I set their isAccountVerified manually in db. when I try to login in clientApp with credential that I made in Idm, it says usename or password are invalid.

brockallen commented 8 years ago

IsAccountVerified is a config property. The instance of the MR config in the app where passwords are validated controls if they're allowed to authenticate if the account's email is verified. So if you're using IdSvr for logins to your other apps, then in that instance of the MR config don't set require account verification.

Or am I still not answering the question? It seems that there are 2 or 3 questions in this thread (or again, I'm simply not understanding).

peymanebrahimi commented 8 years ago

You answered main question, and I really appreciate it. Thanks for your time.