Category Archives: Authentication

Optimal IdM wins best of Tech Ed for Cloud Products

Great news, our VIS for Office 365 product won the Windows IT Pro Best of Tech Ed award.

It really is a great product. The key is that it dramatically simplifies Office 365 adoption for customers with complex multi-forest AD environments.

OAuth 2.0 and authentication

Vittorio Bettocci from Microsoft has a great write up of OAuth 2.0 and how it relates to  authentication protocols (but is not one itself). You can read it here.

Office365 announcement

OptimalIdM announced its new Office365 offering this morning. You can read the announcement here.

This has been an great project to work on. OptimalIdM can now enhance Office365 with a great set of new features and can do so for both the WS-Federation Passive and Active profiles. The Active Profile is used for Office365 Lync and Outlook support.

The new features we add to Office365 include easy multi-forest support, support for non-AD users, support for users with non-addressable UPNs, two-factor authentication, auditing, and a whole bunch of other features.

Exciting times!

Stealing the keys to the kingdom

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.

I thought xauth was a Unix command…

Axel Nennker is calling out Google and Meebo for the privacy aspects of the new XAuth spec.

Peter Yarid has some thoughts here, but criticizes it more from a business than privacy standpoint.

Techie-buzz has this candidate for the understatement award:

There are of course privacy implications because not every user would want every website in the world to know what social networks it uses.

Gee, you think?

Familiar Ground

Johannes Ernst is predicting the demise of the RDBMS (and by extension Oracle) due to the growing popularity of NoSQL. While these kinds of technology trends are hard to predict, there is a lot of logic to what Johannes is saying. He could very well be proven prophetic.

But this is familiar ground. We have been here before.

I remember in the mid 90’s when Object Databases were going to kill the RDBMS. Of course what really happened was that Object-Relational-Mapping APIs became popular instead.

Later XML Databases were going to kill the RDBMS. Instead RDBMS vendors added native XML capabilities to their mainline products.

There are specific functional areas where RDBMSs have been displaced. For instance LDAP directories have mostly replaced RDBMSs for identity and authentication information.  But this has not dented overall RDBMS usage.

So can NoSQL slay the RDBMS after OO and XML failed? Perhaps, but I wouldn’t short Oracle just yet.

It’s all about the PEP

Jackson Shaw has this to say about authorization via SAML vs XACML. Jonathan Sander follows up with some very good comments about SAML vs XACML.

I really like XACML. Ideally, it should be much more widely used. But when push comes to shove it’s really all about the policy enforcement point (PEP).

SAML can be an easy (relatively) bridging technology that really doesn’t require significant changes to the back-end systems. All that is needed is to create a SAML end point that receives the authentication and creates an authn token appropriate for the services being authenticated. It may also need to provision identity information, but that’s another discussion. The point is the services can still leverage the same authentication token they used before SAML was added.

XACML, on the other hand, will require changes to services to make the appropriate XACML authz queries. In other words, the service needs to become a PEP.

An alternative approach is to pass SAML attribute assertions during the authentication that are converted to updates to a user attribute store (in a DB table or directory). Those attributes are then used for authorization decisions by the service. The same can be done with role information.

You could argue that ABAC and RBAC are not sufficient. But chances are the service you are trying to federate is already ABAC or RBAC based. That and the fact that SAML will be implemented first, makes  XACML a hard sell.

Pulling LDAP

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.

Identity Apocalypse Now

Jonathan Sander of Quest has this to say about the coming identity apocalypse. Interesting stuff.

This got me thinking to a fascinating aspect of identity management in the ASP (and SaaS) space, and that it the delegated nature of identity. For example my current employer CareMedic (now part of Ingenix) offers hosted services where authorization decisions are made based on the identity of the user. Since these are medical revenue cycle applications, the authorization decisions are covered by various regulations such as HIPPA.

But here is the interesting part. We don’t really need verify that the identity we know is actually a specific person. We trust our customers (the health care service providers) to validate that the identities they provide us are properly vetted and they determine the roles that those identities fulfill.

And this is the fundamental trust issue pertaining to the identity providers that Jonathan Sander discusses. The entity with the financial stake must validate the real person behind the identity.

SPML, SAML, OAUTH, and Impedance Mismatch

Nishant Kaushik posits an interesting question; can OAUTH fill the provisioning role in Just-in-time federated provisioning. Mark Wilcox follows up here and here.

I agree with Mark’s commenter who suggests that a SAML attribute service fills the role just as well. Mark suggests that a SAML attribute query is too difficult to implement in some development environments. But I am not sure that I buy the argument that there are environments where doing the SAML SSO is doable but doing the attribute query isn’t.

Regardless all this got me thinking about impedance matching. When we wear our standards hat, all things are possible. But we need to step back at times and put on our developer hat and think about how are designs are going to be implements. While we could mix SAML and OAUTH to support JIT federated provisioning, implementation now requires tools, libraries, and implementers that can implement both SAML and OAUTH as well as handle the rough edges where the don’t mesh well. That’s an impedance mismatch in my opinion.