Every company I’ve worked at, there’s been at least a couple of enterprise-wide sites that ask me to log on, and they prompt me for a user name and a password.
Clearly, if I’m connecting to an intranet site, what I need that server to do is to implement Kerberos to recognise me. That’s a great feature of modern web browsers, and it’s relatively easy to do in multiple web server frameworks. I’ll leave that as an exercise for the reader.
But that only works for internal sites, where the server and the client can each communicate to the Kerberos servers responsible for authenticating server and user. Maybe I’ll talk about that some other day.
Today, I talk about achieving SSO through Federated Identity. I’m going to start by talking about the theory.
What’s the benefit?
Simply put, security is improved dramatically, and administration and user effort is reduced.
No reuse of passwords – because even though we tell you not to use the same password across multiple sites, it’s well known that everyone does.
How does it appear to the user? Simple – as long as they are logged on to the corporate network, they browse to a remote site affiliated with the company, and after a couple of brief redirects, they’re automatically logged in to the remote site with credentials and access that matches who they are.
OK, that’s great – far better than having to use and remember a different password for those remote sites.