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.
Related
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.
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.
Big picture: I have been asked to create a search engine for our company's intranet. Such a search engine will crawl pages supplied to it by XML files for each independent application on the intranet. Problem is, the entire intranet is using Forms Authentication, and so the crawler will have to have access to each application without actually having user credentials (e.g. username and password).
Each application within the intranet has its access controlled by a permission manager, which is essentially a wrapper on the default Role Manager ASP.NET comes with. Each application can define its own roles and assign people who have those roles.
Please note that there are potentially hundreds of applications.
The crawler has access to the permission manager's database, so it knows what all the roles are. Therefore my idea was to have the crawler create a cookie that identifies it as having all roles for each application.
The problem I'm running into is this: how do I create a forms authentication cookie which already has the roles assigned in it without creating a corresponding user (IPrincipal).
It is entirely possible that I've failed to completely understand how Forms Authentication works, and if so, please tell me what I can do differently.
This is probably not what you want to hear, but...
I would just have the crawler authenticate like anyone else.
Given that this is a crawler you control, why fight Forms Authentication? Seems logical to create a user with all required roles in each application (hopefully you have a central administration point for the hundreds of apps, else I would not want to be an administrator there ;-)
If you do anything that allows "just the crawler" special access (bypass user-based authentication based on... what? The crawler's user agent? A specific origin IP?), you create a security hole that a hacker can leverage to gain access to all of the intranet applications that have otherwise been diligently secured with user IDs, passwords and roles (in fact, the security hole is particularly wide because you propose granting access to EVERY role in the system).
It sounds like what you want is an appropriately encrypted System.Web.Security.FormsAuthenticationTicket (which then gets attached to HTTP requests as a cookie).
The encryption logic is located in System.Web.Security.FormsAuthentication.Encrypt(), which I think uses the MachineKey as the encryption key. Also have a look at the GetAuthCookie() logic (using Reflector).
You might have to write your own version of the encryption method, but what you want to do should be possible, provided you have a copy of the remote site's encryption keys. You don't need the user's passwords -- only the user name is encoded into the Ticket.
It seems to me that the problem is not yet well defined, (at least to me!).
Why do you need to crawl the pages and index them if there are fine grained permissions on them?! How do you show search results without violating the permissions? Why not index the back end by passing the pages altogether (I mean index the database records not the pages)....
I have an application with different sections. Each section is accessed through a domain. Example: www.section1.com, www.section2.com, www.section3.com. I need to preserve the session when the user navigates from one to another URL. The application is the same in IIS. How to accomplish that?
You will need to pass on the session-cookie, and re-set that cookie on the new domain. That will make the session live over several domains (assuming you use the same app).
Example:
Link from section1.com:
<a href="http://www.section2.com/?s=askdjh3k4jh234kjh">
then, OnSessionStart (or OnRequestStart) check for query-parameter s and attach session to it. Meaning, just manually set cookie ASP.NET_SESSIONID to the value you pass on.
This has severe security-implications, so don't allow this unless you know what you're doing. another solution might be to store something into a common backend (database?) and pass around the user with a token that represents the actual session (and set the cookie based on that token), that you generate on a middle-page when navigating away from section1.com -> transferusertonewdomain.aspx -> section2.com/?token=randomTokenThatMatchSessionInDatabase
That would prevent that anyone could hijack a session by jsut knowing the value of the cookie. However, that is possible never the less if you're somewhat familiar with a computer anyway.
If you have multiple domains (and not just subdomains, which are easier), you're going to have more complications doing this than you'd like, because you can't share cookies across different domains.
The usual workaround is to embed a link an image on the other domains that are served by an asp.net page (or HttpHandler if you like). That page should contain a querystring with a unique token and a hashed version of that data appended with some shared secret. Then, that page will set a cookie on the response appropriate to for that domain to associate itself with appropriate data. It will serve typically a 1x1 transparent image as the response. Usually you only want to do this upon login to one of the sites.
Unless you do some customizations, session is specific to an application regardless of session mode you are using. Here's an article that talks about how to customize SQL session so that you can use session across multiple applications.
You should start by change the sessionState from being "InProc" to either StateServer or SqlServer, ensure that the MachineKeys are identical across all sites (domains and servers), and then set up the relevant backend systems to capture the state information.
More information can be found on:
Session-State Modes
ASP.NET State Management Overview
You could use a cookie to pass it, still researching to find out how. I will repost.
** EDIT
There is another Stack Overflow question, see if it helps, 315132
It basically asks
I need to share SSO information
between two different domains with a
cookie, can this be done in PHP and
how?
the answer given was
On both domains, place an image or
other web element that is pulled from
the other domain. Use the URL to
notify the other domain that user X is
on domain A, and let domain B
associate that user ID with that user
on their system.
It's a little complex to carry out
correctly, but if you think it through
it'll work out very well.
Vinko points out in a comment
(thanks!) that I shouldn't take it for
granted that you understand the
security risks involved. If this
information is of any value to anyone,
then you should make sure you use
proper encryption, authentication, etc
to avoid releasing sensitive
information and to avoid various
attacks (replay, man in the middle,
etc). This shouldn't be too onerous
since you control both websites and
you can select a secure secret key for
both, since the communication is only
going between the two servers via this
special URL. Keep it in mind though.
The user is Adam Davis.
We are launching a new web site using a sub-domain and need to ensure that users logging in to the original (main domain) site, are also authenticated in the new site.
I believe I need to ensure all related web.config settings (forms authentication, cookie names etc) are the same in both applications and also manually set the machineKey validationKey/decryptionKeys (again, the same in both apps).
My question is, if I now manually set theses keys in my main app, will it break the existing logins?
We are using the "hashed" format for passwords.
Depends what you mean by "break". If you modify the machineKeys/encryptiong keys people might have to log back in but the login functionality will continue to work as before.
You also need to make sure that the domain for your cookie are set to domain.com in both places (without the www) or the authentication cookies will not be shard correctly between the sites.