After studying the theories and analyzing the current conditions at your workplace, you've come up with a radically new (well, new for them at least) application security solution! Involving databases, WS-Federation, and countless other features and complexities, it will be the one-stop flexible solution for all security needs across your intranet and even internet applications. It'll even account for cross-company security! Encryption! Hacker defense! Oh my!
And then comes the crushing realization: there is no way you can develop and introduce all of the pieces to this monolithic security solution at once without it crushing the current system under its massive (though decoupled and elegant!) size.
Thankfully, the decoupled nature of claims-based and WS-Federation style security lends itself wonderfully for implementing the pieces individually and gradually introducing them over time.
Ideally, your wonderful design will be something like the following setup:
- Active Directory (or some other user provisioning system)
- A database with further HR/employee details
- Various existing and in-development intranet/internet web/desktop applications
- An STS, such as ADFS2
The reality is rarely ever ideal. You probably have Active Directory and a domain set up already (that's how everyone logs in at work, right?) but not ADFS2. Your existing servers, in both test and prod, may all be Windows 2003 boxes (with a few 2003 R2 thrown in for good measure). ADFS2 needs 2008 or 2008 R2, and it ain't like Windows Server licenses just grow on trees. It's going to be awhile before the server guys price and spec a machine, license the right edition of Windows Server for it, get it loaded with a SAN mounted and ready to go, so what do you do until then?
You want your application developers to go ahead and start coding in claims-based security but they're going to need some kind of STS to interact with in the mean time. Thankfully, the STS role can be easily fulfilled, especially if it is only a temporary solution. After all, the relying party doesn't really care who or what the STS is or how it works, only that it responds appropriately. This is why the default STS generated by the FedUtil program (which you should have gotten after installing the WIF SDK) always just simply replies with a hard-coded name and role. Really easy and simple, and it works and it fulfills the role, albeit perhaps not in a practically useful way.
Still, it doesn't take too much to slap together a temporary solution that responds with live, useful information intelligently while you wait on the more robust ADFS2 solution. This way applications can begin working with claims early and you can shift them over easily enough to ADFS2 later once it is ready. This also should make the "radically new security solution" you've devised an easier pill to swallow for your manager!
In a series of posts to follow, I'll explore just such a temporary yet workable STS solution that could tide someone over while a more robust solution (such as ADFS2) is implemented. My example will be an ASP.NET solution, since that's what we do where I work now. Really, though, since the standards are open and the role is generic, you could do it in any other stack you like. That's part of the beauty of claims federation: you can have WPF apps and RoR web apps talking to a Java-based Tomcat STS server that reads a PostgreSQL employee database and Active Directory via LDAP. (Of course, nobody actually does that — such a ridiculous number of wildly different platforms is a maintenance nightmare that no IT-team would knowingly invest in. But still, in theory, it's possible!)
No comments:
Post a Comment