0
votes

I'm planning to implement an external-facing ASP.NET web application along with a Windows Communication Foundation (WCF) service providing an externally available API. I will provide security for the web app and service by rolling my own Security Token Service (STS) using the Windows Identity Foundation (WIF).

The basics for how I intend to implement this are described by these articles: http://msdn.microsoft.com/en-us/magazine/ee335707.aspx and http://devproconnections.com/development/generating-saml-tokens-wif-part-2

combined with the information provided by Vittorio Bertocci's excellent book on the subject: http://www.amazon.com/Programming-Windows-Identity-Foundation-Dev/dp/0735627185/ref=sr_1_6?ie=UTF8&qid=1366300926&sr=8-6&keywords=vittorio+bertocci

I should have all the tools and information I need to accomplish this task. The use-case for the application is this: user logs into an ASP .NET web application that we own, including the user authentication and authorization mechanism. While on this application, they click a link that uses SAML to single-sign-on (SSO) to a third-party application (with whom we have a tight business relationship with). While on this third-party application, the user can transparently work with files we're storing on yet another application internal to our organization. Basically, they will do a transparent/silent SAML SSO against my web app/WCF service to either save out or retrieve a document while logged into the third-party web app.

Like I said before, I think I have the basics for how to implement the authorization and authentication down for this process.

However, one item that my security team has asked is that we ensure that the user who logged in to the third-party site from out externally-exposed yet totally-owned-by-us originating web application, has an active session with out site. In short, we need to ensure this user is actually logged into site A, is using site B, but wants to access resources on site C by ensuring they, in fact, are logged into site A still.

How would I get this information regarding this user? Now, I did roll my own role provider for site A, but authentication is performed via Forms Authentication using an older username/password mechanism that does not include using an ASP .NET 2.0 "standard" membership provider. Therefor, Security.Web.Membership is not available to me.

Finally, this same process will apply to internal users on our active directory who will log in from our internal network, to site B, and then work with site C again. I believe we will be using ADFS v2 for authentication. Any tips on ensuring said user is active in the AD prior to authenticating against site C?

1

1 Answers

0
votes

The only reasonable way to track whether a web site user is still active is to use tokens with short expirations (say, 10 minutes) that auto reset each time the user navigates around the web site. With this you can say the user was active and logged in within the past 10 minutes. You'll need to track the token in a persistent store on your server that is updated with the time of the most recent user action / token reset so that back-end systems can ask "is this user still active?", and you'll need to pass something to the web client that they can pass back to the server on every subsequent web request to keep the session alive. This is usually a session cookie. The cookie could be the same as the token, or you could set up the cookie as a random value that maps to the token internal to your server if you don't want the true token to be known to the browser app. If the user actively logs out of the web app, then you void the token in your backend database.

Other techniques might involve keeping a long-running http connection open (ala web based irc chat) but this consumes a lot of network resources particularly on your server and firewall and it doesn't really provide any greater assurance that the user is actually still looking at the web app in the browser. A session that has been open 30 minutes but there have been no page navigations in 20 minutes sounds like the user has gone to lunch and left the browser window open. If you have to track page navigation anyway, then keeping the http connection open doesn't really buy you anything.