C# - Authenticate AD user on public page - c#

I want to display the start page of my web application in one way if the visiting user is authenticated in the AD and another way if the user is not.
I am able to distinguish users by checking their username using this: HttpContext.Current.User.Identity.Name
However, this only works after the user has tried to access a secured page and I want to know this when a user visist the public start page. Any ideas of how this can be done?

If you don't have Authentication you can't know which user is it. So I guess you can set cookie/localStorage for the next time he will get to the page.
OR
What I think will be preferable when using AD, you can provide sub domain for those users, so each time someone is coming from this sub domain you will know he is AD user.

Related

Pass WindowsPrincipal user to another web application shown in iframe

I dont know if its possible, but ....
On first site the user is authenticated using active directory and got WindowsPrincipal user.
Then in iframe will shown a second site. How to pass an object User or credentials of authentication to second site?
How to authenticate the user with the same credentials?
Thanks
You are searching for SSO (single sing on).
It depends on how you make your authentication in application, so it's hard to advice you.
But if you want to understand problem you could start from this article.

How to restrict user from same Username and Password to logic from two system/browser in asp.net mvc 4.0?

I've created a asp.net mvc4 web site. I've implemented Form authentication also.
In this web site i want to block access to my web site client in a same time (if a client of my website is already open his or her account in a computer then that client can not get any permission to open that same website on the same time in other computer or any other browser of the same system).
I want to provide one paid service to user, and I don't want him to just share his username and password with many people to use my service simultaneously without paying for it. please help me soon
How can I implement this. do i need to maintain some login information in database or is there any built in tool available for this.
To my knowledge there is nothing built in, but you may be able to implement your own version of the ASP.NET authorization providers.
Upon successful login you would need to store the value of the FormsAuthenticationTicket in your database and associate it to your user record.
On every page load you would need to check the value of the ticket against the database record for that user. In case of mismatch the user would be logged out.
Using this approach if User A and User B were using the same credentials, User A was logged in and if User B then logged in, it would invalidate User A's session and they would not be able to view content at the same time. You could also log the activity when a session is overridden, along with IP address and User Agent to help you identify users that are sharing account details.
This feature is not built in.
I would add an "IsLoggedIn" bit column to my "User" table. Then you could check this column to see if the user should be allowed in.
The problem is going to be knowing when that flag should be set to false. It's easy enough to set the flag to false if the user clicks "logout" or in the "on session end" event, but I think you'll run in to cases where that's not good enough. For example, if a user logs in from a laptop and the laptop's battery fails, you aren't going to get any notification from the client that the user has left...
I think David has already given most of the idea (+1) , However for problems like closing browser without logging out, You can handle it in window.unload() event for setting the flag in your table .

ASP.NET Implementing "Act As" functionality when using Windows Authentication and Custom Role Provider

I'm trying to implement "Act As" functionality for an ASP.NET application while at the same time using Windows Authentication and a custom role provider. Essentially what I want to be able to do is:
Use Windows Auth to get the current user's domain account to verify they are an approved domain user
Use a custom role provider to get permission information from a SQL Server database.
Implement functionality to allow the admins of the application to be able to "act as" another user, without requiring them to actually log into the application as that user.
The scenario I'm trying to fulfill is that an application admin is attempting to assist a user with a problem and clicks the "act as" button to act as that user and see the application as they would see it. So the Role Provider would need to understand that the current user is acting as someone else and get permissions information for that user instead of the current user.
My plan was to implement an impersonation feature that would delete the roles cookie and add a value to a session variable indicating that the user is currently impersonating another user. As the session is not populated at the time that authorization occurs however, this isn't possible. I don't want to use cookies as I don't want this to cause a potentially persistent state on the admins machine (such that the admin couldn't open another window to the app and either act as another user or view their own data).
I can't find a good way (without cookies) to save the "Acting as user..." information given that the session is unavailable. I'd like to use the role provider, etc., so that I can leverage the built in security trimming in .NET. This all may simply be impossible, but I'm hoping someone out there has either tried this before or has a suggestion for something I can attempt to implement.
Thanks in advance!!
See my answer to a similar question here
The gist of it is:
The way I did this, which is admittedly a little crude, was to have an
impersonation table in my database which contains the logon name of
the user who is doing the impersonating and the logon of the user they
wish to impersonate.
I added some override code so that when the user first goes to the
page (it uses Windows authentication), it will check to see if that
user has an impersonation set in the table and then place this user id
in an object in the session state. If there was no impersonation, it
would place the actual user id in this same object.
To prevent me from doing things to the user's data as them, there are
two properties in this object, one for logon_name, which is what is
used by the system for content-customization, and another called
NameForLog, which is used when logging any actions. All actions I make
will be logged as me.
All areas on the site that display user-customized content look at
this session object, so they will always use the impersonated ID and
therefore always show me what the user is seeing. Beyond the first
page and the logging code, it doesn't even know that it is me it is
dealing with.
For your scenario, you could implement a roles provider and override GetRolesForUser to return the roles for the impersonated user plus some role that will allow the impersonating user to access the impersonation functionality for the purposes of turning it off.
You could even return the impersonated user's roles with the impersonating user's roles in order to give the admin user access to all of their own features as well as the user they are impersonating, it all depends how much this would affect the usefulness of the feature in your particular scenario.
I have implemented something similar...though not exactly like your scenario but pretty close.
Admin Login (Has one role like Admin)
Then admin is redirected to "Select Client" Page. Admin can search Client by ID, Name, etc. From the list Admin selects a Client. I store the client ID in a cookie.
I have custom RolesProvider that calls my custom GetRoles(loggedinUserid);
GetRoles(int loggedinUserId) method then determines the type of the user i.e. if it's Admin or non-admin. If it is admin then, fetch ClientID from cookie. Pass loggedInUserID, typdofuser and ClientId to the stored procedure that will return all roles for the admin + all roles for that ClientId and return to roles provider.
This way I have all my menuitems for Admin available as well as menus needed for ClientID.
Admin can go to "Select Client" page anytime and switch to another client. When they select a client, new ClientId will be stored in the cookie.
Now you have two options after this:
You can let rolesprovider call this upon every request or
Store the fetched roles in HttpCache and update this cache whenever ClientId is changed.
Hope this helps.

Login by pass using C#.net program

My goal is to provide a link to customer, when a customer clicks the link he/she should be automatically logged in to this new site(external website not controlled by our company) using their logged in AD credentials.
FYI, the logged in credentials match the login name on this external website and the password will be the same for all. So, I can safely hardcode the password in my program.
Now what I was thinking was to write a C# program that will complete the authentication process for the External website and returns back the page that is received after login.
My analysis:-
1) When I first visit the page http://website2/default.aspx, it returns back a login page with username, password and submit button.
I also noticed that it is returning a session id.
*ASP.NET_SessionId=i0j3d155mxxkuyr3fedp00yf*.
2) Later, when I enter username, password and click the submit button.
It is creating a query string as such
user=adf&password=adsf&buttonName=Login+%21
I think it is using an HTTP Post call.
Can you please help me this!!!! Please, if possible provide me with a code that I can refer to and make changes to acheive this.....
Thanks a lot for looking....Any help is appreciated.....
You're not going to be able to do this since there is no way to retrieve a password from AD. The only way this would be possible is if there was a trust relationship between the external site and yours and it sounds like this is not the case (please correct me if I'm wrong!).
You'll need to have the user manually enter authentication and marshal that information to the external site, which is really no better than just having the user authenticate directly to the external site.
On a side note, it's rarely the case where you can safely hardcode a password in a program. Just sayin. Also, if you're getting a query string that you can see in the browser's address bar then it's not using POST, it's using GET.

How to check if someone is a user?

I'm designing a website (ASP.NET, c#), in which you can see the controls, but you can only use them after you've logged in (for example, you can see a list of games, but you can only place a bet after you've logged in, so if you try to place a bet when you are not logged in, the site should redirect you to the login page).
All said, my problem is this: How can you tell, if a certain user is logged in, BEFORE he types in his credentials?
He his not a user yet right? For me he is just someone that is browsing my website.
If the user is logged in then Request.IsAuthenticated is true. When the request is authenticated, the User.Identity.Name property is set to the user's username. Before the user is authenticated there is no way to tell who the user is. You can, via some javascript code, find out what that person types into your Username textbox, but until the password is validated, you can't be sure it is that user.
You need to research cookies and query the database based on cookie settings.
If someone has not logged into your site ever before, there is no way to tell whether he/she is a a user. The most widely used authentication mechanism for ASP.NET is Forms authentication which returns an authentication cookie to the user's browser which subsequently accompanies all requests by that user so it can be used to track who that user is and that he is authenticated for the current session (also see "Understanding the Forms Authentication Ticket and Cookie").
You could use a separate, long lived cookie to just identify the user's name which then would be (usually) also available after the user has logged out. When that person visits your site you can at least use the name to remind him/her to log in.

Categories