I have one asp.net web application, but two different domains point to this web app. For instance: www.one.com and www.two.com both point to the same web app.
I have an issue where I need certain pages to be on a specific domain (due to some security requirements from our online payment provider - a third party website). So let's say page1.aspx needs to be called on www.two.com
The process is as follows:
A user logs into www.one.com
The authentication cookie is saved to the browser
The user then navigates to page1.aspx and, if on the wrong domain, gets redirected to the correct domain. (this redirection happens on page1.aspx in the page_load event)
Then asp.net redirects the user to the login screen, because the authentication cookie is not sent to www.two.com.
How can I track the user and keep him/her logged in between the two domains?
Related
I have been tasked with integrating single-sign-on for an existing application, so I've been working on a couple of demos. The first one was the standard demo for Spring Security and I got that working. Now I'm trying to do a proof-of-concept demo where I created a toy version of the application in question with only two screens: one for login, and one to display some information about the user that logged in. I want to integrate SSO with this application so that the user has two ways to be authenticated: either by entering credentials directly in the login screen or by a SSO SAML request...
So I copied over SAML libraries and configurations from the standard SSO demo into my proof-of-concept application, and I seem to have SSO working, albeit a bit too well, in that I'm no longer able to get to my login screen, i.e., I still want that to be the default behaviour for someone entering the base URL for the application. How do I have to configure my application to achieve this?
The way I solved the problem was by changing the Spring Security configuration so that instead of using the generic /** to require SSO authentication for most pages of the application, it nows only requires such authentication for a single HTML page, sso.htm. This "page" is really translated by the application as a request to a controller that handles the application-specific processing for an SSO request. The initial page for the application, redirect.jsp, now contains some logic to pick which page a user should be redirected to, based on whether he or she got to that page directly (i.e., by typing in the default URL for the application) or via a SAML message from a trusted identity provider.
Note: For this to work, the initial page cannot be designated in the Spring Security configuration as either a secured or unsecured page. If it were secured, then this page could only be accessed after an SSO authentication, so a user would be thwarted from doing a non-SSO login. If unsecured, then the security context would not be accessible from that page, so the page logic would be unable to determine if the user in question has SAML credentials and an SSO authentication request for the application could never be fulfilled.
Once the user has been authenticated, either by credentials entered in the login screen or by an SSO request, from that point on, the application's continuing authentication of that user to view its pages is the same, i.e., no further SSO authentication is done. But when the user logs off from the application (or is logged off due to a session timeout), a check is made then to see if SSO authentication was done for this user. If so, then in addition to being logged out from the application, a local SSO logout is also done for the user, i.e., the SSO authentication session for the application is terminated, but the user remains logged in with his or her identity provider. So such a user could log back into the application in question, either directly via the application's login screen or by having the identity provider issue a new SAML message.
Hope this helps someone else...
I have tried my best to search the web before asking this question. I've seen similar questions on stackoverflow, however, none has been answered satisfactorily for a long time now. This is one more attempt to get this recurring question answered.
The Problem
How to build an ASP.NET MVC 5 website which uses "Windows Auth" for Intranet users and "Forms Auth" for Internet users? We'd like to accomplish this using ASP.NET Identity. Moreover, we don't want to use Active Directory Groups for authorization. For Intranet users, we want to authenticate them using Active Directory and then fall back to ASP.NET Identity to manage their roles and other profile data.
It'll be nice if we don't ask the end user to choose auth method. The web app should log in intranet users seamlessly. They shouldn't even know that there is a login screen. Likewise, the internet users shouldn't be asked to enter their domain credentials. They should see form based login screen right away.
Is there any recommended way of solving this? Or could you comment if any of the following are proper solutions?
http://world.episerver.com/blogs/Dan-Matthews/Dates/2014/8/Mixing-Forms-and-Windows-Authentication/
https://github.com/MohammadYounes/MVC5-MixedAuth
http://mvolo.com/iis-70-twolevel-authentication-with-forms-authentication-and-windows-authentication/
FYI This is 2004 article, may not be helpful now:
https://msdn.microsoft.com/en-us/library/ms972958.aspx
IIS configuration
Enable Anonymous Authentication status in IIS for the whole site and Windows Authentication for some folder under root directory (for example, /WindowsLogin). In this folder place aspx file (for WebForms project) or create ApiController (for MVC project).
Site setup
On login page add button “Login with Windows/ActiveDirectory account” (in similar way as it is common practice to add buttons Login with Twitter, Facebook, Gmail, etc.). When user presses this button, they will be redirected to the page or controller in /WindowsLogin folder, which require Windows authentication. If site uses some Single Sign-On functionality, locate it in that page or controller, in other case just save Session for Windows users there. If user accessed that page or controller, they had been authenticated as Windows users already.
One of the possible ways could be creating two sites in IIS, but having the same target folder, where sources of site are located. First site is for internal users with enabled Windows Authentication mode and binding to 80 port, while second site is for external users with Anonymous mode enabled and binding to 8080 port, for example. Then, on firewall you will have to configure NAT, that all requests coming from within local network or VPN, will be redirected to local IIS server on port 80 and all requests coming from Internet, will be redirected to port 8080 of IIS server.
The term for this is Mixed-Mode Authentication. I have done this multiple times. You only need to tweak your main site. Here is how I have done it.
Keep your main MVC site as-is but run it as Anonymous vs. under Windows Auth.
Internal Site
Create a Redirect URL Site: Setup this site as Window Auth so you can pull the User ID from Active Directory. Give your users this URL and/or make it the link they click on your Intranet. Then this site calls your MVC Site and passes the user credentials (login id).
a. This can be done either via an encrypted string on the URL or encrypted value in a cookie. You can encrypt with an expiration date/time value too.
b. (Speaking from Forms Auth) Create a Forms Authentication Ticket with that user ID. Run any other login logic you have. Done.
External Site - No Changes required. Let the users login as-is.
Are you wanting to handle forms and AD authentication from one URL? I have used thinktecture (claims based auth) as the framework for WIF and marshaling various forms of authentication. However to handle if from one URL I had to handle some logic at login that associated the user to AD or Forms based. In a more recent project, this was handled at user management when we created the user account (it was associated to AD of Forms Auth). Then when the user logged in they would preface the AD domain name as part of the login. There are a number of ways to implement this, this was just one I have used. An example, instead of requiring the domain, just use the username, then check for AD or forms based flags on the username and then handle authentication accordingly
EDIT
Just an update in re-reading your question. Are the internet users and intranet users the same? If so you need to just go forms based auth across the board and manage the users in the product DB independent of AD. If they are the same then they could login prefacing the domain name to username. if you wanted to rely solely on AD.
I did a proof of concept of this some time ago, at my previous job, so the details are hazy and I don't have any code to refer to...
The requirements were:
Single URL for internal (LAN) and external (internet) access
Two types of users, people on the domain and external (non-AD) users
Windows authentication for domain users both internally and externally
The ability to enter domain logon details when using iPads (no windows auth)
The core idea in the solution I came up with was that we used Active Directory Group Policy to add a custom string to http request header user agent, the content doesn't matter, in fact we used a long random string of characters.
https://technet.microsoft.com/en-us/library/cc770379.aspx
Then the landing page for the site checks for this, and if found redirects to a virtual directory, with windows auth, that checked their AD account, populated the ASP.NET authentication token and then redirected them to their home page.
If the custom header isn't there then it just displayed the normal login form.
The only other thing was to add an AD email/password check to the normal login form so that if a domain user accessed the site from a non-windows device (iPad) then they could use their normal login details.
Why not put your website code on the server, robocopy it to two separate websites and just handle the changes in authentication by configuring the web.config. (one would be setup with anonymous and one with windows authentication.)
It's not as snazzy as other methods but it's relatively painless. There are two sites but the content (except for the web.config) are identical.
We are trying to implement single sign on for two different web application located at different domain
WebApplication 1 (this will act as a front end where user log in)
WebApplication 2
the basic usage idea will be
User sign in trough a login screen in WebApplication 1
User click on a link in WebApplication 1 which will then open a popup screen to WebApplication 2 without signing in again
Now in order to achive this we created an ETL script which runs every 1 hour to synchronize the user and group accounts from web application 1 database to web application 2 database
Question
is there a better way to achieve single sign on rather then writing
a script that synchronize user account every 1 hour?
I have read new technology call WIF(Windows Identity Foundation) that is built in to .net framework 4.5 will this help to solve my issue above?
Running a script every hour is not a good idea as it be overhead on the server
To achieve single sign on for the different domain can be bit tough but not really impossible, It becomes difficult only because we cannot share the cookie across different domain. So we can have one different server for single sign on
When the user visit the web-application 1, redirect user to SSO server.
Once the user is redirected to the SSO server, check if the cookie exist, as its for the first time there will be no cookie so show the login page which is hosted on SSO server.
After getting the credential from the user validate the user
If the user is valid, generate a token now this token can be unique hexadecimal number or hash for the timestamps.
Set this token into the cookie on the SSO server and redirect the user back to the original site or success page
Now when user visit the web-application 2, redirect the user to the SSO server again
Once user comes to SSO, check for the cookie, if it exist and not expire then redirect user directly to the success page without asking for login credential again or show the login page and follow the drill again
As we are redirecting the user on the different server, we can set the cookie there with the common name as 'SSOcookie' and every time access the same when coming from different application. This will help you to achieve single sign on for different domain.
I have an ASP.NET site on a public web server, where users login using forms authentication.
I would like users within certain organisations to be able to login automatically through Windows authentication (bypassing the login page). However, because these clients are on lots of different servers, I can't just build in Windows security to the main site. (I know there are articles on how to mix Windows and Forms security.)
My idea is for each organisation to install a page onto their intranet which redirects to my website and authenticates the user according to their Windows domain and username. Is this possible to achieve securely? How could I go about doing it?
What you have described is almost federated identity.
As well as a page on each site, you will also need a webservice whch will validate a token.
Essentially the flow is:
User comes to your logon page
you redirect them to their company logon page
their company logon page takes their credentials and redirects back to you returning a token
you then call their webservice to validate the token an determine who the user is.
Many public API's use this scheme (facebook being a notable example).
look up oauth and federated identity for more information.
Suppose I have logged into an web application. I'm on the page Default.aspx. If iis restarts then I need to re-login to use the application.
Is it possible to go back to the same page if IIS restarts?
How are you authenticating your users? Using forms authentication stores a client side cookie which can survive IIS resetting. Are you storing any authentication information in session state perhaps?
Edit
Just to add you can also redirect a user to a different page from the login page. Take the following url http://example.com/Login.aspx?ReturnUrl=%2fDefault.aspx.
This URL can be used to redirect the user to the Default.aspx page after they login. Assuming your using Forms authentication you can then redirect them using FormsAuthentication.RedirectFromLoginPage(userName, false); The false parameter prevents a persistant cookie from being created.
If you mean the ASP.Net application domain recycles, you're issue is that you're losing session state data, right? If that's the case, then how about storing session data in the StateServer or inside SQL Server? The default is "in process", so it's wiped clean when the app domain recycles.
If you set a cookie on each page the user vists stating which page they were on, then in your OnLoggedIn event you can check for the existance of this cookie, and redirect the user to the page - we use a similar mechanism for round-robin logins to multiple domains at once.