SharePoint University

Here's the scenario: I have Server 2003 hosting MOSS 2007 and configured to use SQL Server 2005 Enterprise instead of the default Windows Internal Database (SQL Express). I have an ASP.NET Web App built with VS2008 and 3.5 Framework running as a Virtual Directory in the Default Web Site with Integrated Windows Authentication as the authentication method. The Web App has functionality of displaying current logged in user on the homepage of the application (this is important later). I have a Sharepoint Team Site with a Page Viewer Web Part pointing to the URL for the ASP.NET Web App. The Sharepoint site is also configured to use Integrated Windows Authentication (Anonymous access is not an option I will use for any of my sites.).

Here's the issues: End user opens IE browser and navigates to Sharepoint URL. User gets prompted to log in. Credentials are passed and the Sharepoint page opens then the user is again prompted to log in (This is the authentication to the ASP.NET Web App hosted in the Page Viewer Web Part.) before the page will completely open. The first issue then is I want to pass the initial credentials from Sharepoint to the Page Viewer to use for authenticating to the ASP.NET app. I have tried Single Sign-On already and it does not allow for this and I have been reading forums, blogs, and just about every site imaginable to try and figure out how to customize the Page Viewer Web Part itself to have it pass the credentials.

2nd, issue with current scenario: Sign into the SP site and sign into the Web App. Now I am looking at the SP page and the Web App is displaying in my Page Viewer Web Part. (Remember earlier I said there is functionality of displaying current logged on user in the Web App. Here's where it comes in.) My Web App is displaying me as the current logged on user and my Sharepoint shows me as the current logged in user in the upper right of the site. I have a need of changing user accounts so the logical thing to use is the "Sign In As A Different User" right? Okay, so I select that action from the drop-down and sign in as a different user on the SP site. Whoah horsey!!! What's this? I'm not prompted for a sign in to my ASP.NET Web App being displayed in my Page Viewer and it's still showing the original user signed into the Web App? Okay, so this must be a caching or cookie issue I'm thinking but I made web.config changes to disable caching on the site and on web parts and it's still not refreshing the web part and prompting me to sign in again. So what I'm trying to accomplish here is A.) Either figuring out how to disable the "Sign In As A Different User" altogether, which would force the users to "Sign Out" or B.) figure out why this thing is not refreshing the Page Viewer and prompting the user to sign back into the Web App again.

3rd, issue with current scenario: I have the permissions set up on the SP site to currently use the default SPTrimmedSecurity however my "READ" user groups are still displaying the "Site Actions" button and the "View All Site Content" is the only action being displayed on the drop-down. I don't want to modify any css or use Designer to remove/hide anything. I want to see if anyone knows how to A.) Remove the Site Actions button from appearing altogether for users other than "Full Control" users and/or groups or B.) at least get that View All Site Content removed.  I will also note here that no modifications have been done to the site collection that would include having features added to show this in the tab or any other permissions modifications outside of the defaults.  All of the options I have read so far lead me to css mods and/or SP Designer workarounds and I'm trying to stay away from those types of workarounds for ghosting reasons so if I can do this in Out-of-the-Box scenarios that's going to be my first choice always.

 Extremely long post, I know, but I wanted to give as much info as I could and I have been beating my brains for over 2 months on these issues and I have done as much research as I can without asking for any help but I believe I am at the point where I need to ask for some help so anything you can give me is appreciated more than you know.

Experiencing the same first issue you listed.  Using the same technologies too.  Is your ASP.NET web app on the same box as SharePoint Server?  Ours are on separate boxes in the same domain, but we will test placing both on the same box.  I will post an update after we test this.  Maybe that might resolve issue 2 or 3 as well.

I have actually figured out the solution to this. What I did was create a redirect page that essentially grabs the user credentials from the initial login to the Sharepoint site then passes those credentials to the web application. The page viewer web part initiates the connection to the redirector.aspx (hosted on a separate machine or same machine, either way works) and because the credentials have been validated by Sharepoint the redirector simply grabs those credentials and passes them to the web application.

One thing to be aware of also is authentication between domains. If your web application is hosted on another machine but residing in the same domain then this way should work for you. If your web application is on another machine that isn't in the same domain but trusted in the domain that the Sharepoint server is sitting on then you should still be good to go because of transitive trust, but that's another animal.

Bottom line, if the machine you are hosting the new web application on is either a member of the same domain as the Sharepoint server or on a machine in another domain that is trusted by the domain hosting the Sharepoint server you should be good to go using this method. I have set this up in a testing environment to try the "different domain, same trusted environment" and the scenario worked. I personally have my web application on one web server in one building and Sharepoint on another server sitting 2500 miles away but on the same domain and this is working like a champ. I'll also add that the SQL Database that is the backend of the web application is sitting yet on another server in a totally different location than the web and Sharepoint servers and this is still working so there you have it.

What triggered the idea to do it this way was started with this article: http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/3666ed41-3d9f-49cb-b3b6-9299dfc84848/

The article talks about using a "Content Editor WebPart" but if you pay closer attention you'll see that the idea pops out by one of the repsondants about using the "Response.Redirect" in a login_redirect.aspx page, which is exactly what I ended up using and it worked great and it solved issues 1 and 2 together.

To solve issue 3 the solution resided in changing permissions on the site to not inheret from parent and to set up individualized permissions for the site instead of using Active Directory Groups (e.g. BUILTIN\Administrators, DOMAIN\Domain Admins, DOMAIN\Domain Users, etc...) I removed these accounts and just added the users on an individual basis and Voilah, it worked!

Hope this helped and Good Luck!

Did you disable Integrated Windows Authentication on the .NET web app before doing this? 

Yes. The web application is set to allow anonymous access to the site and we store user credentials in the existing database. The way the default.aspx page is set up for the application is to bounce credentials from the connected user to the database and allow/disallow based on those credentials so setting the site to anonymous and not storing any anonymous account(s) in the database will automatically redirect anyone trying to access the application using anonymous access to an error message page stating "Access Denied, Please contact the site administrator for assistance.".  This is necessary because someone could figure out what the URL is to directly access the application through a web browser instead of through the SharePoint Page Viewer Webpart. So, What the redirector does is grabs the credentials from Sharepoint, passes them to the web application in a hashed string and bounces them off the stored credentials in the database. If the credentials match voilah, you're in. If not, bam, sent to the error message page.

Another tidbit to note is that the redirector file created must reside in this directory "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS" then you point to the filename from within the Page Viewer Webpart using something like this: "/_layouts/your_redirector.aspx"

Here is an example of a redirector page without the hashing algorithm and this one only grabs the username and not username and password. You'll have to add the rest.

<%@ page language="C#" %>

<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
  Response.Redirect(String.Format("http://yourwebsite/yourvirtualdirectory/default.aspx?UserID={0}", Request.LogonUserIdentity.Name));
}
</script>

Good Luck!

Thanks for all the information.  I am following the steps in the link that suggests building a control, but cannot determine what file(s) exactly should be copied to the SharePoint folder.  I wrote a user control, but suspect that is not what this instruction wants.  Did you build a user control?  If so, what file(s) did you copy to the SharePoint folder?

 "1)  write a custom control with nothing on it. just write your code in load event. in your code generate a hidden field with value of current logged in user id which you can easily get from httpcontext.  compile your control dll and put dll into 80/bin folder of sharepoint and put ASCX file in CONTROLTEmplate folder in 12 hive. [...]"

Did you read all of my postings? Let me break it down this way:

1. You have a web app that has a "Default.aspx" page that has the controls to query against a database for stored credentials that either allows/denies access to that application based on the credentials passed in a URL bringing your to the application (Ex: http://yoursite/yournewapp/default.aspx?UserID=username). You will have to code to allow for this in the default.aspx and that file resides in your web app folder with the rest of the web application. You need to get that to work before going any further. There are different scenarios on how to do that and I'm not going to get into all those so just pick a method that works for you. Bottom line, you need to be able to pass a url as your authentication string to the application in order to access it. That string value is queried against the stored credentials in your database.

2. Now, you build a new aspx file to redirect that string using credentials pulled in from the Sharepoint site (Look at the code I wrote above do to this. You don't need "using" statements or anything else, just what I have in the example code with the exception of course that the url string will be your actual web application.). So let's call this file "login_redirect.aspx" for this example.

3. Now, copy the login_redirect.aspx file into the directory I identified earlier in the post for your Sharepoint site "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS". 

(NOTE: this directory is the root directory for all of your Sharepoint sites so any file put into this directory is accessible by all of your Sharepoint sites so be careful of what you put here. Also, this is the only file that needs to be copied to the Sharepoint server unless of course you decide to put your web app on the same server.)

4. Open the Sharepoint site you have your Page Viewer WebPart on and open the properties of the WebPart and enter "/_layouts/login_redirect.aspx" in the URL path and apply the changes. Exit out of edit mode on the Sharepoint site and the page should refresh and connect you to your web application with the correct login credentials providing you have windows authentication turned on for your Sharepoint site and off for your web site.

That's it. It's that easy. Then what you can do is add additional coding into your default.aspx page to query both username and password and then you add the additional coding into your login_redirect.aspx to grab both username and password instead of just username as in the example I've given.