[ASP.NET] security.

[Alarmnummer]

Ik heb het volgende:

Ik heb een service Foo, met een methode bar. Deze methode bar kijkt in de Thread.CurrentPrincipal of de juiste IPrincipal wel goed is gezet. Zo nee, krijg je een security error, anders ga je verder. Tot zover de service layer.

Ik heb verder ook een LoginService. Deze kijkt of de login/password correct zijn. Zo nee? Dan een error.. Zo Ja? Dan wordt een IPrincipal opgebouwd met al zijn roles. Tot zover de Login Service.

Wat verwacht ik:
Ik heb een webapplicatie en ik neem aan dat IIS gebruik maakt van een of andere request afhandelende thread pool. Als iemand op zijn browser een pagina opvraagt, dan komt dit request binnen bij IIS. IIS pakt dan een thread uit de pool. Pakt daarna de Session die hoort bij die Persoon. En vist uit de Session de IPrincipal en koppelt deze aan de Thread. De thread kan nu beginnen met acties uit te voeren op mijn Foo service.

Als iemand inlogt moet uiteraard de gevonden IPrincipal wel even gekoppeld worden aan de Session zodat hij er later weer uitgehaald kan worden.

Dit is wat ik dus graag wil/verwacht van .NET. In hoeverre helpt IIS mij? Dus kan hij zelf uit de session de Principal halen en deze koppelen aan de request afhandelende Thread? Of moet ik het zelf doen?

Ik ben verder niet op zoek naar andere oplossingen.. ik wil gewoon dit aan de praat krijgen. Ik heb weinig tijd en weinig zin om het aan te gaan passen. Lees mijn verhaal aub goed want ik heb met .NET continu het gevoel dat niemand in staat is antwoord te geven op mijn vragen.

[ Voor 14% gewijzigd door Alarmnummer op 28-12-2004 11:04 ]

[Verwijderd]

ja en nee, met windows login doet IIS het voor je, als je forms security gebruikt moet je het zelf doen. Als je roles gebruikt dan. ik sla bijv. nog wat extra gegevens op in mijn auth ticket.


Als je op de website van microsoft kijkt, kan je een pdf downloaden die heet secnet en deze spreekt over jouw vragen. Het is een goed document en behandelt alle security opties voor .NET voor bijv. ASP.NET, remoting, webservices etc.... hoop dit je iets op weg helpt.


voor asp.net en forms gebruik ik dit stukje:

code:

void Application_AuthenticateRequest(object sender, EventArgs e)
    {
        // fetch the cookie
        HttpCookie myCookie = Context.Request.Cookies[FormsAuthentication.FormsCookieName];

        // if no cookie is found we have a anonymous user
        if (myCookie == null)
            return null;

        // decrypt the ticket
        FormsAuthenticationTicket myTicket = FormsAuthentication.Decrypt(myCookie.Value);

        // the cookie couldnt be decrypted
        if (myTicket == null)
            return null;

        // create the users identity
        FormsIdentity myIdentity = new FormsIdentity(myTicket);

        // create the users principal
        GenericPrincipal myPrincipal = new GenericPrincipal(myIdentity, null);

        // set the principal
        Context.User = myPrincipal;

        CustomerContext myContext = CustomerContext.DeSerialize(myTicket.UserData);
    }

[tijn]

Alarmnummer schreef op dinsdag 28 december 2004 @ 11:02:
Dit is wat ik dus graag wil/verwacht van .NET. In hoeverre helpt IIS mij? Dus kan hij zelf uit de session de Principal halen en deze koppelen aan de request afhandelende Thread? Of moet ik het zelf doen?

De truuk is om het HttpApplication.AuthenticateRequest event te gebruiken (Global.asax of eigen HttpModule). Hierin kun je je eigen IPrincipal koppelen aan de pagina die uitgevoerd wordt:

code:

IPrincipal alarmnnummerPrincipal = ...
HttpContext.Current.User = alarmnummerPrincipal

Zo, die staat. Als je nu in je Service Thread.CurrentPrincipal opvraagt krijg je netjes je eiegen principal te zien.
Je kunt je IPrincipal niet direct aan een uitvoerende thread hangen omdat niet gegarandeerd wordt dat een ASP.NET pagina geheel binnen dezelfde thread uitgevoerd wordt. Door em aan de HttpContext te hangen weet je zeker dat evt. andere threads ook het goeie principal bevatten.

Ik begreep verder niet precies wat je met de Session bedoelde. De ASP.NET Session? Deze moet je sowieso niet gebruiken voor security gerelateerde zaken want daar is de HttpContext voor.

Ik ben verder niet op zoek naar andere oplossingen.. ik wil gewoon dit aan de praat krijgen. Ik heb weinig tijd en weinig zin om het aan te gaan passen. Lees mijn verhaal aub goed want ik heb met .NET continu het gevoel dat niemand in staat is antwoord te geven op mijn vragen.

Nou nou, misschien komt het ook door de manier van vragen stellen. Je benadert de materie zoals je met Java gewend bent en dat vinden .NETters gewoon een beetje vreemd .

[whoami]

Zoals ik je al gezegd had Alarmnummer:
in de authenticate_request dus je Principal gaan zetten.

Echter, daar heb je nog geen session-state tot je beschikking, dus moet je wel met die authentication-tickets aan de slag.
Toch zou ik wel eens willen weten welke soort van authentication je nu eigenlijk gebruikt. (Wat is er in je web.config gespecifieert)?

[Alarmnummer]

whoami schreef op dinsdag 28 december 2004 @ 12:16:
Zoals ik je al gezegd had Alarmnummer:
in de authenticate_request dus je Principal gaan zetten.

Echter, daar heb je nog geen session-state

Wat is dat?? Session state?? Ik weet wat een session is, en ik ken het begrip state. Maar wat is Session state? In een Session staat al State, dus waarom zou je daar nog een statevoller iets van willen??

tot je beschikking, dus moet je wel met die authentication-tickets aan de slag.

Heb ik nog nooit van gehoord en ik denk niet dat ik ze nodig ben. Ik ben nu afgezien van het setten van de principal bijna klaar. Ik heb geen behoefte van sidetrack oplossingen. Ik heb een probleem.. dat moet zo snel mogelijk opgelost worden.

Toch zou ik wel eens willen weten welke soort van authentication je nu eigenlijk gebruikt. (Wat is er in je web.config gespecifieert)?

Helemaal niets. Ik check de IPrincipal op mijn Service (voor jullie je BL) objecten en daarmee moet de kous maar af zijn imho.

Verder werken wij met Maverick. Dus ik weet niet in hoeverre of dat met elkaar te verenigen valt.

[ Voor 10% gewijzigd door Alarmnummer op 28-12-2004 14:27 ]

[whoami]

Alarmnummer schreef op dinsdag 28 december 2004 @ 14:08:
[...]

Wat is dat?? Session state?? Ik weet wat een session is, en ik ken het begrip state. Maar wat is Session state? In een Session staat al State, dus waarom zou je daar nog een statevoller iets van willen??

Session, session state, whatever.

Heb ik nog nooit van gehoord en ik denk niet dat ik ze nodig ben. Ik ben nu afgezien van het setten van de principal bijna klaar. Ik heb geen behoefte van sidetrack oplossingen. Ik heb een probleem.. dat moet zo snel mogelijk opgelost worden.

Het is geen side-track oplossing, het is iets dat je gewoon nodig hebt om je principal te kunnen 're-construeren' zo je het wil noemen.
Zie de post van WooTz

[Alarmnummer]

whoami schreef op dinsdag 28 december 2004 @ 15:04:
[...]
Session, session state, whatever.

Ok.

Het is geen side-track oplossing, het is iets dat je gewoon nodig hebt om je principal te kunnen 're-construeren' zo je het wil noemen.
Zie de post van WooTz

Waarom zou ik dat willen? Ik bouw mijn principal op, op basis van roles beschreven in de database. En daarna kan IIS het serializen/deserializen (als hij dat nodig vind). Daarom waarom zou ik het nog een keer willen opbouwen?

En waarom mag ik niets (belangrijks) opslaan in de Session en waarom moet het in de HttpContext? De session is gemaakt om dingen in op te slaan, dus waarom niet gebruik maken van deze functionaliteit? Dit is het doel van de session... dingen in opslaan... ik kan dus geen perfecter object bedenken dan de session.

[ Voor 29% gewijzigd door Alarmnummer op 28-12-2004 15:10 ]

[whoami]

Alarmnummer schreef op dinsdag 28 december 2004 @ 15:08:
[...]

En waarom mag ik niets (belangrijks) opslaan in de Session en waarom moet het in de HttpContext? De session is gemaakt om dingen in op te slaan, dus waarom niet gebruik maken van deze functionaliteit? Dit is het doel van de session... dingen in opslaan... ik kan dus geen perfecter object bedenken dan de session.

Ik zeg toch niet dat je het niet mag opslaan in de session ?

Je kan het gewoon niet opslaan in de session, omdat de 'session state' afaik nog niet beschikbaar is in de 'authenticate-request' method; en dat is de method die je nodig hebt om je principal te reconstrueren.

[Alarmnummer]

whoami schreef op dinsdag 28 december 2004 @ 15:11:
[...]


Ik zeg toch niet dat je het niet mag opslaan in de session ?

Jij niet, maar iemand anders in dit topic.

Je kan het gewoon niet opslaan in de session, omdat de 'session state' afaik nog niet beschikbaar is in de 'authenticate-request' method;

Hoezo? Misschien is die sessie al een uur geleden voor de user aangemaakt. Als die een uur geleden is ingelogt (en de session heeft nog geen timeout) dan zit dat object er nog steeds in. Als de session is geserialized, kan het eventueel ook nog gedeserialized worden.

De session is er dus al (lijkt mij).

en dat is de method die je nodig hebt om je principal te reconstrueren.

Reconstrueren???? Je kunt session.Items["principal"] doen... taadaa... er hoefts imho niet gereconstrueerd worden, want het is er nog steeds.

[ Voor 3% gewijzigd door Alarmnummer op 28-12-2004 15:40 ]

[Not Pingu]

Misschien begrijp ik het wel verkeerd, maar kun je niet gewoon in de Session_Start event de security principal in de session hangen? Je kunt daar afaik zowel de session als de context object aanroepen.

[whoami]

Alarmnummer schreef op dinsdag 28 december 2004 @ 15:39:
[...]

Reconstrueren???? Je kunt session.Items["principal"] doen... taadaa... er hoefts imho niet gereconstrueerd worden, want het is er nog steeds.

Wat is je probleem dan ?
Als je dat kan doen, dan heb je je principal toch ?

[whoami]

Gunp01nt schreef op dinsdag 28 december 2004 @ 15:46:
Misschien begrijp ik het wel verkeerd, maar kun je niet gewoon in de Session_Start event de security principal in de session hangen? Je kunt daar afaik zowel de session als de context object aanroepen.

De session_start wordt voor iedere sessie slechts 1x aangeroepen; dat is dus niet goed.

[gorgi_19]

whoami schreef op dinsdag 28 december 2004 @ 15:51:
[...]


De session_start wordt voor iedere sessie slechts 1x aangeroepen; dat is dus niet goed.

Dan kan je het in BeginRequest regelen

[Alarmnummer]

code:

    public class RestoreCurrentPrincipalModule : IHttpModule
    {
        
        public RestoreCurrentPrincipalModule()
        {
        }
        
        public void Init(HttpApplication context)
        {
            context.BeginRequest += new EventHandler(RestoreCurrentPrincipal);
        }
        
        public void Dispose()
        {
            // TODO: Add AuthenticationModule.Dispose implementation
        }
        
        private void RestoreCurrentPrincipal(object sender, EventArgs e)
        {
            HttpApplication application = (HttpApplication)sender;
                        
            HttpContext context = application.Context;
            if (context.Session != null)
            {               
                IPrincipal principal = (IPrincipal) context.Session["principal"];
                Thread.CurrentPrincipal = principal;
            }
        }
    }

Volgens mij moet dit wel goed genoeg zijn.

[Skinny]

Hoe ik het nu (globaal) :

- Mijn BL checkt username/password en zet Thread.CurrentPrincipal naar mijn custom-principal-object.

code:

MyBusinessObject.Login(userName, password);

if( Thread.CurrentPrincipal.Identity.IsAuthenticated)
{
    Session["MyPrincipal"] = Thread.CurrentPrincipal;
    HttpContext.Current.User = Thread.CurrentPrincipal;

    //redirect
}

Aangezien ASP.NET niet met Thread.CurrentPrincipal werkt zet ik mijn principal dus in de HttpContext om hem binnen ASP.NET te gebruiken.

In Global.asax heb ik verder

code:

protected void Gobal_AcquireRequestState(object sender, EventArgs e)
{

    if( Session["MyPricipal"] != null )
    {
        // we zijn al ingelogd.

        // stel de threadprincipal in op mijn sessie principal
        Thread.CurrentPrincipal = (IPrincipal)Session["MyPrincipal"];
        // en ook in de httpcontext voor gebruik binnen asp.net
        HttpContext.Current.User = Thread.CurrentPrincipal;
    }
    else
    {
        // Als we wel authenticated zijn, maar geen sessie principal hebben, dan is er dus iets
        // niet goed gegaan, dan maar even opnieuw inloggen.
        if( Thread.CurrentPrincipal.Identity.IsAuthenticated )
        {
            System.Web.Security.FormsAuthentication.SignOut();
            Server.Transfer("Login.aspx");
        }
    }
}

[ Voor 3% gewijzigd door Skinny op 28-12-2004 16:02 . Reden: net te laat :( ]

[whoami]

Just a silly question:
waarom doe je dat in een custom module, en niet in de global.asax ?

[Not Pingu]

whoami schreef op dinsdag 28 december 2004 @ 15:51:
[...]


De session_start wordt voor iedere sessie slechts 1x aangeroepen; dat is dus niet goed.

Ja nou en? je hoeft die IPrincipal er toch maar 1x in te hangen? Of snap ik het probleem niet? De IPrincipal blijft toch hetzelfde gedurende een login? Tenzij ie tussendoor gewijzigd wordt, maar dan lijkt het me geen probleem om de veranderde IPrincipal weer opnieuw in de session te pleuren

[whoami]

Als je forms authentication gebruikt (of windows auth, of passport auth) wel ja (althans, dat dacht ik ook).

[Verwijderd]

je schrijf nu alles zelf terwijl .NET dit ingebouwt heeft. In je web.config neem je je security params op, je beveiligt je files daar etc... misschien zelfs impersonation. En .NET handelt het meeste met IPrincipal af.

Hij maakt hem aan, maakt de ticket, beveiligt deze met 3DES and valideert hem per request. Als je roles wilt gaan gebruiken, dan haal je die op in je DB, voegt ze toe aan de Context.User, maar dat zal je moeten doen in je HttpApplication zoals ik boven al zei. Als je alles in je BL gaat checken, is dat wel leuk maar een beetje nutteloos werk.

Ook is dit geen sidetrack maar de gewone manier van zaken, ik verwijs je naar de ASP.Net website met de tutorials daar. Daar staat simpel uitgelegt wat jij wilt doen.


bij forms auth moet je hem wel zelf terug hangen als je er roles in stopt. Maar bij windows auth niet. Ten minste dat zegt mijn boek

de code die ik eerder poste werkt prima

[Alarmnummer]

Verwijderd schreef op dinsdag 28 december 2004 @ 16:11:
je schrijf nu alles zelf terwijl .NET dit ingebouwt heeft. In je web.config neem je je security params op, je beveiligt je files daar etc... misschien zelfs impersonation. En .NET handelt het meeste met IPrincipal af.

Hij maakt hem aan, maakt de ticket, beveiligt deze met 3DES and valideert hem per request. Als je roles wilt gaan gebruiken, dan haal je die op in je DB, voegt ze toe aan de Context.User, maar dat zal je moeten doen in je HttpApplication zoals ik boven al zei. Als je alles in je BL gaat checken, is dat wel leuk maar een beetje nutteloos werk.

Je business logic (of eigelijk de service layer) die is verantwoordelijk voor de security. Niet je weblayer. Dat is imho een hele verkeerde benadering.

Verder willen we de .NET applicaties nagenoeg gelijk opbouwen aan Java apps. Scheelt weer een hele lading uitzoek werk en vorm 1 manier van programmeren. Dat je als die hard .NETTER hier problemen mee hebt interesseerd me niet zoveel. Ik kies voor de goedkoopste oplossing en dat is qua onderhoud/opbouw gewoon 1 stijl van ontwikkelen. En dat het niet de .NET way is... dat maakt mij niet zoveel uit omdat wij voornamelijk Java apps ontwikkelen.

Ook is dit geen sidetrack maar de gewone manier van zaken, ik verwijs je naar de ASP.Net website met de tutorials daar. Daar staat simpel uitgelegt wat jij wilt doen.

Als dit werkt hoef ik geen andere oplossing meer.

bij forms auth moet je hem wel zelf terug hangen als je er roles in stopt. Maar bij windows auth niet. Ten minste dat zegt mijn boek

de code die ik eerder poste werkt prima

Moet je wel met forms werken en waarschijnlijk gaat het problemen opleveren met maverick.

[ Voor 17% gewijzigd door Alarmnummer op 28-12-2004 16:20 ]

[Alarmnummer]

Alarmnummer schreef op dinsdag 28 december 2004 @ 15:59:

code:

    public class RestoreCurrentPrincipalModule : IHttpModule
    {
        
        public RestoreCurrentPrincipalModule()
        {
        }
        
        public void Init(HttpApplication context)
        {
            context.BeginRequest += new EventHandler(RestoreCurrentPrincipal);
        }
        
        public void Dispose()
        {
            // TODO: Add AuthenticationModule.Dispose implementation
        }
        
        private void RestoreCurrentPrincipal(object sender, EventArgs e)
        {
            HttpApplication application = (HttpApplication)sender;
                        
            HttpContext context = application.Context;
            if (context.Session != null)
            {               
                IPrincipal principal = (IPrincipal) context.Session["principal"];
                Thread.CurrentPrincipal = principal;
            }
        }
    }

Volgens mij moet dit wel goed genoeg zijn.

Hier gaat nog wel iets in fout. De Thread die de events afhandeld is niet dezelfde als de thread die de request inhoudelijk gaat afhandelen. Ik loop de principal dus op de verkeerde thread te zetten.

[gorgi_19]

Hoe maak je de thread aan? Als je die aanmaakt dmv een Timer-class, kan je HttpContext meegeven als parameter en deze in de thread gebruiken.

[Alarmnummer]

gorgi_19 schreef op dinsdag 28 december 2004 @ 16:42:
Hoe maak je de thread aan? Als je die aanmaakt dmv een Timer-class, kan je HttpContext meegeven als parameter en deze in de thread gebruiken.

Threads aanmaken? Ik hoop dat ik dat niet hoef te doen. Ik hoop dat IIS al deze probematiek voor mij oplost en fijn een thread pool met httprequest afhandelende threads heeft klaarliggen waar zo nu en dan een uit wordt gepakt om request af te handelen.

[ Voor 5% gewijzigd door Alarmnummer op 28-12-2004 16:46 ]

[Verwijderd]

in jouw functie is sender ook geen reference naar de httpapplication, maar dat is mijn gedachte. Maar opnieuw, waarom vang je dit niet op in je global.asax, en waarom gebruik je niet de standaard .NET features? Het is misschien 10% anders, maar je bent er in 5 min klaar mee om het opzetten, en dan overdrijf ik niet.

[Alarmnummer]

Verwijderd schreef op dinsdag 28 december 2004 @ 18:29:
in jouw functie is sender ook geen reference naar de httpapplication, maar dat is mijn gedachte. Maar opnieuw, waarom vang je dit niet op in je global.asax, en waarom gebruik je niet de standaard .NET features? Het is misschien 10% anders, maar je bent er in 5 min klaar mee om het opzetten, en dan overdrijf ik niet.

Het probleem is dat we werken met maverick en niet met forms. Ik weet dus niet hoe goed dit zich laat vertalen.

[Verwijderd]

je kan toch wel 2 waardes ophalen? oftewel een username en een password en die door de FormsAuthentication class heenhalen? Daarna is 'forms' meer een begrip dan iets anders.

Opnieuw, check even de tutorials op www.asp.net dan zie je wat ik (we) bedoelen.

[whoami]

Alarmnummer schreef op dinsdag 28 december 2004 @ 18:41:
[...]

Het probleem is dat we werken met maverick en niet met forms. Ik weet dus niet hoe goed dit zich laat vertalen.

Normaal gezien zou dit geen verschil mogen maken.
Security zou toch moeten losgekoppeld zijn van de webserver; als dit wel een probleem zou vormen, dan heeft MS wel problemen als ze .NET willen profileren als platform onafhankelijk. (Dit zou dan willen zeggen dat mono ook niet volledig .NET kan ondersteunen).

Forms Authentication gaat gewoon een cookie zetten met een authentication ticket, dus ik zie niet in wat de webserver daar voor problemen zou kunnen mee hebben.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 19:08 ]