Comments on: Can OAuth do what SPML hasn’t?

By: The Smoking Monkey » Blog Archive » Bookmarks for February 10th

The Smoking Monkey » Blog Archive » Bookmarks for February 10th — Fri, 12 Feb 2010 20:03:25 +0000

[...] Can OAuth do what SPML hasn’t? – Talking Identity – [...]

By: SPML, SAML, OAUTH, and Impedance Mismatch « Identity Blogger

SPML, SAML, OAUTH, and Impedance Mismatch « Identity Blogger — Thu, 03 Dec 2009 13:27:34 +0000

[...] 3, 2009 · Leave a Comment Nishant Kaushik posits and interesting question; can OAUTH fill the provisioning role in Just-in-time federated provisioning. Mark Wilcox follows [...]

By: NishantKaushik

NishantKaushik — Mon, 30 Nov 2009 17:17:23 +0000

In an ideal world, you are right that the RP shouldn't need to create or store the identity. But this use case is aimed at those (existing) systems that enterprises are trying to open up to external domains that need internal stores to be provisioned to function. And sadly, this covers the majority of those systems.

By: NishantKaushik

NishantKaushik — Mon, 30 Nov 2009 17:15:42 +0000

Some of this is addressed in the other comments on this and my previous fed-prov posts. You never want to pollute the SAML assertion with all the extra attributes needed for JIT Provisioning on the off-chance that it might be needed. The SAML assertion should have minimal information. And out-of-band provisioning has faced some significant adoption challenges because of the complexity involved. My thought on OAuth usage is aimed at smoothing some of that, though not solving it completely (the SPML-like API still needs to exist, and the non standard way of using the standard is still a problem).

By: NishantKaushik

NishantKaushik — Mon, 30 Nov 2009 17:09:39 +0000

Pretty much, Eve. And I do think that there are good things in both IGF and UMA that can come together in a way to make the whole thing both user- and enterprise-friendly at the same time. The big thing that needs to happen (the point of the post title) is that we (the IdM industry) need to make it easy for RPs to connect to IdPs in an enterprise grade federation.

By: willemdepater

willemdepater — Mon, 30 Nov 2009 11:57:12 +0000

We see a lot of traction around the idea of NOT having to provision the Identity to the service provider or relying party, either pre using SPML or JIT.

Why should we not use some sort of VJIT (Volatile JIT) provisoning?

Meaning the SP or RP doesn´t need to create or store the Identity, but is just able to use the provided information (assertion/attributes) in making authorization decisions, auditing the information and so on. All without storing the Identity at the SP or RP.

By: l33tpmp

l33tpmp — Wed, 25 Nov 2009 12:03:06 +0000

Why not just include the appropriate attributes for JIT Provisioning in the SAML Assertion during federated SSO?, these attributes are set by the IDP Any need for out of band or pre-provisioning can be done with SPML. In my opinion, the user centric identity assertion stuff like OpenID and Cardspace hasn't really gained any traction (maybe less than SPML has). I do like the idea of the IDP sending intent and policy to the RP (SP). Not sure if using a user provisioning product to send policy information is the right way to go.. but it's certainly worth further discussion.

By: Eve Maler

Eve Maler — Tue, 24 Nov 2009 21:10:13 +0000

(Thanks for the namecheck! Interesting… So I'm guessing you'd have a (perhaps truly RESTful) SPML-ish interface offered by the provisioning service on the IdP's side, and the provisioning service on the RP's side authenticates to the other side in (two-legged?) OAuth fashion before making its data requests. OAuth provides the authenticated-request substrate, but (as is the case in other uses of OAuth) the responding side would still have to publish its API for doing application-level stuff.

(For the intent-and-policy requirement, maybe IGF in combination with an enterprise-friendly UMA could someday fill the bill.