Wondering if it is possible for my claims aware application (ASP.NET) to save a cookie that can be read by the ADFS Service (ASP.NET also). This is so I can give it the URN of a specific client at the time of the SSO based on the subdomain. However I am not sure if a website can read cookies from a different website or not.
I think it's possible, but only when both webapplications are on the same domain. The following question, and especially the marked answer, handles a similar question:
sync cookies and sessions in different subdomains (asp.net)
If it were possible to do it with different domains, that would be a huge security risk. Then your cookies would be readable by any other website you visit. So I don't think that's possible. But if I'm wrong, someone please correct me on this one.
Further information # MSDN: http://msdn.microsoft.com/en-us/library/ms178194.aspx.
See the section called Limiting Cookie Domain Scope.
Related
Is there a way to share cookies across different domains and different applications (classic ASP and ASP.NET)
No, there isn't.
The issue is the cross domain one, rather than the asp.net/classic asp and is security reasons.
If the domains are subdomains you can share the cookies, provided you use a cookie path that both can access (ie. for the domain sub.example.com you can read and write cookies using the example.com domain).
You can share cookies via some behind the scenes communication between servers, or through querystrings.
Both are ill advised, unless the information in the cookies is harmless (but be aware that harmless looking data quite often isn't actually harmless).
Native support for accessing cookies is not possible cross domain, and probably will never be for security reasons.
you can use cookie convertor which save all the cookies in the share database and try to recreate them again.
Is there a way to share cookies across different domains and different applications (classic ASP and ASP.NET)
No, there isn't.
The issue is the cross domain one, rather than the asp.net/classic asp and is security reasons.
If the domains are subdomains you can share the cookies, provided you use a cookie path that both can access (ie. for the domain sub.example.com you can read and write cookies using the example.com domain).
You can share cookies via some behind the scenes communication between servers, or through querystrings.
Both are ill advised, unless the information in the cookies is harmless (but be aware that harmless looking data quite often isn't actually harmless).
Native support for accessing cookies is not possible cross domain, and probably will never be for security reasons.
you can use cookie convertor which save all the cookies in the share database and try to recreate them again.
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.
We have a scenario whereby we are hosting an ASP.NET MVC web site on behalf of someone else.
The customer in this case wants us to restrict access to the web site, to those users who have logged in to their main portal. They should then only be able to get to our web site via a link from that portal.
At this point I'm not yet sure what technology or authentication mechanism the 3rd party are using but just wanted to clarify what the possible options might be.
If we call our hosted site B, and their portal web site A,as I see it we could:
Check the referrer for all requests to B, unless they've come from A they can't get in
Check for a specific cookie (assuming A uses cookies)
I'm sure there are other options, anyone any ideas?
Check the referrer for all requests to B, unless they've come from A they can't get in
Can be faked, but most normal users won't do it.
Check for a specific cookie (assuming A uses cookies)
Ask them to embed in their portal some code portion from your site. This way visiting their portal will resulting in you setting a cookie for your domain. Then you can easily read it later.
One more thing to mention. If you're talking about public sites, then it will suffice for a search engine to somehow discover these hidden urls once, after which the game is over. It will index the pages and keep a cache of it. You may want to consider including some noindex/nocache meta tags in these pages.
But seriously, if you wish to have it done properly and secure, you're going to need some form of shared user authentication that that portal and your site both support.
The solutions you have posted are not secure.
In case this is an enterprise application with real requirements for security, you may want to look at some single sign-on solutions.
List of single sign-on implementations
If I am on a website#1, and I enter my username/pwd for website#2 on a login page that is on website#1, and website#1, behind the scenes, makes a httpwebrequest to website#2 and posts to the login page. If I then navigate to website#2, should I be logged in?
website#2 uses formsauthentication and I call a httpHandler that is on website#2 and pass it the username/password via the querystring.
Should this work?
What you're trying to do is called Single Signon. The way you're doing it, posting values from one site to another, probably won't work because you're using the same technique a hacker might use to trick user into sharing their login information. It's called a cross-site request forgery attack. IIS is configured not to allow that.
Generally, you need a central authentication system that both sites use to share login information. This can be done in several ways, including a shared database-based login system. Google "asp.net single sign on" for more ideas.
Do site #1 and #2 want their users to have single sign on?
If so, read up on single sign on. It's a bigger project than can be addressed here. There is a good book on it though from Wrox :
http://www.amazon.com/Professional-ASP-NET-Security-Membership-Management/dp/0764596985/ref=cm_lmf_tit_10
Or are we imagining something sinister?
If we are imagining something sinister, then evil site #1 would collect the credentials, then automate a browser on the server side to start checking to see if site #2 uses the same password and user combination. Then the server would have an authenticated session. This wouldn't give the user who accessed site #1 an auth cookie, the HttpWebRequest object on the server would get the auth cookie. Site #2 couldn't really do anything to prevent this because a browser request from one computer looks much alike a browser request from another. A well crafted attack would spoof all elements of the browser's request so that it looks like it came from a browser instead of a primitative HttpWebRequest object, which may not even set the user-agent.
Site #2 should stop using passwords and user Id or use 2 factor ID if they are concerned abut this, or do something that requires javascript for logon because spoofing a browser that is executing javascript is harder than spoofing a browser that just sends and receives http requests and responses.
There are too many security issues trying to auto-authenticate between sites. There needs to be a central security provider that both sites belong to so that hand off is completed securely.
We use CA's Siteminder for cross site authentication. Effectively, web 1 creates a unique session id on the siteminder server and passes any credentials and info to it. Siteminder invokes web2 and passes the information by means of session variables. Web 2 retrieves the data from the session and uses it. There's much more going on there but that's the just of it.
To do something like this, I would strongly consider using an out of the box solution as generally coding up custom security generally falls short.
While this can be done on some cases, in the form of an HTTP request with POST parameters, you will not be authenticated once you browse to site #2.
This is because, generally, these sites store a cookie on your end and these are domain-based, which means that even if you grabbed that and stored it yourself from site #1, the cookie name would not match site #2.
Additionally, site #2 may not be easy to authenticate against and this is usually a security concern that developers are aware of. This can be considered an attempt of XSS as well.
In case you're simply doing this for yourself, I'd recommend LastPass and save most of your info in it.
Please reconsider your goals and how to achieve them, this is not the way.
Edit: Link text.
This could work, depending on the security measures in place on website #2. For a secure website, this would fail.
I would recommend against this purely on the basis of good security and good coding/design practices.
If you are unclear what security measures stop this, you should probably educate yourself so you can prevent the same issues on your own site. See http://www.owasp.org/index.php/Top_10_2007
Since both your sites are using FormsAuthentication you can easily configure both of them to share FormsAuthentication encryption schemes.
This will allow you to do Cross Application Authentication automatically :)