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]

Federated Provisioning

Nishant Kaushik has a great (and funny) slide deck on federated provisioning on his blog. He discusses some distinctions between two flavors of federated provisioning, the Just-in-time (JIT) and what he terms advanced provisioning (often referred to as bulk provisioning).

I would like to clarify a couple of points in his presentation, however. He talks about a possible SAML profile of SPML for JIT provisioning. There was already an effort (which I lead) to define a SAML profile of SPML in Project Liberty (most of the work has already been done if anyone wants to revive it). But this was not for JIT provisioning as there is really no need for SPML when doing JIT provisioning. JIT provisioning can be done by SAML alone (or OpenID+other stuff). Rather the SAML profile of SPML was intended for advanced (bulk) provisioning. While the DSML profile could be used for advanced provisioning the Liberty TEG felt that using the SAML attributes assertions as the provisioning data structure was a better fit for advance provisioning accounts that would later be used in a SAML sign-on.

Me, I see it six one way, half dozen the other.

Another point the Nishant brought up is the need for the equivalent of the SAML attribute query in SPML. That already exists in the form of the SPML Search query which supports getting a single user record and asking for a subset of attributes.

When discussion whether JIT or advanced provisioning is appropriate, the points that are usually brought up are auditing, de-provisioning, and billing. But Nishant overlooks the most important point:

Do the identities have any meaning outside of authentication?

If the answer for your service is yes, than JIT provisioning is likely not an option.This is not a case of “tightly coupled” versus “loosely coupled”. Rather it is a matter of business requirements.

Take my current employer CareMedic (now part of Ingenix). We have a suite of medical revenue cycle management web apps that we host as SaaS. We need to know the identities of our customer users for the purposes of workflow before the user actually logs into the system.

Of course there are plenty of apps where the business requirements make JIT provisioning ideal. But it still comes down to the business requirements, not the technical architecture or standards.

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.

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.

It’s not always about you

Pat Patterson points out that the Liberty ID-WSF protocol is a nice fit for Federated Provisioning:

Now, in my Liberty-tinged version, when sending a new user to Omega, Acme includes a reference to their Employee Profile (EP) service – essentially the service’s endpoint URL – in the SAML assertion. This endpoint reference serves as both a description of where to find the service and permission for Omega (when sent as part of the signed SAML assertion) to invoke that service.

On receiving the assertion, Omega send a signed request to the EP service, the request containing the SAML assertion it just received. Now, the EP service knows that Omega is entitled to access that employee’s data, since it has a signed SAML assertion, issued by Acme itself, that says exactly that (via the presence of the EP endpoint reference). The EP can return exactly the data required (this will have been configured according to the underlying contract between Acme and Omega).

Now there is absolutely nothing wrong with this scenario. SAML in conjunction with ID-WSF is a very reasonable way for information about You (the person needing to be provisioned) to be conveyed to the service provider. For You, all the bases are covered.

But there is one big problem here. It’s not always about You.

Think about any enterprise application that You use. How much data concerns You and how much data concerns Somebody Else? I am talking about data such as contact lists, workflow approvers, roles, responsibilities, etc. How does all this data about Somebody Else get synchronized in a timely enough fashion to useful to You?

For instance if John is an approver in a workflow in a hosted application, and John is laid off, how does John get removed as a approver? How does Mary get added in his place? Do all the requests that John need to approve sit in limbo until an administrator manually makes the change? Sadly that’s how it usually handled now.

The SAML/ID-WSF solution is fine for many applications. It just isn’t sufficient for moving many of today’s enterprise applications to a SaaS model.