search

aspnet / Identity

[Archived] ASP.NET Core Identity is the membership system for building ASP.NET Core web applications, including membership, login, and user data. Project moved to https://github.com/aspnet/AspNetCore
Apache License 2.0
1.96k stars 868 forks source link

[Question] How to do SSO with a Forms Auth MVC app that is not using OWIN? #1405

Closed yarsiemanym closed 7 years ago

yarsiemanym commented 7 years ago

Hi all,

Not sure if this is an appropriate place to ask this question but here goes anyway.

I have a couple of older ASP.NET MVC apps that use Forms Authentication, ASP.NET Membership and do not use OWIN. Moving forward I would like develop new apps in .NET Core using IdentityServer4 for auth. I implemented a custom IUserStore et al so IdentityServer can use my existing ASP.NET Membership database and all that is working well. Users registered via IdentityServer can log into my older apps and vice versa. The problem I'm having is that Forms Authentication in my older apps and ASP.NET Identity aren't generating cookies that the other understands. So while I'm able to share accounts across the apps, I don't have SSO.

I'm looking for some guidance on how to proceed. My first inclination was to attempt to implement a custom IDataProtector and ISecureDataFormat<AuthenticationTicket> to use in the IdentityCookieOptions. This might work but I have zero idea how to replicate in DPAPI what Form Authentication is doing with the machine key. If there is a way to get the encryption to line up, I'm at a loss on how to do that. Maybe there's a better/easier way?

Here is my Stack Overflow question if you could also past your answer there as well.

blowdart commented 7 years ago

It's not just the encryption, it's always the format. I'd look at moving to Identity Server as the main auth point, and then federate all your applications to that. So for WebForms go with WS-Fed support, then for Core use OIDC.

yarsiemanym commented 7 years ago

Hmmmm. If at all possible, I'd like to avoid making changes to my legacy apps. Less risky that way. Is there no way to override parts of ASP.NET Identity and customize the cookie to the point where Forms Authentication would recognize it?

blowdart commented 7 years ago

Well there's a ticketformat extension point, but oh lord, it'll be ugly, you'd have to yank a lot of the old stuff up.

yarsiemanym commented 7 years ago

At this point, I'm trying to determine which is worse: overhauling the auth framework in a number of legacy apps or going down this rabbit hole. What kind of old stuff are you referring to? Just point me in the right direction and I'll see how far I can get.

blowdart commented 7 years ago

You'd dragging core down to the level of web forms security, and I'll be honest I'm not even sure it'd work. Add to that none of the code that old is actually on reference source, so I can't point you to it. You'd have to fire up a decompiler and go hunting yourself. At which point licensing issues kick in, and I can't advise anything.

yarsiemanym commented 7 years ago

Gotcha. I'm no security expert but I was able to figure out how to deal with the hashed passwords in my ASP.NET Membership database. That little flicker of glory might have gone to my head.

Let me bounce this off you. If my legacy apps were built on OWIN would that change anything?

blowdart commented 7 years ago

If they didn't use identity? No. The recommendation would be the same. If you pulled them up to identity 2.0 then you could use the forward compat pieces with a bit of work to share the keys.

yarsiemanym commented 7 years ago

OK. Yeah that's what I meant. I saw some articles about Framework45 compatibility mode but found out pretty quick that wasn't going to work for me unless I moved to OWIN and Identity. I don't know much about WS-Fed but I do know a bit about OWIN and Identity so I'm wondering if the bigger bang for my buck might be to port the apps over to OWIN and Identity and do the Framework45 compatibility stuff. Is the WS-Fed route relatively simple?

blowdart commented 7 years ago

None of this is simple if I'm honest. But if you're wanting to use Identity Server it would be the way to go, that way every app is going to use the same auth point.

yarsiemanym commented 7 years ago

WS-Fed would be simpler than porting the app to Identity and using Framework45 compatibility mode?

blowdart commented 7 years ago

Well no, I think you'd do both. You use WS-Fed to bind the old apps to Identity Server as their login mechanism. It'd probably take less time, but it'd need WIF (at a minimum), better would be moving to the version inside .NET, which takes, I think, .NET 4.0.

yarsiemanym commented 7 years ago

I've never done anything with WS-Fed before so I'm likely not fully understanding something. Can you list the coarse-grained steps I'd have to take to convert my legacy app to use Identity Server?

brockallen commented 7 years ago

You can just as easily use OIDC from WebForms -- just put Kanata in front and use the OIDC authentication MW (like in our webforms sample: https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Clients/WebFormsClient).

If you don't want to use OWIN, then you can implement the OIDC protocol manually (like our other sample: https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Clients/MvcCodeFlowClientManual).

yarsiemanym commented 7 years ago

Thanks, Brock! It actually looks like MvcFormPostClient is going to do the trick. Does that make sense?

brockallen commented 7 years ago

The beauty of OIDC is that it's designed to be easy for clients to consume. So webforms, php, JS, python, etc. should all have an easy time. The main requirement is a JWT processing library. The one from Microsoft requires .NET 4.5, but there are others for .NET pre-4.5.