RE: [saml-dev] RE: How to provide SAML assertions in RESTful services

[Vikas Jain <VIKAS.JAIN@ORACLE.COM>]

This is a great discussion kicking off, and couldn't stop jumping in.
Here are some other alternatives I see,

Using HTTP Authorization header: Client app acquires SAML token(HOK) from STS and sends it in the Authorization header of the REST request. See http://bit.ly/aKPYB1

Outlook calling Google apps over REST using OAUTH + SAML. See http://bit.ly/bCkfIY

Camera(device) calling Picasa(App) over REST to upload pictures. See http://bit.ly/cxJtIS 

Would love to hear everyone's thoughts (pros/cons) on these approaches.

Btw, looks like it's time that specs similar to WS-* get invented for REST albeit lightweight to keep the promise of REST alive.

Cheers,
Vikas Jain | Principal Product Manager | 650-506-8923
Oracle Web Services Manager, Fusion Middleware
200 Oracle Parkway, Redwood Shores, CA 94065 
Blog: http://ws-security.blogspot.com 

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Friday, June 25, 2010 4:18 PM
To: Moehrke, John (GE Healthcare)
Cc: saml-dev@lists.oasis-open.org
Subject: Re: [saml-dev] RE: How to provide SAML assertions in RESTful services


On Jun 25, 2010, at 5:29 PM, "Moehrke, John (GE Healthcare)" <John.Moehrke@med.ge.com> wrote:

>> 
> Our assumption is that the SAML assertion is more than just a fancy 
> way to send a username. But clearly I might not be fully aware of what 
> more I should expect to get out of the SAML assertion than a fancy way 
> to carry the username.

It's more than a fancy username because you're using a signed object containing potentially other info. But it isn't a token that authenticates the message to the server, and it doesn't prove to the server that the user explicitly authorized the action the client is taking.

>> 
>> 
> There are times when the client is it-self an identity issuer, but 
> this is a degenerate case. Right?

Your client isn't issuing identity in that sense, but it is claiming without direct proof from the assertion issuer that the user is present, intending to perform the requested action, etc.

> So, we want the SAML assertion to be capable of being validated as it 
> might be issued by a trusted-third-party... hence federation. Right?

Yes, but what you're validating is that the issuer is claiming various things about the subject, not that the issuer has authenticated that user or the client system to perform some action for that user. In other words, it's data, not something like a Kerberos ticket.

>> 
>> 
> I suspect from your words, that I am missing something. What 'security 
> properties relevant to SAML' are you referring to?

Mainly subject confirmation, the thing that turns signed data into a security token that authenticates the party presenting it as a stand in for the subject. Like a Kerberos ticket.

> 
>>> So, somehow we need to carry the SAML assertion on the RESTful API.
>> 
>> I think it's just app content.
> Could be. This is one approach we have thought of using. Just a 
> base-64-encoded blob of an attribute. But then what is the attribute 
> name? Is it a reference or the assertion it-self?

That's fairly arbitrary, but personally I don't use references when I don't have to.

> Do we put it in
> parameter or as HTTP-Auth?

Oh, it definitely isn't HTTP-Auth. Because it is *not* authenticating the request.

> Then we might simply not be understanding how to do it right? Or, I 
> hope, I am just not communicating well enough in this email thread.

There is no right or wrong way, but when you use the assertion as just data, it's fairly arbitrary to use that format, just a notational convenience or a way to reuse a few other simple notions like validity period or conditions.

>> 
>>> 
> I understand server-to-server. I understand not browser-to-server. But 
> what do you mean by 'not Token based'?

When I say that, I mean a protocol in which authentication or perhaps some supplementary authz is based on the use of a token, and not on a trusted server saying, without proof, "I'm doing this for user X, and here's some data from an authority you trust about X."

OAuth is certainly a token based approach too. You go somewhere to get a token that let's you in the door, you don't use your key and say "Trust me, John said to do this for him."

When you asked this question, I said ECP from the point of view of how one could use SAML to authenticate a REST request. That isn't this use case, which is much simpler and built around servers authenticating each other and just believing each other when they reference who they're working for.

-- Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: saml-dev-help@lists.oasis-open.org