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.

Advertisements

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.