There are two sites. The main site, where there is an authentication logic for users and second site that works as an additional service for main site and has its own database, code, technology etc.
Both sites are own by different teams. Second site should be able to authenticate users, but has no access to database and code of the main site and is hosted on the different domain.
Now, authentication works in following way:
1. Second site show login page where in an iframe the login form of main site is loaded.
2. When user enters his credentials and clicks enter, all authenticate logic runs through the main site and user is authenticated only by main site.
3. Main site sends request through http(s) that informs second site about user that needs to be logged in by some unique identifier of the user (email).
4. Second site receives request from main site and simply creates authentication cookies without any validation and even without to be able to access to the user credentials (because of login form in iframe of main site).
The next problem appears here:
- Encryption of the messages from main site to second site. Second site uses asp.net mvc, but main site can use any different technology. Every message can contain additional piece of information, such as login and password for main site.
Which kind of encryption can be used here to encrypt message through the sites? Maybe someone know more appropriate way of doing this kind of interaction between sites. The main goal for all of this is easy integration between main site and second site.
Thanks in advance,
Dima.
Which kind of encryption can be used here to encrypt message through the sites?
A symmetric encryption algorithm such as AES seems a logical choice. Both sites will share a common secret key that will be used by the first site to encrypt the data and by the second site to decrypt the data.
Related
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 been trying to Google over this topic like crazy. I have this primary domain that has got a couple of subdomains and alied domains. All of these sites share the same set of members that will log-on. Naturally I will have to give them a single sign-on. So I have been looking various forums(including ours) and still have no luck. This is what I have done uptil now.
I have set a common machine key and decryption key of all the websites and also my authentication mode is set to forms. As far as sub domains are concerned, they work fine and a user signed in on the primary gets acknowledged on the sub-domain. The same case unfortunately does not work on domains(and I know cookies cannot be accessed across domains but I have set the machine key and decryption key).
Yes and no. .NET does not support this "out of the box".
If you're willing to force users to a specific domain to sign in, you can then redirect users to that domain/login page. After you have authenticated the user on your primary domain, then you redirect the user back to their original page and post some kind of encryption key to the page that tells the site that the user is authenticated, you then set a cookie for the new domain if you want a persistent authentication cookie.
This is more or less the method used by sites such as Stack Overflow when using Open ID, or for msn when using live id.
Technology
ASP.NET, VB.NET 2.0 (soon to be 4.0)
Overview
I'm writing a Login / Authentication Portal, so that a web application can use it to login a user, and then they can use the application using their credentials.
The login portal will be a separate application, and initially only available via an extranet as well as intranet for certain applications; but future apps will need to authenticate via the web (happy to implement as a separate instance). I basically want other individual applications to be able to authenticate users via this portal.
So that...
A user goes to an application's web url (i.e. www.application.com / http://apps/application - intranet) and clicks "login".
User's browser is redirected to the portal application, with a query
string
www.loginportal.com/login.aspx?url=www.application.com/login.aspx
(or other page).
User fills in their credentials (username, password), and clicks
"login" button.
Browser redirects back to url i.e. www.applications.com/default.aspx or login.aspx and is authenticated and logged in; and can use app.
Completed
I have the authentication itself sorted, and will implement as a class library in the local applications via a dll.
Need
So I basically need to know, how to:-
1. Post data to the portal url (could be different domain).
2. Redirect browser with post.
3. Make sure that the authentication is secure, and not easily hackable (I know how to use urlencode and htmlencode etc) - just not sure about implications of posting data across domains.
Any help greatly appreciated...
Cheers,
Duncan.
Seriously tough stuff, here. If it were me, I'd lean heavily on Windows Identity Foundation. I believe it can support this scenario (haven't actually done it; someone else at my company is developing against it).
OK, so this is the solution I ended up using:
In the original application (the one that needs the authentication; step 1 above) I redirect the user to my login portal, and include the original url as a get parameter.
The user then types in their details, username and password.
Next, the server-side code authenticates them, and redirects to a new page, where I send back to the page an html form which includes the request datetime (for security) along with a encrypted string (including the datetime of the request) of the data I want sent back to the original form.
I also add a JavaScript post method which sends the data to the original url as a form post. Because I'm using the same class library at both ends, I can encrypt and decrypt the data using the same method and the original requesting application has all the user data, including the ability to check the datetime of the request (I allow a set amount of time between the authentication and the picking up by the original app, making sure these are within say 5 minutes.
And job done.
If anyone wants the code, I can provide it, just don't have it with me at the moment, if I remember I'll post it.
Not the most elegant solution, but it works, and it's secure, so I'm happy. :).
I have a sharepoint webpart where I have links to go to different web sites to which login is required. Therefore, I think i need to log the users on before redirect them into deep pages in that site, therefore I think i need to set up a cookie to that web site when the web part is loaded (by using the user credentials of the user's active directory information).
How can I achieve this requirement with out opening up a new browser window? (Though I have used a client side script, it pops up a new browser window)
Any help is highly appreciable...
Thanks
If you are referring to "different web sites" as sites having completely different URL's, then it's probably not possible without SSO system.
The reason is that it's impossible to read/write cookies from other domain in web environment, i.e. pre-login the users like you are saying.
If all the sites are inside same domain, like mycompany.com for example, and different sites are in abc.mycompany.com or mycompany.com/subsite, then yes, you can set the cookie. See top section here http://www.15seconds.com/issue/971108.htm
A simple way to implement SSO is by implementing method described later on in same article.
in the "Requesting Cookie from Another Domain". This is not a very secure method though, but can be done if you restrict it properly to specific slave domains. And obviously all the slave sites have to be modified, as with any SSO implementation.
I am doing an ASP.NET website for a client, who wants to make their reports page available via IFRAME on other "reseller" websites.
The reseller websites are providing the same service with different branding.
I need to avoid, where I can, requiring them to implement any code on their webserver to enable this - hence using iframes.
A user would log in to the reseller website, load a page which contains an iframe, which in turn loads the report at the primary site.
As parameters, we would send the reseller id, and their username.
We can use SSL server certificates, but not any federated login (like OpenId) - a business choice of the client.
The question is, how does the primary site verify that the report page really is being requested by the user who loaded the page from the reseller?
In other words, how to authenticate the user across domains, without requiring the reseller to implement code..
Any thoughts would be much appreciated!
Your login form can use some javascript to post the login form to a hidden iframe (you can't use an XMLHTTPRequest because of cross domain security concerns) for each domain that you require a login for.
Be sure to redirect your iframe back to the original domain or you won't be able to fetch the login status out of the iframe due to cross-domain security.
The final trick for IE support is to flip the evil bit and add
P3P: CP="CAO PSA OUR"
to your HTTP response headers. Which tells the browser "I am not going to do anything bad, honest".
http://support.microsoft.com/kb/323752
http://www.w3.org/P3P/
I see no satisfactory way to do this without implementing any code on the reseller site.
Instead, I would require them to send an HTTPS request from the reseller webserver to the primary webserver, passing a unique secret key to identify themselves, as well as the username of their logged-on user.
Once verified on the primary site, this key would then serve as authentication for the reseller, and by extention, their logged-on user.
The response of this request would contain a html fragment string, which the reseller can inject into any page.
This fragment would contain an iframe, which, in turn, would load the report for the logged-on user directly from the primary site, using their username.
This report content would contain a reference to a reseller-specific stylesheet.
With this approach I would say HTTPS is not required in the browser, since both the reseller and their user is authenticated, and if that process happened over HTTPS, we can assume there is no eavesdropper.
In the case where the secret key or the user password got compromised, HTTPS from the browser would make no difference anyway.
I might be missing something, but if the client is authenticated against your server, then it will still be authenticated if you view it through an iframe.
For example, create an HTML page on your server with an iframe to gmail. As long as you're authenticated against gmail in your browser you will see your inbox in that page...