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.


2 responses to “Janus versus Vulcan in Federated Provisioning

  1. Welcome to the world of academic provisioning! We’ve been tackling this for years. Pre-provisioning is the only solution, otherwise tutors cannot group their students into cohorts, grant access to specific areas of VLEs etc, until the students log in. Auditing is a big problem too. How does a tutor assess a student who is using resources at a federated partner institution? How can the tutor compare the students’ activity on the remote site with set criteria for grading? Normally federated access uses opaque, privacy protecting identifiers but they don’t cut the mustard in federated eLearning. Also, the group of users who must be granted access to an application changes each semester, while the old ones must be gracefully removed, while still giving them the time to gather up their work and revise. I think I’m a Vulcanised Janus in this case!
    Nice post btw, I must go and read the others.

  2. Pingback: Silo Sync vs. Service Sync - Adventures of an Eternal Optimist

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s