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.
Related
I have a web application developed using ASP.NET 4.5 and MVC 4. It originally used Form Authentication for users to log in, however, we are moving it to ADFS (WS Federation) authentication. The idea is users from my organisation (Org 1) and another organisation (Org 2) will be able to log in using ADFS (ws-fed).
ADFS is set up so when you navigate to the web application's URL it is redirected to ADFS log in screen. At this point, it displays an option for the two organisations, Org 1 and Org 2. If you belong to Org 1, click this button and the user has to enter their username and password. The same thing happens if you click Org 2 button.
The ADFS servers in Org 1 and Org 2 have exchanged metadata/certificates and the claim values.
When a user from Org 1 logs in, there is no problem, after successful ADFS authentication, they are redirected back to the Web application with the required Claims (the web app uses the info in these claims). However, when user from Org 2 logs in, they are authenticated but their Claims aren't reaching the web application.
Does the web application need configured to work with both ADFS servers from Org 1 and Org 2? My original thoughts were Org 1 (my own organisation), would handle all the ADFS authentication. The web app would point to it, and when a user from Org 2 tries to log in, our ADFS would redirect the request to Org 2 and then Org 2 would send the claims back to our originsation ADFS server and it would redirect back to the application with the Claims? Am I wrong in thinking this?
No, that's correct.
Two possibilities:
Org2's ADFS has the wrong claims rules
Your ADFS has no pass-through claims rules. You need these rules on your CP (for Org2) and for your RP
It needs these rules to pass through what it receives from Org2.
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.
I have spent about 6 hours trying to figure this out and I feel like I'm close but can't quite get the right answer. I have an extranet ASP .NET site. In that site I have an landing page that exists under a folder that has anonymous access. On that page, I have a custom login page to ask the user for a username, domain, and password that corresponds to an AD account that exists on the server. I want to take that information authenticate it against the AD on that box, and then somehow pass the AD authentication token back to the browser/client, and forward them onto the other folders on this site that requires the user to be authenticated with windows auth.
I already have code working to validate the user information successfully against AD. I just can't figure out how I pass a context or token back to the browser, set it, and then direct the user onto the part of the site that requires this windows authentication to have already taken place.
I've seen a million forms talking about using various methods of FormsAuthentication objects to store a cookie, etc - but that doesn't seem to address what I'm trying to do. I control the logon process instead of the user seeing the standard gray windows logon box. And once I authenticate, I need to in a single place on my custom login page pass that token back to the client so for the rest of the session, it's authenticated with AD. Just as if I had received the standard windows AD prompt and correctly authenticated.
Seems like this should be possible? Any guidance is much appreciated! I'm pulling my hair out over this one!
I'm developing a web application that requires the user to log in using forms authentication. inside the webpage you need to download a desktop application that requires to login to the same system too. Is there a way to transfer the current logged credentials from the web application to the windows desktop application without need to login again?. Both applications shares a Login object from an vb.net interface.
I tried to save the IP address in the Database but that don't work for me because the website needs to be accessed inside and/or outside of the company and the user cannot login twice in different machines.
I tried to google for solutions but without luck.
Do you have any suggestions regarding this?
This may not be exactly the scenario you're envisioning, but this article shows how to use Forms authentication from a Winforms client using WCF Authentication Services. This should get you going in the right direction. Per the article, you can use these services in any .NET application.
http://msdn.microsoft.com/en-us/library/bb386582.aspx
This article shows how to do it with a Silverlight app, just so you have another example. http://blogs.msdn.com/b/brada/archive/2008/05/03/accessing-the-asp-net-authentication-profile-and-role-service-in-silverlight.aspx
And just one more for fun. http://aspalliance.com/1595_Client_Application_Services__Part_1.all#Page1
There isn't really any way to share this without encrypting a file containing the user's credentials and storing it on the hard drive along with the file, but then you run the risk of someone decrypting the information and getting access to the user's password.
I think that an alternate approach that could work is to generate an authentication token (could be as simple as a GUID) and store it in your database along with the user's id when the user requests the download. You would want this token to expire after a reasonable time limit (5 minutes, for example).
You could then include a file that contains this authentication token with the download. When your apps starts, you could check for the existence of the file. If it's there, you extract the token, delete the file, send the token prior to presenting the user login.
If the token valid, your server would send back the user's login and your app would proceed as though the user were logged in, otherwise you would just display the login screen.
The first time I log onto my webservice I want to use FormsAuthentication e.g.
myService.ClientCredentials.UserName.UserName = "name";
myService.ClientCredentials.UserName.Password = "password";
but once a user has logged onto my web app I dont want to have to know about his password so I would like to be able to connect to the webservice as this user without knowing his password. Is this possible?
I would save the password on whatever front end is accessing the web service and then pass it behind the scenes whenever the user called the web service.
So essentially, design your web service take a password always, but have the front end cache the password so once the user enters the password, the front end doesn't ask again.
Be forewarned, there may be a security concern with keeping the password cached, as I believe that would be part of the session. I'm not familiar with how .net handles this, but you may want to look into hashing.
You should be able to do this, but there are several issues to consider. Forms-based Authentication (FBA) normally uses a cookie to track authentication.
Security - Configure the web application
and web service to use the same FBA database.
Domain - As long as the web service
is on the same domain as the web
application, the web service can use
the same authentication cookie. If the
client has cookies disabled, then this
may not work.
Cookie expiration - You need to configure
the duration of the authentication to an
acceptable time limit (30 minutes, 1 hour,
1 day, or more) in the web.config file. This
will allow the user to access the web service
within a proper time frame after he or she
has logged in.
you can enable sessions in your webservice. There is a simple token that you add in at the begining of the service declaration.
<WebMethod(True)> Method Name