[ASP.NET Identity 2] Hoe custom authenticatie-cookies zetten

[Avalaxy]

Ik werk aan een custom implementatie van ASP.NET Identity 2.0 die werkt met ons eigen datamodel, een ander ORM, maar ook met andere business logic. Standaard is het zo dat je inlogt, er een ApplicationCookie wordt geset, waarna de standaard AuthorizeAttribute deze herkent en je inlogt. In onze eigen implementatie wil ik deze implementatie echter flink oprekken.

De bedoeling is dat je op allerlei manieren in kunt loggen, bijvoorbeeld:

• Impersonation
• Password reset token
• Google Authenticator (two-factor)
• Username + password
• SMS (two-factor)
• Etc.

In alle gevallen moet de gebruiker ingelogd worden, maar welke acties uitgevoerd mogen worden hangt af van de manier waarop je ingelogd bent. Zo ben je met 'Password reset token' weliswaar ingelogd, maar heb je alleen permissie om je wachtwoord aan te passen. Met 'Username + password' mag je bijna alles doen, behalve de dingen waarvoor je bijvoorbeeld weer two-factor nodig hebt (SMS of Google authenticator). Om dit te bereiken wil ik in mijn custom AuthorizeAttribute kijken welke cookie er geset is, en aan de hand daarvan wel of geen permissie geven.

Het probleem is bijvoorbeeld dat er bij SMS welliswaar een 'TwoFactorCookie' wordt gezet, maar deze wordt niet herkend als valide inlogmethode. Zo is HttpContext.Current.Identity null. Alleen een ApplicationCookie resulteert in een log in.

Waar ik momenteel mee worstel:

1. Is het de bedoeling dat ik altijd ApplicationCookie gebruik om de gebruiker in te loggen en op een andere manier (bijvoorbeeld via Claims) het onderscheid maak qua inlogmethode, zodat er altijd maar één cookie is? Of is het handiger toch aparte cookies te gebruiken per inlogmethode? Zo ja, hoe zorg ik er voor dat 'XYZCookie' ook resulteert in een ingelogde gebruiker?
2. Valt samen met punt 1: is het de bedoeling dat ik custom authentication middleware schrijf voor mijn andere inlogmethodes of kan ik gewoon de standaard CookieAuthenticationMiddleware daarvoor gebruiken? Het enige dat er moet gebeuren is dat er een cookie geset wordt, en aangeduid wordt op welke manier de user is ingelogd.

[ Voor 5% gewijzigd door Avalaxy op 30-10-2014 17:21 ]

[Sebazzz]

Moet je niet claims gaan gebruiken? In de claim geef je aan hoe de gebruiker is ingelogd. Claims zijn ideaal om meta data bij te houden.

[Avalaxy]

Dat is inderdaad een van de opties die ik overweeg. Maar wat is het nu dan van TwoFactorCookie en ExternalCookie? Wat doen die?

[D-Raven]

Ik zou wat Sebazzz ook al aangeeft Claims gebruiken.

De cookies worden gebruikt om tijdelijk informatie op te slaan ter ondersteuning van het Two-factor authenticatie verhaal. Voornamelijk als je via een 3rd party gaat inloggen. Maar hoe het precies in het Two-Factor verhaal past ben ik ook nog niet achter.
Lastig om concreet wat over te vinden.

[ Voor 139% gewijzigd door D-Raven op 31-10-2014 13:18 ]

[Avalaxy]

Op StackOverflow heb ik een reactie van iemand die in het Identity team werkt van microsoft. Hij schreef:

quote: http://stackoverflow.com/...om-authentication-cookies

So each instance of a CookieMiddleware basically represents one auth cookie, if you want multiple cookies, you can add more than one CookieMiddleware and to retrieve the ClaimsIdentity mapping to your cookie, you just need to call Authenticate on the AuthenticationManager passing in the AuthenticationType for the cookie you want.

Ik heb nu dus een aantal extensions gemaakt, die er bijvoorbeeld zo uitzien:

C#:

public static void UseSmsSignInCookie(this IAppBuilder app, TimeSpan expires)
{
    if (app == null)
        throw new ArgumentNullException("app");

    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = ApplicationAuthenticationTypes.Sms,
        AuthenticationMode = AuthenticationMode.Passive,
        CookieName = CookiePrefix + ApplicationAuthenticationTypes.Sms,
        ExpireTimeSpan = expires,
    });
}

Vervolgens log ik de user in door AuthenticationManager.SignIn aan te roepen met een custom ClaimsIdentity (die dus mijn eigen authentication type mee krijgt). Echter is na het aanroepen van SignIn het resultaat van HttpContext.Current.User.Identity.AuthenticationType nog steeds ApplicationCookie. De cookie is wel gezet zoals het hoort.

Iemand enig idee wat ik mis?

[Avalaxy]

Iemand?

[D-Raven]

Je zou kunnen proberen om hier wat vragen te stellen. Via de Discussions.

https://aspnetidentity.co...ol/latest#Readme.markdown

[Avalaxy]

Thanks, gedaan.

[Avalaxy]

Nog nergens een reactie

[Sebazzz]

Heb je het al geprobeerd met claims in plaats van vijf cookies?

[D-Raven]

Sebazzz schreef op donderdag 06 november 2014 @ 22:40:
Heb je het al geprobeerd met claims in plaats van vijf cookies?

Dat is niet wat zijn probleem oplost. HIj wil dat het type van zijn Security Identity mee veranderd met de methode van login.
Naar aanleiding van documentatie e.d. zou je er vanuit kunnen gaan dat dit zou moeten werken, aangezien zo'n beetje alles om zelf iets te implementeren wel aanwezig is.
Het is alleen ontzettend lastig om fatsoenlijke documentatie hierover te vinden.

[Avalaxy]

Uiteindelijk maar gekozen voor de claimsmanier, maar iemand een oplossing voor dit probleem? \[ASP.NET Identity] HttpContext.Current is null