When exactly are you logged in? (Forms authentication)

[Lauchlan M]

Hi.

For forms authentication, the standard way to go would be something like

<<

1. Get user name and password

2. Look it up against database store

3. Create an authentication ticket

4. Create an authentication cookie (based on the ticket)

5. Redirect as required/appropriate

6. In the Global_AuthenticateRequest event handler, code it something like:

<<

// private void Global_AuthenticateRequest(object sender, System.EventArgs
e)

// (if authentication ticket is recovered from a cookie or session
variable then:)

// pipe delimited string of role names.
string[] roles = authTicket.UserData.Split(new char[]{'|'});

// Create an Identity object
FormsIdentity id = new FormsIdentity( authTicket );

// This principal will flow throughout the request.
GenericPrincipal principal = new GenericPrincipal(id, roles);

// Attach the new principal object to the current HttpContext object
Context.User = principal;

// (else bounce them back to the login page)

>>

>>

Now, I don't want to use cookies (ie operate cookieless). If I created an
authentication ticket in my login.aspx, encrypted it (ie to a string) and
put it in a session variable and caught this session variable, decrypted it
and recreated the Context.user principal in in the
Global_AuthenticateRequest handler, would it be logged in at that point
(regardless of the fact that I never created any cookie)?

Thanks!

Lauchlan M

[Fredrik Normén NSQUARED2]

You can't use FormsAuthentication without cookie.
What you can do is to create your own Authentication
module, read this site:

[url]http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%[/url]
3B318786

/Fredrik Normén NSQUARED2
[url]http://www.nsquared2.net[/url]

>-----Original Message-----
>Hi.
>
>For forms authentication, the standard way to go would

be something like

>
><<
>
>1. Get user name and password
>
>2. Look it up against database store
>
>3. Create an authentication ticket
>
>4. Create an authentication cookie (based on the ticket)
>
>5. Redirect as required/appropriate
>
>6. In the Global_AuthenticateRequest event handler, code

it something like:

>
><<
>
> // private void Global_AuthenticateRequest(object

sender, System.EventArgs

>e)
>
> // (if authentication ticket is recovered from a

cookie or session

>variable then:)
>
> // pipe delimited string of role names.
> string[] roles = authTicket.UserData.Split(new char[]

{'|'});

>
> // Create an Identity object
> FormsIdentity id = new FormsIdentity( authTicket );
>
> // This principal will flow throughout the request.
> GenericPrincipal principal = new GenericPrincipal

(id, roles);

>
> // Attach the new principal object to the current

HttpContext object

> Context.User = principal;
>
> // (else bounce them back to the login page)
>

>>>

>

>>>

>
>Now, I don't want to use cookies (ie operate

cookieless). If I created an

>authentication ticket in my login.aspx, encrypted it (ie

to a string) and

>put it in a session variable and caught this session

variable, decrypted it

>and recreated the Context.user principal in in the
>Global_AuthenticateRequest handler, would it be logged

in at that point

>(regardless of the fact that I never created any cookie)?
>
>Thanks!
>
>Lauchlan M
>
>
>.
>

[Lauchlan M]

Hi,

thanks for the response.

> You can't use FormsAuthentication without cookie.

Well, how feeble is that?

Actually, I think you can, eg using the mobile internet stuff

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mwsdk/html/mwconauthenticationoptionsformobiledevices.asp[/url]
and
[url]http://support.microsoft.com/default.aspx?scid=kb;%5bLN%5d;Q311568[/url]

It's just that it's not easy, convenient, or a path I want to spend time
pursuing. For example, using the MobileFormsAuthentication instead of
FormsAuthentication doesn't let you just redirect with the authentication
ticket cookie taken care of (passed in the url query string), this is only
done when using RedirectFromLoginPage.

> What you can do is to create your own Authentication
> module, read this site:

> [url]http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B318786[/url]

Thanks for this. I've looked over it and it looks like too much overhead
getitng my head around another overly-complicated MS approach as a hack for
getting around their poorly thought out (in this regard) framework. But if
you have a link on the philosophy/idea behind this so I can make more sense
of this, I'll put it back in the list of options . . .

It's reached the point where I've spent too much time trying to fit in to
MS's authorisation schema, and just need to move ahead.

So I figure I'll try:

<<
(i) blowing away the web.config authorisation and authentication elements

(ii) In my login.aspx page, creating an "authenticated" session variable,
and checking for it in the global.asax "Global_AcquireRequestState" handler
and bouncing people back to Login.aspx if it's not there or not valid

(iii) when logging in in login.aspx, create another session variable for
userrole, and in the Global_AcquireRequestState handler, check the path
explicitly for secure directory names (eg "private", "admin" or whatever I
call them and check these manually against the relevant permissions defined
by the roles and bounce them if they dont meet the criteria.

At least I'll then implement the security I want, even if I can't manage to
do it Microsoft's way. The 'cost' would be two session variables per user -
"authenticated" and "role".

>>

If you see any problems with this approach, please let me know . . .

Lauchlan M