Running a localSTS inside the same site as the RP? Other questions about locally issuing tokens

Question

We have an application that is using WIF 4.0 and ACS for our authentication needs.  We want our users to be able to auth with FB, Live, custom etc.  We pretty much have all that working now (lots of thanks to these forums).

Now we also want to support an 'alternate' authentication method of standard forms auth.  For the best user experience, we want it to be inline user name and password entry FROM OUR SITE without the need for lots of redirects, clicks or ACS.

My thinking was this would not be a problem, but I am a little stuck.

It would seem to me, what i need is to create a LocalSTS or using something like IdentityServer which acts as a claims wrapper to MembershipServices.

The user will login using FormsAuth, we can then do something like:

if (Membership.ValidateUser(model.UserName, model.Password))
{

 // Issue our claims

// Redirect to standard Account/LogOn page that is our ReplyTo site for ACS

// Let WIF take care of the rest

}

My questions are:

1.) Is there any reason I can't embed my STS into my existing project?  Do I really need to re-direct to a different site?  Can the WIF configuration handle being both an RP and an STS (if I have those right)

2.) If so, what method do I call in WIF to "issue my token and redirect back to the ReplyTo site" - we are using SWT from ACS, so I need to issue one of those.

3.) It would seem that I could do what this guy does:  http://stackoverflow.com/questions/5997848/adding-claims-based-authorization-to-mvc-3 and just issue my session directly from the post FormsAuth login.  Is this best?  Or should I try to simulate a localSTS and pass a token to STS?  Certainly from a code / future stand-point, I would like to use my current ClaimsTransformation for all forms of auth and not issue directly within my FormAuth ValidateUser method.

Even if you can't answer #2, I appreciate any insight if I am on the right track or not.

Thank you!

Answer 1

Mixing Forms and federation is a tough thing to do properly as there's never a one-size-fits-all solution. Generally you want to abstract away as much of the identity-stuff as possible from the application, so it isn't necessarily a bad idea to create an STS that talks to ACS instead of doing things directly in the app. Writing directly to the session muddies the abstraction.

With that being said, Dominick Baier wrote a good article on this: http://www.leastprivilege.com/MixingFormsAndTokenAuthenticationInASingleASPNETApplicationTheDetails.aspx

However, he's using WS-Fed, not SWT.

---

Developer Security MVP | www.syfuhs.net

Answer 2

I think writing directly to the session makes sense in this scenario.

Authenticate the user, create a ClaimsPrincipal, wrap that with a SessionSecurityToken, write the token to the cookie, redirect.

---

Dominick Baier | thinktecture | http://www.leastprivilege.com