Question

I am wondering if it is possible to leverage the Authentication, Membership, and/or Profile provider features in .NET to help integrate .NET web apps into my company’s enterprise portal. In a nutshell, the portal sends custom header values to any application that is ‘behind’ the portal for fields like the username, user profile data, and some access rights. One issue that we have with the portal is that we aren’t able to leverage many of the .NET apps available on the web because they weren’t designed to be “portal aware”, primarily to trust that the user has already authenticated.

Would it be possible to somehow write a custom authentication provider (or maybe leverage forms auth somehow) to just look at the header (plus the IP) and automatically “authenticate” as that user? My thinking is that by writing a profile provider, possibly a membership provider, and somehow adding authentication I would be able to download cool components like the Oxite blog (.net mvc demo that i found), switch providers to my custom one, and leverage it behind my company’s portal with minimal code changes.

Does this make any sense? I feel that I might not be understanding how these components fit into the puzzle.

Answer 1

I don’t think you can do this with zero changes to the .Net app, but I think you might be able to do it with minimal changes. Please note that I’m assuming that the portal Gateways everything that is going to the .Net web application. That is, the portal gets every HTTP request from the browser, adds its own headers to it, submits the request to the .Net app, gets a reply from the .Net app, rewrites things some more, and then returns info to the browser.

I’m guessing that what happens now (the reason you wrote this question) is you embed this .Net app into a portlet on your portal, but when someone tries to browse to it, even though they are logged into your portal, they see the external .Net login screen inside the portlet box. Not very nice.

There are two steps that need to be taken here:

1. Re-do the login page for the .Net app to auto-login portlet users
2. Create a custom membership provider that works along with #1

1. Re-do the login page for the .Net app to auto-login portlet users

Find the login page for the .Net app. It’ll probably be something like login.aspx. Copy it (and any associated codebehind files) to portallogin.aspx and portallogin.cs.
Open up the portallogin.aspx and portallogin.cs files. Get rid of all of the controls and code in there. Replace it with something like what you see below. Please note that everywhere you see PORTAL_SomeFunctionName, you’ll need to replace that with code from your Portal’s SDK that makes the appropriate function call.

const string specialpassword = "ThisPasswordTellsTheBackendSystemThisUserIsOK";

Page_Load()
{
  if (PORTAL_IsLoggedInToPortal())
  {
    string username = PORTAL_GetCurrentUserName();
    // Authenticate the user behind the scenes
    System.Web.Security.FormsAuthentication.SetAuthCookie(username, false);
    System.Web.Security.FormsAuthentication.Authenticate(username, specialpassword);
  }
  else
  {
    throw new Exception ("User isn't coming from the Portal");
  }
}

Next, edit web.config for the .Net application and tell it that the login page is portallogin.aspx instead of login.aspx.

That should take care of automatically attempting to log the user in.

2. Create a custom membership provider that works along with #1

This is where you will need to create a custom membership provider. In order for this to work, the .Net application you are working with has to make use of membership providers and allow for a custom membership provider to be used.

Create a new Membership Provider. You need to create a class and inherit from System.Web.Security.MembershipProvider. At a minimum, I think you’ll need to implement the GetUser and ValidateUser functions and ApplicationName property. Below are some ideas for how they could look. The are many more functions that need to be overridden, but the stubs (with the accompanying NotImplementedException(s)) can probably be left alone.

    public override string ApplicationName
    {
        get
        {
            return "Portal";
        }
        set
        {
            ;
        }
    }

    private const string specialpassword = 
       "ThisPasswordTellsTheBackendSystemThisUserIsOK";

    public override bool ValidateUser(string username, string password)
    {
        // If the password being passed in is the right secret key (same  
        // for all users), then we will say that the password matches the
        // username, thus allowing the user to login 
        return (password == specialpassword);
    }

    public override MembershipUser GetUser(string username, bool userIsOnline)
    {
       string email = PORTAL_getemailfromusername(username);

       System.Web.Security.MembershipUser u = new MembershipUser(
         this.name, username, username, email, "", "", true, false, 
         DateTime.Now(), DateTime.Now(), DateTime.Now(), 
         DateTime.Now(), DateTime.Now(), DateTime.Now()
       );
       return u;
    }

You can also do similar implementations for the .Net RoleProvider and ProfileProvider if that functionality would be helpful in integrating with this .Net app. (the Role provider will provide group membership information, and the ProfileProvider will provide extra bits of profile info such as email address, zipcode, or whatever other properties you want it to provide for each user. This information would have to be lookuped up from a database or from the portal HTTP header information.

Other Considerations

Since you’re using a third party authentication provider for this external .Net application, you need to figure out how you can tell this .Net application which users/groups are administrators. I can’t tell you that – you’ll have to find that out from the third party .Net application. This is needed if there are any permissions that are needed to do anything in this .Net application beyond having an account.

Since you’re using this in a portal, there are a couple of ways it can be used. You can just have one big portlet that shows the entire .Net web application. You could also have lots of little portlets that show bits and pieces of the .Net web application. Either way, you’ll have to consider that the portal might or might not render things properly when it puts a full .Net application inside a little portlet box on a portal page. If you get HTML that looks or works weird, it’ll be annoying to fix it. You can either try to fix the original .Net web app to spit out different HTML, or you can add a module to IIS to rewrite the HTML on the fly (I’m not completely sure it’s a module… you’ll have to dig some on IIS to figure out how you might do this).

Whew!

I know this doesn’t cover everything, but I’ve worked with setting up the Plumtree Portal (now BEA’s Aqualogic User Interaction) as the authentication source for Microsoft’s SQL Server Reporting Services, and I’ve implemented a Custom Authentication Provider for IIS based on user membership stored in a Dynamics NAV table. Hopefully my experience with these projects will be helpful to you in your integration of this external .Net application with your portal.

Tim