Tag Archives: Federation

When did federation become a blame game?

I have noticed a disturbing trend recently. A lot of vendors seem to have taken the position that as soon as their help desk finds out that there is federation with another vendor involved, they immediately toss it over the wall.

I have seen my company (Optimal IdM) have to spend a lot of time and resources helping customers when vendor that really needs to solve the problem won’t do even the basic trouble shooting as soon a federation is involved.

So here is the question, is this because not enough support folks understand federation, or is that they do but want to reduce their work queue and see a convenient scapegoat?

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.

Tell us how you really feel…

Okta has some choice words about ADFS in this recent post. I always felt that if you can’t say anything nice… don’t blog about it.

Jackson Shaw points out that the operative four letter word is FREE.

Claiming your product is better than a free product is a losing argument. A better approach is to make a product that co-exists with, and extends, a free product.

That’s where VIS and VIS Fedaration come in. ADFS is a great tool for a lot of enterprises. But for some enterprises it needs a little help. The OptimalIdM products work side by side with ADFS and AD and extend their capabilities.

[Full disclosure: I am an employee of OptimalIdM]

OptimalIdM and WIF

OptimalIdM has announce support for Microsoft WIF (you can get more info here). What they have done is pretty interesting. The have created an STS that front ends their Virtual Directory. This allows a single STS to be used to issue claims against multiple identity stores.

Of course the main use case here is the multiple AD forest scenario, but it could also support disparate identity stores such as other LDAP directories, databases, etc.

[Full disclosure: I have done consulting work for OptimalIdm in the past.]

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.

King of the wild frontier

You have to love it when someone ties together Davy Crockett and the iPhone as Mark Wilcox does here. And he makes a great point about federation as well:

Thus you should begin adjusting requirements. For example – its time to break the addiction thinking that just to get access to IT resources they need to log into a Windows domain. Instead focus on network-based services such as file shares & network mail (whether Web and/or IMAP based).

Accept that federation (such as SAML) is not just SSO between your company and a remote service but really about SSO between domains that do not control the other. Sometimes that is going to be an external partner but it could also be another business unit.

When I was with BMC/OpenNetwork I often worked on federation projects that did exactly that. Companies where federation (typically SAML) was used to allow users to cross domains with organization. One example was a large communications company that had acquired multiple subsidiaries that still operated fairly independently. They wanted all users to be able to access common services such as HR Portals. In such an environment provision usually plays a key role as well as federation (one could even call it federated provisioning).

There is one IT/Davy Crockett analogy I want to make:

Be careful what cause you take up. It may not end well for you if you choose poorly.

Janus versus Vulcan in Federated Provisioning

I always thought the Roman God Janus should be the patron deity of security professionals. From the Wiki page on Janus:

In Roman mythology, Janus (or Ianus) was the god of gates, doors, doorways, beginnings and endings. His most prominent remnants in modern culture are his namesakes: the month of January, which begins the new year, and the janitor, who is a caretaker of doors and halls.

Likewise I see Vulcan as the symbol of those toiling in the system integration and provisioning fields. Crafting unsexy and necessary technologies that make disparate IT systems work together. From the Wiki page on Vulcan:

The Romans identified Vulcan with the Greek smith-god Hephaestus, and he became associated like his Greek counterpart with the constructive use of fire in metalworking.

This comparison came to me as I was reading the recent flurry of posts about Federated Provisioning. You can go here to read the latest from Dave Kearns, Pamela Dingle, Ian Glazer, and Nishant Kaushik. These are some really smart people who make some good points, but they are mostly talking past each other. This is a Mars versus Venus kind of debate, only it’s really Janus versus Vulcan.

The federation (Janus) side of the federated provisioning discussion tends to favor the just-in-time-provisioning, minimal disclosure, and privacy aspects of federation. The provisioning (Vulcan) side of the federated provisioning focuses on the total life-cycle of the identities known to both the service provider and consumer.

That’s not to say either is right or wrong. Both have good points. But there are serious holes in the just-in-time provision approach and Pamela’s just-on-usage deprovisioning suggestion. Let me give you an example to illustrate.

Suppose ACME is outsourcing one of its sales application. Now support the SaaS application has a feature that lets you (as a sales manager) assign a sales lead to one of your salesmen. Right off the bat you should see the first problem. How do you get the salesman’s information into the system if he has never performed the federated authentication step (I am intentionally being protocol agnostic here). Clearly ACME must have bulk provisioned all the salesmen to the application when setting up the service.

But what happens when a new salesman is hired? A provisioning process should be in place to provisioning the new salesman to all the SaaS services that need to know about him. But what happens if the new salesman doesn’t work out and is let go? Cleary ACME doesn’t want to him to still show up in the list of people that sales leads could get assigned to. Just-in-time-provisioning and deprovisioning just won’t be sufficient for many applications because the identity information needs to be synchronized before the user performs his first authentication. This can be true of any application where the users interact with each other.

In addition to the data synchronization problems in Federated Provisioning, there is also the auditing issue. How does ACME audit what its salesmen did in the application? Right now there isn’t a standard that covers “Federated Auditing”, but I predict that it is something customers are going to start asking for if the truly embrace SaaS.

I guess you could say I am more Vulcan than Janus.