MembershipReboot & IdSrv

[mafis]

First thanks for you great work on all your Open Source Products

At the moment i am trying to combine MembershipReboot and the Identity Server. I use the Identity Server as Provider for your Authorization Server.

After all i read add Usermangement directly to Identity Server is not the best idea. So i try to get this things seperated and create a Usermangement System based on MembershipReboot.

Now i am understanding everything write i can create Repositories for IdentityServer based on MembershipReboot and so i can use the same Userdata.

My directly question is, it is possible to outsource the whole Login,... to the Usermangement System from Identity Server away ? Like the Identity Server isn't there or another option to use Authorization Server directly with my Usermangement System ?

A little Example what in my mind:

1. User ist Registering on Usermagenent
2. Now is getting in an App which uses the Authorization Server
3. Authorization Server redirects at the moment to Identity Server and User is Logged in
4. Redirects back to AS...

It is possible to change the third Step to use my Usermangement System ?

Or it is the wrong way?

[brockallen]

I think it's a good idea to separate the identity management system from the STS (IdentityServer). For the login, though, IdentityServer needs to somehow know who the logged in user is and that's why is has a login page. As part of the login code, there's support for a custom implementation that validates the user's credentials, and you could implement this in terms of MembershipReboot. This is the approach I'd suggest.

[mafis]

Ok, with Login Code you mean the "Repositories" Interfaces or something other?

[brockallen]

Yep, to signin you'll need a custom IUserRepository. To view and/or manage the users in the admin page you'll need a custom IUserManagementRepository. If you want to manage certificates for users in the admin page then you'll need IClientCertificatesRepository. And finally to customize the claims that are issued in the token from the STS, you need to implement IClaimsRepository.

HTH

[dealproc]

Unfortunate... I'm struggling with this exact issue right now... wondering if we cannot all band together and get one last OSS project out that ties Identity Server, Authorization Server, and Membership Reboot into a cohesive solution that we can all just build our business applications from with this "cohesive solution" as the root.

[brockallen]

Yes, I hear you :) Putting a sample or project together like this has been on my TODO list for some time.

[dealproc]

Well... as of right now, I have the idea of the following implemented:

• users
• accounts (as in tenants within an application)
• resellers
• (stolen from TeamCity) * roles * groups \ permissions

I have to add the hierarchical org. of an "Application" in the system, since i have many apps that need to draw from this... then accounts, roles, groups, and permissions need to all become children of an Application. This is all implemented using DurandalJS and WebAPI with a Postgres db.

With what I have above, and the re-org for "Application".... if I just implement the custom repos from MembershipReboot, what all would IdSrv and AuthServ need to have to be able to re-namespace and push this out as OSS? I'm so tired of thinking of this that I'm willing to put it out as OSS just so that I don't have to do it again!

The only other item I'm unclear on is how, on a per-application basis, I'd link to a central "user".

[mafis]

An OOS Project Sounds Great.

I think i will start an easy Usermangement System based on Membership Reboot. And the Repositories for Identity Server and bring it to Github.

[dealproc]

Outside of the tie-ins to the thinktecture bits + Brock's Membership Reboot, I have most of it built... my git-fu is abysmal @mafis but I think I can probably give you most of the UI and db bits in appx 1 wk. And it's in the SPA style... so someone could build a phone app that works much like what DNSimple did for dns management.

I have a mercurial repo on my business DCVS that has all of this in there https://tailoredpos.kilnhg.com/Code/Public/Samples/CredentialManagement (or it did... have to pull the bits out of the production app and merge into this "public" repo). The only thing I'll possibly be missing is an invoicing mechanism... but the data bits could be scraped into another tool, like dotnetopeninvoice or whatever.

in the sample project, i'm using SQLite, but its abstracted out into its own implementation... we can do the same for postgres, EF, etc.

Thoughts on next steps?

[brockallen]

You guys know what - I'll go knock one up real fast and at least that can serve as a starting point.

[mafis]

@brockallen that would be fantastic :+1:

What is real fast for you :) ?

I have something in mind, but you are a real pro at that topic.

[brockallen]

Well, I've gotten as far as File -> New Project.

[dealproc]

why don't you fellas scrape my credential management project as a starting point... it makes no sense to re-invent the already cut wheel here.

[mafis]

@dealproc i think (hope) @brockallen & i have something other i mind which would be easier to create within a new project

[brockallen]

Yea, I don't want to build a whole management UI. I just want to show the smallest code to get MR to work in IdentityServer. I'll go peek, tho, @dealproc.

[mafis]

The question for me is what makes an Identity Management System (IMS) an IMS.

Users, Roles & Groups or ?

[brockallen]

Ok, I'm done coding it... just testing now. Stay tuned.

[dealproc]

Seriously, it was that easy?! O_o

[brockallen]

Yes, it was that easy... except... MR requires email addresses, whereas IdentityServer when creating the initial admin screen doesn't allow for an email for the admin, so that's the only hang up right now. I've been toying with the idea of allowing MR to not require emails. So I'm thinking of adding this to MR right now. Thoughts?

[dealproc]

If you're asking... go for it. If we can align these 3 projects that they can co-mingle, that'd be the end goal of it all.

[mafis]

I think it's ok without require an Email.

But also it cuts out a lot of things that MR does. Hmm

[brockallen]

Ok, here's the check that contains the sample: https://github.com/thinktecture/Thinktecture.IdentityServer.v2/commit/eb09981d28b1b24f62dc413d00e2dc7b3f164929

The one thing that won't work is the initial configuration page where you create the admin account -- you will need to change the web project's Controllers\InitialConfigurationController.cs and on line 152 where it creates the admin account simplypass a 3rd param that has a string that looks like a valid email address ("admin@admin.com", for example).

[brockallen]

Here's the direct URL, if needed:

https://github.com/thinktecture/Thinktecture.IdentityServer.v2/tree/master/samples/MembershipRebootUserRepository

[brockallen]

Yes, good point @mafis. But I recently came across a client that did not want email verification in any way, plus you can already disable email account verification today (but it still requires an email).

[brockallen]

@mafis look over the sample and if you have questions, then ask. Once you're content, go ahead and close this issue, please. Thanks.

[dealproc]

so this gets tucked into Identity Server, we still take membership reboot and flesh that out, and we need authorization server if we want to enable mobile clients?

[mafis]

The example looks great.

A good starting point for the identitymanager is the Membership Reboot Sample App.

I get in some trouble with the MembershipReboot NuGet Packages, but that's another topic so i create a issue within MembershipReboot.

But this could be closed now.

[brockallen]

@dealproc this sample for MR + IdSrv is unrelated to AuthorizationServer.

[dealproc]

cool. apparently this is on tonights task to get this all in place. Thanks for the sample to kick-start it.

[dealproc]

Going through the MR samples, specifically the MR SingleTenant sample, I notice that MR has the capability of associating my credentials with facebook/google/etc. Knowing that Identity Server has similar capabilities, are we able to extend the sample to include those bits at some point, or at least document the direction someone would need to take on the IdSrv end in order to fully utilize MR with IdSrv?

After evaluation, although we wont be doing it now, we will be spec'ing out to do an integration project to use all of the MR features with IdSrv, where they fit (2-factor auth, etc.)

[brockallen]

Well, IdSrv's support and MR's suport are slightly different. IdSrv maintains nothing in its DB about about a user's social logins -- it's really just there to broker (actually that's true for all federation gateway logins). And in fact it doesn't even implement the OAuth2 client protocols -- that's implemented by a different library. MR only maintains data for a user's external login providers. It too does not implement the protocols.

But yea, I can see what you're getting at -- instead of setting the external logins via the HRD page, why not just support the social logins directly from the IdSrv login page.

[dealproc]

right... IdSrv is meant for controlling Identity within our ecosystem, and it seems only right that you support all the login UI's there, even for the HRD logins (facebook, github, etc.)

Someone did do just this (move the HRD buttons into the login) and it's on github, but i'd almost like to see it in the base tools, instead of each user of this tooling having to re-script it.

It would be nice to get 2-factor auth into IdSrv as well, since again, it's part of the login story. We can use MR to manage the data, which makes sense.