ASP.NET Login Control - Is it possible to extend it with custom data? - asp.net

I'm currently developing an ASP.NET website, and I'm using ASP.NET's built-in Login control with client-side cookie generation for state management.
Unfortunately, as I didn't figure out how to append custom information (generated by other controls on my application) to the Login control self-generated cookie, my application generates an additional cookie to store that additional info. Basically, I have two cookies: one managed by the Login control and another managed by me, programatically.
What I would like to know is if it's possible to merge my additional information into the infrastructure's Login control self-generated cookie. This would prevent some issues with the "sliding timeout" feature that could result on my "custom cookie" expiring with the user being logged in - I could solve this one with a custom HTTP Module to prevent it, but that seems to me as an "inelegant" solution.
Any brilliant mind could help me out with this?
Thanks in advance for your attention and support.

Yes, you can store data in the UserData property of the authentication ticket. Please see the section "Storing the Username of the Admin User Who Logged On As Another User" at https://web.archive.org/web/20210304120451/https://www.4guysfromrolla.com/articles/102208-1.aspx
However, you might find the User Profile system to be more useful. https://web.archive.org/web/20211020111657/https://www.4guysfromrolla.com/articles/101106-1.aspx

Related

Not handling authentication, but need claims and cookie

I am creating a new asp.net MVC 5 application. Authentication is handled by a third party using smart cards. Once a user is authenticated by the third party, I am sent the user's unique ID (inside the http header) which I match up against my database in order to find relevant information about said user (roles, display name, etc.).
Currently, on every page request, the sent user ID is compared against the database, and checks are performed to ensure the user has the proper permissions to view the requested page. While this works, it sure seems like a bunch of needless database hits when all the user information could just be stored in a cookie.
If I was using Individual User Accounts for authentication, what I am looking to do would simply be built in using Identity and OWIN. But since I am not handling the authentication, but merely the authorization, is there a way to use all the nice features of Identity and OWIN (claims and cookies specifically)? If not, how might one go about this?
Also, of particular interest to me is when a role is added or removed. Using OWIN with Individual User Accounts, updating the cookie is as simple as logging the user out, and then back in immediately in the background. That functionality would also be desired for any solution presented.
Any insight would be extremely helpful. Thanks for reading!
You could do what you're asking by directly storing values in a custom cookie, but for your purposes it sounds to me like you might be more interested in utilizing sessions to track that info. This will keep all of your actual data stored server-side, which is more secure as it isn't vulnerable to cookie modification and it allows you more freedom to control the state (for your role example, you wouldn't have to "update" the cookie at all, just update the session variable on the server side to add or remove the role as needed).
Figured it out. Found a great article that really helped:
http://www.khalidabuhakmeh.com/asp-net-mvc-5-authentication-breakdown-part-deux

Impersonate a membership user in ASP.NET

In a generic asp.net website with Membership, Roles and hashed passwords enabled, I would like to provide the administrators with impersonation so that they may browse the website as that user would. The website should function as if that user is logged on and then be able to revert to their own login.
What is the best approach to achieve this?
An example use-case: A website with two types of users: 'Buyer' and 'Admin'.
The website provides a 'Purchase' button to buy something specifically provided to the user by the admins. i.e only that buyer can use the purchase button and make a payment.
User has trouble so a support admin can 'impersonate' the user's login and purchase on their behalf or 'see' the trouble they are facing.
Without impersonation, the only way is to allow this in code and that negates the purpose of 'seeing the user's issue'. Not even if I was not using hashed passwords and had used FormsAuthentication.SignOut() and manually logged in the admin as the user.
I hope i am making sense above.
Take a look at this sample on codeproject.com. I think it does what you're looking for.
I don't have the code we used to do this in front of me (assignment from a few years ago), but there are bits in the Membership API to sign someone in using code. I will not have access to the code until this weekend, unfortunately, or I could quickly share the bits and be done with this.
I do remember you had to get the user first, as a MembershipUser, using the Membership class. I am not sure, from this point, whether you had to validate against provider or what.We did use a custom provider, but I forget whether it was related to this solution.
Regardless, examine the security bits, focusing on membership and membershipUser.

How to implement session like stackoverflow?

I'm implementing this kink of login: http://jaspan.com/improved_persistent_login_cookie_best_practice
In this design a new token issued to the user each new login.
So it tells me that I need to
Now I need to implement a session, for this login.
I'd like to implement session like stackoverflow, so people can have session as soon as they entered the site, so they don't must to register.
Any ideas how?
I'm going to take a complete stab in the dark here and assume "have a session without a login" is referring to StackOverflow's use of OpenID, which enables you to share one set of login credentials across websites. The user still has a session, but it's the OpenID provider who does the authentication.

How to loggedin in LinkedIn automatically from Asp.net Application?

I have created a username and password to enter and search people in linkedin. Now, I am devloping a web application using asp.net. I need to open a popup page which is displaying the searched results in linked in as logged in.
When the popup page is displaying, I need to logged in automatically using the username and password.
So, here is my question,
How to logged in automatically when the button clicked in Asp.net application using linked in username and password?.
Thanks
The problem is twofold:
deciding which credentials to use
actually logging in
Logging in is fairly straightforward: post to LinkedIn's login URL in the manner that LinkedIn expects. Unfortunately, LinkedIn still does not have a public API, so this is going to require hackery. Go to a LinkedIn web page that allows login and analyze the page source. There will be a field names for username and password in the login form, and the login form will post to a specific URL. Duplicate the username and password with a web request to the URL of the form. You will receive a cookie as part of the response. Make sure you include that cookie in future requests to LinkedIn and you are then "logged in" for every request.
Of far more importance than the actual logging in, which is a simple programming challenge, is deciding which credentials to use. I'm guessing that you're building an application for others to use, rather than yourself. If so, you'll need to ask them to give you their LinkedIn credentials. Beware: this is something that most people simply will not do. It's a trust issue; if they give you their credentials, you now have access to their profile and can do nefarious things with it. You'll need a good disclaimer explaining how you would never do that, ever, and you'll need the people who read it to believe you. Not as easy as it sounds.
If, however, this is just for you, you're on easy street. Just use your own credentials.

ASP.NET, OpenID and registration confusion

I have managed to get all the authentication parts working, however i am confused about setting up registration.
By registration i mean that if the OpenID is not attached to an existing account, then a new account must be created.
Should i simply have it return to a registration page (with from fields for registration) and redirect to a different page if the user is registered?
Is there a way to set up a clean and simple registration flow without signing the user in first (formsauthentication.redirectfromloginpage) then checking if they are new on every page?
Sorry if this is worded badly, like most other things i ask it is difficult to explain!
Thanks
Ideally, no registration is required at all beyond simply an OpenID. Does your site require to know more than a user identifier to provide any functionality at all?
If your site can offer any services to users (even just informational) without asking for more than their identifier, which OpenID supplies, then don't have a registration page at all. This is by far the best for the users and will lower the barrier of entry to new users to your site. Then, when the user accesses a page that offers something that requires the user to give up more information about themselves, stick them with a registration page at that time.
If you must stick up a registration page for all new users, I suggest you do a check every time someone logs in with their OpenID. If you recognize the OpenID Claimed Identifier upon successful login, you just let them through... otherwise you create a database entry for them and redirect them to the registration form.
You can optimize the experience by using OpenID extensions such as Simple Registration or Attribute Exchange so that the user might get a pre-filled out registration form courtesy of the OpenID Provider, further streamlining the registration process.

Resources