Google Chrome has passed IE as the worlds most popular browser. Interesting.
The creeps a lot of people out. What creeps them out even more is that you can’t opt out.
Of course there is always my way out… (cue lightning flash and creepy James Earl Jone laugh).
Seriously though, don’t use Google services exclusively. Use Bing instead of Google for searching. Use Yahoo instead of GMail. Buy an iPhone, or if you want an Android phone, create a new email account just for phone use. Use Facebook instead of Google+.
If you give one company all your data what do you think they are going to do with it?
You ultimately have control over this in your choice of providers. You can opt out by switching.
There is a lot of push vs pull provisioning discussion going on recently. Both models have a place but there is hard and fast rule you should consider. If your solution requires your customers to stand up a web service (SOAP or REST) you are going to be running uphill against a head wind. Customers see public web services as support and security costs they just don’t want to pay.
For most customers it’s far easier to have a system running in a data center that makes that makes web service requests to a provider than it is to stand up a service. Google, for one recognizes this. The Google Apps Directory Sync is often incorrectly cited as a “Pull Provisioning” technology when it is exactly the opposite. The sync software runs on the customer side, reads from the local directory and pushes to the Google Apps Provisioning Web Service.
A proper provisioning standard, regardless if it’s SOAP or REST, should support both push and pull (note that SPML supports both). But I really don’t see the pull model getting much traction for cloud based provisioning. Perhaps it will for provisioning internal applications.
Posted in Cloud computing, Google, Identity, Identity Management, Provisioning, SOAP, SPML, Standards
Tagged Identity, Identity Management, Provisioning, REST, SOAP, SPML
There are some interesting tidbits coming out about the Chinese hack of Google. Apparently the source code to Google’s SSO technology was a target (although this is misstated in the headline as a “password system”). It’s unknown at this point what source code (if any) was taken, but this highlights the nightmare scenario of the SSO world.
If a vulnerability is found in your token generation code such that someone can spoof a token, then your SSO system and every system connected to it is compromised.
Of course just having the source code is not in itself a problem. Typically there is a private key that is used to encrypt or sign the token. But protecting that private key is the issue and that is where the source code is key. If you think your key has been compromised you can replace it. But the code that authenticates the user and generates the token needs to get the private key to do the encryption (or signing (or both)). If the secret algorithm to access that key is compromised, then the attacker can then attempt to penetrate the system where that key lives and get the key. With the key and token generating code in hand the attacker can then access any SSO protected system.
And here is an ugly secret. If the SSO technology is public key encryption, they key on needs to exist where the token is initially generated. If it’s based on symmetric key encryption then the key has to exist on every server in the SSO environment.
So just use public key encryption, that solves the problem right? Not so fast. One critical aspect of SSO is inactive session timeout. That requires the token to be “refreshed” when used so that it expired based on inactivity. Refreshing the token at every server in the SSO system (every PEP if you will) requires either that server to have the key, or it make a remote calls to a common authentication service to refresh the token.
There are pluses and minuses to both approaches. One puts the keys to the kingdom in more locations but the other adds overhead to the token refresh. When security and performance collide, who do you think usually wins?
These kinds of trade offs are what make SSO so interesting to me.
Note that I am not talking about federated SSO (SAML or openid) or intranet SSO (Kerberos) as they present a different set of challenges.
Phil Windley posts about Google’s recent moves in China and describes them as a result of conflict between Google’s desired to do what’s right (not censor) and doing what it needs to do to stay in business in one of the largest markets in the world. That’s an interesting take on it, but it doesn’t wash with recent history.
To be clear, Google was fine with doing evil for several years now. The lived with the government restrictions and did business up until recently when they were penetrated (reportedly badly) by hackers that no one seriously believes aren’t at least backed by the Chinese government. Also the decision to buck the government was also made easier by Google’s own lagging competitive position in China.
If the real story ever comes out I’m sure it will be fascinating. Until then I’m not sold on Google’s altruistic motives in this dispute.
Mark Diodati sums up the recent SPML threads here. But one questions that needs to be answered, if not SPML then what? One alternative that has been put forward by Mark Diodati, Mark Wilcox, and others is the LDAP (or DSML) pull model of provisioning.
This model is to expose your user accounts via LDAP using a Virtual Directory (VD) instance exposed to your service provider. The service provider would periodically make calls to the VD to look for account CRUD operations.
There are several compelling advantages to this model;
- LDAP is already a standard protocol
- There are defacto standard schemas (the most common of which is the standard AD account)
- This is really just an extension of a model that has already been embraced in the enterprise (look at how many apps can be AD enabled)
Could that be it? Is the solution to service provider provisioning really this simple? No, at least not without SAML. While this model shows promise there is a problem; passwords. If your enterprise is not ready to use SAML to authenticate to your service provider, then you are left with two choices; both unpleasant.
First you could just punt on passwords and force your users to manage their passwords on their own. This is no worse than the situation without any provisioning, but certainly not where you could be if you used a provisioning solution to push the passwords out to the service provider as needed.
The second is to expose your password hashes via your VD. If your service provider supports the same salting and hashing algorithms, then the passwords could be synchronized by copying the hash across. In fact the recent version of the Google apps dir sync utility claims to be able to do just that.
But think about this for a moment. If you do that then the service provider knows the clear text password to log into your network for every one of your users that actually uses the service. After all, the user has to provide the clear text password to the service provider’s login page to generate the hash value to compare to the hash you sent them. If that’s the same as the hash value in AD, then the service provider knows your AD password by definition.
Do you trust Google with the clear text AD passwords? I’m not picking on Google; there simply aren’t any service providers I would trust with that information.
Another alternative I have heard is that the service provider’s login page would make an LDAP bind call back to the VD with the supplied password to do the authentication. Again, that gives the service provider a clear text version of your AD password.
Are you sure you really want to do that?
But if your enterprise and your service provider can implement SAML, then the LDAP pull model looks a lot more compelling. I would be curious to hear from anyone that has implemented this or is thinking of implementing it. And if anyone is using the password hash sync approach, I would be interested in hearing about as well.
Posted in AD, Authentication, Google, Identity, Password Management, Provisioning, SAML, SPML, Standards, Virtual Directory
Tagged Authentication, Google, Provisioning, SAML, SPML, Virtual Directory