Subject: [OAUTH-WG] SAML profile comments/questions from the SAML people

From: Brian Campbell <[email-masked]>
Date: Mon, 9 Aug 2010 10:30:11 -0600

I received some feedback on the SAML profile from a cross posting on
the OASIS SSTC (SAML) list.  Links to the thread topic index are
below[1], if you are interested, but I'll try and summarize the two
primary issues here.

First, concern was expressed that restricting the assertion to only
allow for a single <SubjectConfirmation> element was too limiting.
The restriction basically limits the ability of a single assertion to
be issued for use across multiple use-cases/profiles.   A good example
is the use-case that Prateek recently brought up in a different thread
on this list[2] where the assertion is delivered to an SP via Web SSO
and then that SP uses that same assertion to acquire an access token
for data services at a 3rd party site.    As currently written,
draft-campbell-oauth-saml-00[3], wouldn't allow for that use-case.
I'm starting to think that my attempt at simplification was is indeed
too restrictive.  Allowing for more than one <SubjectConfirmation>
will make the wording in the profile a bit more complicated (as well
as implementing validation) but I think, in the longer term, it's
probably the right thing to do from a spec perspective.  At this point
I'm planning on loosening that restriction in the next draft.  I'm
curious, however, if anyone has any strong opinions on it one way or
the other?

The second issue involves my assumption and requirement in the profile
that the subject of the assertion be the resource owner.  To me, it
seemed like a reasonable and useful constraint that was generally
inline with the spirit of the assertion flow, however, the comments
from Scott (editor of the core SAML specifications) suggest that it's
too constraining and/or inappropriate.  I'm honestly not sure where to
go with this one and am reaching out to this list for
ideas/suggestions/opinions.   I guess I see where he's coming from but
I'm kind of partial to the restriction/guidance as I have it.  Also,
I'm thinking that perhaps the counter example cases he describes would
be better captured by use of the "none" access grant type and a client
assertion (coming in draft -11, I think?).

Thanks,
Brian C

[1] Discussion Thread on SSTC list
http://lists.oasis-open.org/archives/security-services/201008/threads.html#00000
http://lists.oasis-open.org/archives/security-services/201007/threads.html#00034

[2] Discussion Thread with use-case on OAuth list
http://www.ietf.org/mail-archive/web/oauth/current/msg04118.html

[3] draft-campbell-oauth-saml-00 / SAML 2.0 Bearer Assertion Profile
for OAuth 2.0
http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 12 Aug 2010 10:19:11 -0700

On 8/9/10 9:30 AM, "Brian Campbell" <[email-masked]> wrote:

I think it would be reasonable to loosen the language to reflect that the subject is who access will be granted to.   It may or may not be the resource owner, I agree.

-cmort

Thanks,
Brian C

[3] draft-campbell-oauth-saml-00 / SAML 2.0 Bearer Assertion Profile
for OAuth 2.0
http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Aug 2010 14:07:59 -0600

On Thu, Aug 12, 2010 at 11:19 AM, Chuck Mortimore
<[email-masked]> wrote:
> I think it would be reasonable to loosen the language to reflect that the
> subject is who access will be granted to.   It may or may not be the
> resource owner, I agree.

Any thoughts on what that would look like in the spec?    Something
like "The assertion MUST contain a <Subject> element.  The <Subject>
MAY identify the resource owner for whom the access token is being
requested."?   Or just drop the language about resource owner all
together?  Or something else?

What about the two bullets on AuthnStatement?

   o  If the assertion issuer authenticated the subject, the assertion
      SHOULD contain a single <AuthnStatement> representing that
      authentication event.

   o  If the assertion was issued with the intention that the client act
      autonomously on behalf of the subject, an <AuthnStatement> SHOULD
      NOT be included.

They kind of, but not completely, imply/assume some explicit
relationship between the subject and resource owner.

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 19 Aug 2010 15:41:53 -0400

Hi Brian,

Apologies for the late comments (below).
__________________________________________

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Campbell
> Sent: Thursday, August 12, 2010 4:08 PM
> To: Chuck Mortimore
> Cc: oauth
> Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML
> people
> .....

My first reaction on seeing the first bullet is that
the assertion MUST (instead of SHOULD) contain
a single <AuthnStatement> representing that authentication event.
Not sure if this is too strong.

Secondly, is it implicit in Oauth-v2-10 that the 
Authorization Server is able to process 
XML signatures (xmldsig). I'm presuming that if 
the Authorization Server can deal with SAML assertions, 
then it can handle digital signatures.

Thanks.

/thomas/

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 19 Aug 2010 15:52:04 -0400

Again apologies for my late comments.
__________________________________________

> Sent: Monday, August 09, 2010 12:30 PM
> To: oauth
> Subject: [OAUTH-WG] SAML profile comments/questions from the SAML
> people
> 
> too restrictive.  Allowing for more than one <SubjectConfirmation> will
> make the wording in the profile a bit more complicated (as well as
> implementing validation) but I think, in the longer term, it's probably
> the right thing to do from a spec perspective.  At this point I'm
> planning on loosening that restriction in the next draft.  I'm curious,
> however, if anyone has any strong opinions on it one way or the other?

I was under the impression that the Oauth use-case was 
intentionally made to be simple, where the client talks direct to 
the Authorization Server (not via Web-SSO and the SP, 
as in the classic SAML use-case).  Does Oauth-v2 today allow 
the Authorization Server to delegate/relegate the actual 
obtaining of the access token to a 3rd Party?

> inline with the spirit of the assertion flow, ...

I think there are a large number of SAML-based use cases that 
can be interestingly "layered" atop OAuth.  I guess the question 
is how complex should we get in Oauth-v2.  Perhaps for now you 
should make the subject of the assertion be the resource owner, 
to be in-line with the basic Oauth design assumptions.

/thomas/

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Aug 2010 14:12:52 -0600

> Apologies for the late comments (below).

And apologies for my late reply.

> Not sure if this is too strong.

I'm not sure either, to be honest.  I was on the fence between
MUST/SHOULD and MUST NOT/SHOULD NOT in those two bullets respectively.
  Perhaps you are right and the stronger language is warranted.

> then it can handle digital signatures.

Yeah, not all authz servers will support this, of course, but those
that do will need to be able to do XML signatures.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Aug 2010 14:28:36 -0600

Again, sorry for the slow reply.

On Thu, Aug 19, 2010 at 1:52 PM, Thomas Hardjono <[email-masked]> wrote:
> as in the classic SAML use-case).

It is simple in that the client talks directly to the authz server and
exchanges an assertion for an access token. However, the means by
which the client gets the assertion, who issues/signs the assertion,
and how the authz server decides to trust the assertion, are all out
of scope.  That allows for more complex use cases or deployments.

In the case Prateek mentions, for example, the client gets the
assertion via web sso from an IdP that is mutually trusted by the 3rd
party.   I don't think it's the most common use case by any means but
the profile, as I have it written now, would disallow it and that's
probably too restrictive.

>  Does Oauth-v2 today allow

I'm not sure I follow the question?

> to be in-line with the basic Oauth design assumptions.

That was my thinking as well but most of the other feedback I've
gotten about it suggesting it's too restrictive.