Externally provided username as identity?

Question

I have a couple of systems which uses external authentication, google authentication. I'm just keeping the login information in a session variable and keep track of the user that way (no membership provider).

I would like to have the user identity in the HttpContext.Current.User object. Should I assign the user manually on an event in Global.asax.cs, or could I have the user automatically identified during the session?

score 2 · Answer 1 · answered Aug 28 '11 at 19:35

You could write a custom Authorize attribute which will take care of assigning the HttpContext.Current.User property from the session:

public class MyAuthorizeAttribute : AuthorizeAttribute
{
    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        var user = httpContext.Session["username"] as string;
        if (string.IsNullOrEmpty(user))
        {
            // we don't have any username inside the session => unauthorized access
            return false;
        }

        // we have a username inside the session => assign the User property
        // so that it could be accessed from anywhere
        var identity = new GenericIdentity(user);
        httpContext.User = new GenericPrincipal(identity, null);
        return true;
    }
}

Then simply decorate your controllers/actions that require authentication with this custom attribute.

Session is very insecure because the session cookie is just a arbitrary token. You can force a specific session ID on someone relatively easily. Then if it's used for authentication you gain control of their account by using this token yourself. It's therefore better to use the authentication cookie which is an encrypted token specific to user and server. It's much harder to steal. — TheCodeKing, Aug 29 '11 at 11:23
@TheCodeKing, agreed that session ids are not secure and standard forms authentication should be used. — Darin Dimitrov, Aug 29 '11 at 11:39

score 1 · Accepted Answer · edited May 23 '17 at 11:43

1

Use a membership provider, it will give you exactly what you want. Even creating your own provider isn't too difficult, just implement the abstract class MembershipProvider and plug into config, or use some of the out-of-the-box providers.

Don't roll your own solution for something critical like security, it will have gaping security holes. Storing authentication info in the session is a really bad idea. It leaves it open to session hijacking, session replay attacks etc.

If you really want to go down the route of custom authentication. Then have a look at the code I posted here. It will show you how you can take control of the authentication cookie, and use this to create your own HttpContext.Current.User instance.

edited May 23 '17 at 11:43

Community

1
1

answered Aug 27 '11 at 00:20

TheCodeKing

19,064
3
47
70

1

Well, just using the membership provider doesn't make it more secure. The built in forms authentication uses cookies which are vulnerable to replay attacks. – Carl R Aug 28 '11 at 17:22
Yes absolutely but it's no reason to throw it out. Forms authentication is still more secure, tried & tested, and robust than almost any home rolled solution. The roll your own approach is really a bad idea. Rather build on FormsAuthentication to protect against session replay attacks, and session hijacking etc. Most of these are well documented in terms of mitigation by building within the framework. Session is much more vulnerable to attack than cookie based forms authentication. – TheCodeKing Aug 28 '11 at 18:27
I added a link to some code which shows how you can manage the authentication cookie yourself if you so wish. It might be more what you are looking for. – TheCodeKing Aug 28 '11 at 19:13
You can use the forms authentication token bits without writing a membership provider. Once you do that the user will be populated into the user property as a forms auth user without you having to do anything. – blowdart Aug 28 '11 at 19:38

Externally provided username as identity?

2 Answers2