I have two web application. One is for centralized Image server.
Suppose they are a.com and b.com
b.com is for image server.
and a.com is where my application is hosted.
I have created a handler for images ob b.com which process the request and add watermark and send it back to a.aspx.
I am passing the path of the image (absolute like http://b.com/ImageHandler.ashx?id=imageurl) to the Handler on b.com
Now I am not able to authenticate the request on b.com
Now I am thinking about Handler which is on b.com
should be on a.com
because at a.com I can easily authenticate user.
for this purpose do I need the handler at both a.com and b.com
or is there is any way that I can authenticate the user at b.com.
which has session on a.com.
I can not access the database for each request at b.com because the number of request for the images is very big.
Hope I am able to explain my problem correctly.
You need to first evaluate whether it make sense to have image server under different domain. If its all about sharing the same code among multiple sites then you will be better off by putting you handler under site and sharing the relevant code via class library.
There can be legitimate reasons for having handler on different domain. For example, it might need different level of scaling, it might be resource-hungry and you want to isolate it to different machine (isolating to different app-pool is possible under same domain) or because of some licensing issue (you want to save processor based license cost of some library used by handler).
If there are going to be different domain then you can have them as sub-domains. For example - a.xyz.com and b.xyz.com. In such case, same authentication ticket (issued at parent domain i.e. xyz.com) will suffice for both. See domain property for Forms Authentication Cookie to control this.
You also need to ask if authentication make sense for your image handler. Do you want it to be open or restricted to certain users? If you want only authenticated users and you want to support multiple applications then you are looking at supporting user sets of multiple applications. If it's the same user set (e.g. active directory) then your job will be simpler - have a single authentication provider whose ticket will be trusted by your site and all other applications [Windows Authentication works on similar basis].
If its diverse set of users then it essentially means that for image server, you have multiple authentication providers that you need to trusted. You probably need to look at some Federated Identity system - see one such .NET based implementation discussed here: http://msdn.microsoft.com/en-us/magazine/ff872350.aspx
Maybe this helps:
http://msdn.microsoft.com/en-us/library/eb0zx8fc.aspx
Asp.net forms authentication and multiple domains
If this doesn't work for you you could pass some kind of encrypted token to b.com that b.com can validate to ensure the request is legit.
Related
I have two domains
Example :
a.com and b.com
I try to implement SSO Cross-domain authentication for these two websites
I refer to this link reference How youtube gets logged in to gmail account without getting redirected? to implement like Gmail and YouTube
I have doubt about that
How to send tokens from one domain to another domain using iframe
How to pass tokens in a secure way
If I use an intermediate domain how to prevent that domain call for accessing cookies value I want to set the cookies in the second domain
Please help me to implement I searched but the sample code is not available in asp.net
have you tried this method?
Using Reverse Proxy
As #David suggested, use a reverse proxy like Nginx or HAPorxy to serve both the applications from the same domain - protocol://host:port. All three things should be equal.
Using cookies instead of LocalStorage
If you use cookies instead of LocalStorage, then host ports do not participate in determining site policy. So two application running on the same host but the different port will share cookie without any extra work. To protect the cookie, use an HTTP-only cookie, same-site cookie.
Using URL to share - IFrame only
If you are using iFrame, then you can use URL to share the token. When the outer window is loading the iFrame, send this information via hash like http://localhost:8081/somepage#token=1234
Using hash will allow the page to send data to an inner page without being sent over the wire.
Using window.postMessage - IFrame only
Using window.postMessage, you can simply pass the required data to the inner window/iFrame. As long as you control both the endpoints, you can easily do cross-domain message sending.
In the end, it really depends on your security requirements, ease-of-maintenance, etc.
The best of this is using oAuth https://oauth.net/ provides a comprehensive definition of this.
There are many open-source implementations of oAuth consumer and server available.
The concept is that a third URL will authenticate and maintain the primary session and pass tokens via URL on redirect. The consumers can utilize tokens to request the server for details directly.
Overall benifit is that you will get implementations via open-source communities in a language of your choice, and you will be able to utilise third-party logins. There are other standards you can look into as well are SAML , OpenID and LDAP and products like shibbobleth,CAS and Azure AD.
We're developing a SAAS solution for a big company in which doctors can view patients and make mutations, order products, provide licenses.
This project is for 4 separate companies under one umbrella company. For each company we developed a portal. All portals use the same code but have a strict separated database because the database contains all the patient information.
We're using Sitecore as CMS.
The client decided to use virtual folders instead of subdomains for the production environment. Our staging evironment url is for example: acc-portal1.umbrella.com. For the production environment they would like a URL such as: acc.umbrella.com/portal1. One SSL certificate is being used for all portals and requests.
We're using Membership Provider (forms authentication) for the authentication of users. Users can not log in with the same account in for example portal1 and portal3 because of the usage of separated databases.
Because we're using formsauthentication the ".ASPXAUTH" cookie is being used. Of course the "ASP.NET_SessionId" cookie is used also.
Because the client wants to use virtual folders instead of subdomains, the cookies are shared over all portals. It is possible to set the "path" on the node in web.config but this path is dynamically read by Sitecore and resolved in a pipeline. I did not find a way to override this path after it is being loaded in the web.config. Also I did not find a way to alter the ASP.NET_SessionId cookie path.
My question is: is it a (security) risk to share these cookies over multiple portals (remember, they should be separated completely)? Are there any other problems this setup could cause?
Hope somebody can help!
Yes, there is a huge security risk. What you do is called a multitenant application. You have to take special steps to ensure that cookies and other sensitive data cannot be shared.
My advice would be to store the tenant name (portal1) in the custom data section of the forms authentication cookie. You set the custom data when you issue the forms cookie.
Then, have a custom module or just a handler of the Application_AuthorizeRequest event, where the identity is already established based on the cookie.
In your handler, you decrypt the forms authentication ticket from the cookie, retrieve the user data and compare to the actual url. If there is a match - nothing happens. If there is no match, it means that user is authenticated in one portal but tries to access another. You can gently clear the response and render a message "well, this portal is not meant for you" or just log the user out.
I have several websites that use a HTTPModule (wrapped in a dll) to authenticate users and store an authentication object in the application cache for ~10 hours. I then set a cookie containing the cache key on the users machine.
I'm now looking for a way to allow admins to clear a specific cache object for all websites for any given user (effectively logging them out) causing them to automatically log back in (via windows authentication) next time they visit any of the sites.
I was planning to have a single administration website with the facility to reset logins - but I can't change the application cache for other websites for obvious security reasons.
Is there any way of passing a signal to those sites that use the authentication module so that they can clear their own application cache?
Note: I have read up on memcached but I would like to avoid a solution that isn't 'Standard ASP.NET' if possible.
Here are two ideas:
If they are on the same server, you could have a file containing the active logins in the file system, that all projects can access.
Add a generic handler to each project, that resets the login of a given user. Call this from another project when he gets logged out there. You could add a passphrase for security reasons.
EDIT: I just thought of a better solution:
Create a central "authentication" project that keeps track of the login status. Call it from the websites (e.g. through generic handlers, webservice, ...) to log out a user or check his status.
I've opted to piggyback code onto the existing HTTPModule.
I check for a custom user-agent string, if it exists I clear the relevant cache entries based on a query string and return a custom HTTP header upon success.
The only extra overhead is checking the user-agent for each request which I can live with.
With this setup I can now use a WebRequest object (injecting my custom user-agent string) from my central site to send messages to all sites using the module.
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've built an application that uses jQuery and JSON to consume an ASP.NET .asmx web service to perform crud operations. The application and .asmx are on the same domain. I dont mind people consuming the read operations of the .asmx remotely but dont want people randomly deleting stuff!!!
I can split the methods i'd like to be publicly accessible and the 'hidden' ones into 2 web services. How can I lock calls to the 'hidden'.asmx web service to the same domain that its hosted in?
Thanks in advance.
Edit:
Can someone comment on this, seems plausible ( source: http://www.slideshare.net/simon/web-security-horror-stories-presentation ):
Ajax can set Http headers, normal forms cant.
Ajax requests must be from the same domain.
So "x-requested-with" "XMLHttpRequest" requests must be from the same domain.
There are two scenarios you need to secure with web services:
Is the user authenticated?
Is the action coming from my page?
The authentication piece is already taken care of if you're using Forms Authentication. If your web service sits in a Forms Authentication-protected area of the site, nobody will be able to access your web services unless they're logged in.
The second scenario is a slightly trickier story. The attack is known as CSRF or XSRF (Cross Site Request Forgery). This means that a malicious website performs actions on behalf of your user while they're still logged in to your site. Here's a great writeup on XSRF.
Jeff Atwood sort of sums it all up in the link above, but here is XSRF protection in four steps:
Write a GUID to your user's cookie.
Before your AJAX call, read this value out of the cookie and add it
to the web service POST.
On the server side, compare the FORM value with the cookie value.
Because sites cannot read cookies from another domain, you're safe.
In AJAX the browser makes the calls, so even if you were to check that the domain is the same it wouldnt be secure enough because it can easily be faked.
You need to use some sort of authetication/autharization tokens (preferably with a time out) to keep things safe.
Quick and dirty solution would be to use IP address restrictions to allow only your domain's IP address access via IIS.
Probably better would be using HTTP authentication. There are many ways to do this, I found Authentication in ASP.NET Web Services a helpful overview.