OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]