Introduction and Assumptions:
Since it is fairly easy to implement the same in the intranet, we'll talk more about the extranet implementation. Let call our main application (the portal) as the Master. All our users have access to the Master (with role based security). However, not all have access to the child applications within Master.
Scenario:
Let us assume a user-- Bob. Bob is an accountant for two different departments( A and B) at his work. He will need to log into the departments' websites to pull sensitive reports. Now, our Master application will let Bob in with his own credential settings. Within that application, he'll see the links to websites for departments A & B. When he clicks on either of those, he's directed to the corresponding department's homepage (not the login page) bypassing the login process.
Behind the Scenes:
We need to setup few tables to do this single sign-on which enabled Bob to bypass the login process from the Master application. I'll explain the table layout and thier functionality below.
tbl_App: This table has the list of child applications to be brought into single sign-on
- AppID
- AppName
- AppURL
tbl_AppUsers: This table has the list of users and the Application ID (from the previous table) that they have access to
- AppID
- UserID
tbl_AppUserKey: This table stores the AppID, UserID, and a GUID (which acts more like a authentication token for our single sign-on)
- AppID
- UserID
- Key
These are the key tables that you'll need. Assuming this is not for beginners, I will bypass other topics like user roles for different applications, securing the keys generated (to be discussed later) and so forth.
The Process:
Master:
Choose a data driven control like gridview or treeview to display the Applications that a user has access to. Use the first two tables for this. After Bob logs in to Master, read his user ID and get the applications (departments A and B) that he has access to.
Now this is important! When Bob clicks on the application link (Department A, in this example), you'll need to generate a unique key (GUID, to keep it simple), and store this GUID along with Bob's User ID and the App ID. Read the App's URL from the tbl_App table. Open a new window (You can do this using client script which I'll post at the end) for the link that Bob has just clicked, and pass the generated key as a query string.
Department A's application:
Get the query string (the GUID) and read the corresponding User ID from the tbl_AppUserKey table. Now that you have the User ID for Bob, it's not a good idea to keep the GUID in the table. So, delete it! duh!
In this way, even if Bob closes the browser (instead of logging out), and tries to come back (by entering the URL from his browser history) you can redirect him to a error page as the query string would be null. As I said earlier, I assume you already know about maintaining roles and synchronizing the Master and Child applications.
ClientScript for Opening a new Browser Window:
//Open a window to the app and pass Token as query string - works only on postbacks
string script = "window.open('" + url + "?token=" + key + "')";
ClientScriptManager cm = Page.ClientScript;
cm.RegisterStartupScript(this.GetType(), "window", script, true);
Any questions? shoot me an email at vimaljonn@yahoo.com
