5 ms·

This might be the right place to ask but ... is there a reason people keep reinventing SSO? It's 2012. The first place I saw SSO was on a Banyan VINES network

by bdunbar 15y ago

This might be the right place to ask but ... is there a reason people keep reinventing SSO? It's 2012. The first place I saw SSO was on a Banyan VINES network, in 1990. Years, I hasten to add, before NetWare figured it out. We've got it, still, in the enterprise. It's now Active Directory, but I can use my same credentials for login and auth on Windows clients, unix machines, two different web apps from as many external providers. Note, I have no idea how the web apps obtain my login credentials, save that the AD guy and the web guys did some black magic behind the scenes. Why do people keep re-inventing SSO, sometimes badly? No way to make a black box that Just Works?

bmelton 15y ago
What is the 'de facto' answer for environments where AD isn't present? I was going to say something about AD not supporting SAML, or federation, but it appears that my knowledge is dated. But in an enterprise where there are no Windows machines (to my knowledge,) much less Windows servers, what's the fill-in? *Edited the snark out.
- JoachimSchipper 15y ago
  I think the standard UNIX-flavoured solution is LDAP+Kerberos, which is pretty much AD without the gratuitous incompatibility and useful extras.
- bdunbar 15y ago
  Good question. I'm familiar with two 'unix' networks that stood apart from the windows networks in an enterprisey setting. - NIS+ - Scripts to copy a 'master' /etc/passwd to all other unix hosts. Keep the master under version control. But I've been here for over a decade. When I got here we were using vintella which hooks the unix hosts into AD.
- kprobst 15y ago
  A lot of enterprises use SiteMinder (aka ChannelSecure), which used to be Netegrity's before they got bought out by CA. It supports both Apache and IIS, although I'm not 100% sure what the policy servers run on, it might be Windows. But I have seen LAMP apps that integrate with it, for example. It really is just an intercept-and-forward system that functions as a module on the web server and puts a few things on the HTTP headers to allow apps to handle authorization by themselves.
  - m0nastic 15y ago
    After about a decade of testing people's web applications, SiteMinder has defnitely emerged as the standard third-party tool for SSO. Many years ago, it seemed like people were fairly evenly split between Siteminder and another one (I think it was called GetAccess, but the fact that I can barely remember it is probably an indication of it's current popularity). Siteminder is a good solution (and I've probably tested about ~150 web applications over the years that are using it). It's caused my attack plan to go from "Let's see how fundamentally broken this company's home-grown SSO solution is" to "Oh good, they use Siteminder. Let's see what areas they haven't implemented it properly in." That's an important distinction, and the bulk of issues I've found with Siteminder over the years have all been in identifying specific pages or transactions which aren't properly using the SMSESSION. I found a forehead-slapping issue recently where there was one page that wasn't properly validating the SMSESSION (it was just checking to see that it existed). That page happened to be the "reset password" page, and it was possible through a series of redirects to modify anyone's password to whatever you wanted, even if you didn't have a valid account on the system. And that's kind of the problem, which is that even using someone else's SSO mechanism (which, again, Siteminder is as good as any one I've seen over the years), If you've screwed up the implementation for any transaction or on any page, you're still screwed.
tptacek 15y ago
Because standarized SSO systems would require the maintainers of multiple unrelated app stacks to agree with each other about something.
- Spearchucker 15y ago
  The only thing that needs agreement is the protocol. There are two choices IMO. SAML, or WS-Federation. SAML2 is pretty good but limits implementers to the passive requestor profile (it relies on the browser for the HTTP 3xx redirects) and means you can't use services[1]. It also doesn't do attribute provisioning (something U-Prove can do). The SAML protocol also mandates use of SAML tokens. WS-Federation on the other hand lets you use any token you like. And it supports services. [1] TBH I haven't looked at SAML for a long time. It may well have come along by now.
  - tptacek 15y ago
    You were thinking maybe PHP, Rails, and Django devs might decide to adopt a WS-star XML-hell enterprise standard?
    - Spearchucker 15y ago
      I wasn't thinking anything - I have no idea what your requirements are. Slide 12, and slide 61: http://wwww.wittenburg.co.uk/Presentations.aspx http://wwww.wittenburg.co.uk/Presentations.aspx [Edit] Maybe that answer was a bit trite. As mentioned, I don't know what the requirement is. The article mentions Ruby, Python and Node, but also suggests those selections are random to introduce complexity. Would I choose WS-Fed? Depends. Maybe, if the IDP uses AD. The benefit is that you can use ADFS and only code out the relying party. Definitely, if the solution is service-based. And also definitely, if a). I need a token other than SAML or b). I'm doing anything with Azure or Office 365. I guess a more interesting question is why I'd code web SSO from the ground up when there are two stable protocols out there. I wouldn't. I'd use what brains more capable than mine have already designed. Something that has been out there for a while, and has proven itself to scale and be secure. Security is very compelling. WS-Federation is used to protect some very, very sensitive public sector services. And I'm talking a lot more sensitive than the HR solution I built for the UK government.
ominous_prime 15y ago
Not only what tptacek said, but it's somewhat related to NIH syndrome. People look at the specs for standards like OpenID, OAuth or SAML2; think it's way too complex; and decide they can write something much simpler to suit their needs. After dealing SAML myself for a couple years, I agree it's huge and possibly over-engineered, but it also has years of work put into it, and there are well-tested implementations that you can use, just maybe not in your favorite language. Note: I'm talking about Web-SSO. Host SSO pretty much consists of LDAP+Krb5 (which is the basis of Active Directory authentication), or just LDAP. Everything else is pretty much dead, though NIS still sticks around the *nix world due to it's ease of configuration.
- mattmanser 15y ago
  With a lot less experience to you I can relate to the NIH syndrome, but I don't think it's just the specs, it's the resulting implementations. Just go look at the .Net one that everyone recommends you use: https://github.com/AArnott/dotnetopenid/tree/master/src https://github.com/AArnott/dotnetopenid/tree/master/src Over-engineered specs seemingly result in over-engineered code. Not that I really get why they made the client and the provider one big project in the first place. Having mucked around with OAuth on a couple of .Net projects it's just a nightmare to use. If something goes wrong and you try and dive into that code, woe betide you. It's like a rabbit warren. Just to figure out you aren't properly encoding the &s or something. Having used the v3 calendar API recently it's interesting to see Google now just release essentially very simple libraries that just deal with the integration for you. It's like even they've given up trying to get people to use OAuth, where the google groups were littered with 'can't get auth working' and so just hand-wave over it. Personally I think it's at the SOAP stage that data exchange formats went through, sounds simple but somehow is extremely complex. I'm hoping that the JSON equivalent will come out soon.

by bdunbar 15y ago

bmelton 15y ago

What is the 'de facto' answer for environments where AD isn't present? I was going to say something about AD not supporting SAML, or federation, but it appears that my knowledge is dated. But in an enterprise where there are no Windows machines (to my knowledge,) much less Windows servers, what's the fill-in? *Edited the snark out.

JoachimSchipper 15y ago
I think the standard UNIX-flavoured solution is LDAP+Kerberos, which is pretty much AD without the gratuitous incompatibility and useful extras.
bdunbar 15y ago
Good question. I'm familiar with two 'unix' networks that stood apart from the windows networks in an enterprisey setting. - NIS+ - Scripts to copy a 'master' /etc/passwd to all other unix hosts. Keep the master under version control. But I've been here for over a decade. When I got here we were using vintella which hooks the unix hosts into AD.
kprobst 15y ago
A lot of enterprises use SiteMinder (aka ChannelSecure), which used to be Netegrity's before they got bought out by CA. It supports both Apache and IIS, although I'm not 100% sure what the policy servers run on, it might be Windows. But I have seen LAMP apps that integrate with it, for example. It really is just an intercept-and-forward system that functions as a module on the web server and puts a few things on the HTTP headers to allow apps to handle authorization by themselves.
- m0nastic 15y ago
  After about a decade of testing people's web applications, SiteMinder has defnitely emerged as the standard third-party tool for SSO. Many years ago, it seemed like people were fairly evenly split between Siteminder and another one (I think it was called GetAccess, but the fact that I can barely remember it is probably an indication of it's current popularity). Siteminder is a good solution (and I've probably tested about ~150 web applications over the years that are using it). It's caused my attack plan to go from "Let's see how fundamentally broken this company's home-grown SSO solution is" to "Oh good, they use Siteminder. Let's see what areas they haven't implemented it properly in." That's an important distinction, and the bulk of issues I've found with Siteminder over the years have all been in identifying specific pages or transactions which aren't properly using the SMSESSION. I found a forehead-slapping issue recently where there was one page that wasn't properly validating the SMSESSION (it was just checking to see that it existed). That page happened to be the "reset password" page, and it was possible through a series of redirects to modify anyone's password to whatever you wanted, even if you didn't have a valid account on the system. And that's kind of the problem, which is that even using someone else's SSO mechanism (which, again, Siteminder is as good as any one I've seen over the years), If you've screwed up the implementation for any transaction or on any page, you're still screwed.

tptacek 15y ago

Because standarized SSO systems would require the maintainers of multiple unrelated app stacks to agree with each other about something.

Spearchucker 15y ago
The only thing that needs agreement is the protocol. There are two choices IMO. SAML, or WS-Federation. SAML2 is pretty good but limits implementers to the passive requestor profile (it relies on the browser for the HTTP 3xx redirects) and means you can't use services[1]. It also doesn't do attribute provisioning (something U-Prove can do). The SAML protocol also mandates use of SAML tokens. WS-Federation on the other hand lets you use any token you like. And it supports services. [1] TBH I haven't looked at SAML for a long time. It may well have come along by now.
- tptacek 15y ago
  You were thinking maybe PHP, Rails, and Django devs might decide to adopt a WS-star XML-hell enterprise standard?
  - Spearchucker 15y ago
    I wasn't thinking anything - I have no idea what your requirements are. Slide 12, and slide 61: http://wwww.wittenburg.co.uk/Presentations.aspx http://wwww.wittenburg.co.uk/Presentations.aspx [Edit] Maybe that answer was a bit trite. As mentioned, I don't know what the requirement is. The article mentions Ruby, Python and Node, but also suggests those selections are random to introduce complexity. Would I choose WS-Fed? Depends. Maybe, if the IDP uses AD. The benefit is that you can use ADFS and only code out the relying party. Definitely, if the solution is service-based. And also definitely, if a). I need a token other than SAML or b). I'm doing anything with Azure or Office 365. I guess a more interesting question is why I'd code web SSO from the ground up when there are two stable protocols out there. I wouldn't. I'd use what brains more capable than mine have already designed. Something that has been out there for a while, and has proven itself to scale and be secure. Security is very compelling. WS-Federation is used to protect some very, very sensitive public sector services. And I'm talking a lot more sensitive than the HR solution I built for the UK government.

ominous_prime 15y ago

Not only what tptacek said, but it's somewhat related to NIH syndrome. People look at the specs for standards like OpenID, OAuth or SAML2; think it's way too complex; and decide they can write something much simpler to suit their needs. After dealing SAML myself for a couple years, I agree it's huge and possibly over-engineered, but it also has years of work put into it, and there are well-tested implementations that you can use, just maybe not in your favorite language. Note: I'm talking about Web-SSO. Host SSO pretty much consists of LDAP+Krb5 (which is the basis of Active Directory authentication), or just LDAP. Everything else is pretty much dead, though NIS still sticks around the *nix world due to it's ease of configuration.

mattmanser 15y ago
With a lot less experience to you I can relate to the NIH syndrome, but I don't think it's just the specs, it's the resulting implementations. Just go look at the .Net one that everyone recommends you use: https://github.com/AArnott/dotnetopenid/tree/master/src https://github.com/AArnott/dotnetopenid/tree/master/src Over-engineered specs seemingly result in over-engineered code. Not that I really get why they made the client and the provider one big project in the first place. Having mucked around with OAuth on a couple of .Net projects it's just a nightmare to use. If something goes wrong and you try and dive into that code, woe betide you. It's like a rabbit warren. Just to figure out you aren't properly encoding the &s or something. Having used the v3 calendar API recently it's interesting to see Google now just release essentially very simple libraries that just deal with the integration for you. It's like even they've given up trying to get people to use OAuth, where the google groups were littered with 'can't get auth working' and so just hand-wave over it. Personally I think it's at the SOAP stage that data exchange formats went through, sounds simple but somehow is extremely complex. I'm hoping that the JSON equivalent will come out soon.