We have the following setup:
-Windows 2008 R2 Standard.
-ASP.NET Web Application deployed on Microsoft IIS 7.5 Web Server.
-PHP Version 5.4.21 Non Threaded 32-bit version
-WISP (Windows, IIS, SQL Server/Express, and PHP) stack and an ASP.NET web application HTTPS ( SSL )
We will ultimately deploy an ASP.NET Web Application and a PHP Web Application on the Same IIS Server.
User will first log on to the ASP.NET Web Application, but we want the user to be able to navigate between the ASP.NET Web Application and the PHP Web Application back and forth with ease.
We are planning to implement REST-based Web Services on the ASP.NET Web Application side and PHP Application side.
The User login Framework is only on the ASP.NET Web Application side( for those familiar with ASP.NEt technologies, we are using ASP.NET Membership Framework).
As I mentioned before, User will first log on to the ASP.NET Web Application, but we want the user to be able to navigate between the ASP.NET Web Application and the PHP Web Application back and forth with ease.
Do we have to Reauthenticate the user whenever he/she navigates over from ASP.NET side to PHP side and vice versa?
Would it be reasonably secure enough to just pass over the login cookie( "Security token") when user navigates over from ASP.NET side to PHP side and vice versa?
Please feel free to suggest alternatives to the approach mentioned above( for example, some people told me to use Memcached technology to share session information between the ASP.NET Web Application and the PHP Web Application. Is Memcached Technology better than using Web Services? )
I successfully implemented the exact same thing as you describe, but in the reverse direction. The users would authenticate on the PHP side (an existing legacy site), and we would just pickup the security token via cookie and just read against the same database to make sure the token was still valid. Worked without a problem for a site supporting several hundred regular users per day. In our case the PHP servers and the ASP.NET servers were actually even hosted in separate facilities.
Note that the use of a cookie based security token (session token) is commonplace. You do not have to do anything extra to have your users browsers maintain and send you the token as long as the domain does not change from the browsers point of view, or you properly set the path for the cookies when you do your authentication.