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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Re: [security-services] draft: SAML 2.0 Bearer Assertion Profile for OAuth 2.0

On Mon, Aug 2, 2010 at 7:25 PM, Scott Cantor <cantor.2@osu.edu> wrote:
>> I was wondering if anyone would notice/comment that I'd constrained it
>> to a single subject conf.  I did that intentionally to try and
>> simplify the validation process.  Allowing for multiple
>> SubjectConfirmations makes validation more difficult.  In particular
>> it makes it hard to provide meaningful feedback when none of the
>> confirmations can be confirmed.
> Why?

Each confirmation must be evaluated and, if considered unsatisfactory,
the reasons must be tracked while the other confirmations are being
checked.  At the end, if none of the confirmations were good, the
reasons for each being unsatisfactory should be reported.  Sure, it
can be done.  But it is more complicated than just rejecting the whole
assertion when some condition in a single confirmation isn't met.  As
I recall, there was even an errata item or two in saml-prof regarding
the wording about finding the one sufficient bearer confirmation
method in an arbitrary number of assertions each with an arbitrary
number of subject confirmations.   I was looking to simplify to lower
the likelihood of making mistakes in this spec and later on in

For example, I've seen Web SSO fail due to some problem with the
NotOnOrAfter, Recipent or InResponseTo in the SubjectConf but the only
feedback given is something like "subject could not be confirmed" or
"invalid assertion" which may be true but is a real PITA to
troubleshoot.  I'll admit that that is not necessarily a good reason
to constrain a specification like I've done, however, I do think
simplicity is a good general guiding principal when possible.  Of
course, one can go too far in simplifying.  I'm honestly not sure if
I've been too simplistic in my limiting things to a single subject
confirmation.  I'll admit that I'm probably biased by having coded
several complex validation routines that account for multiple
assertions with multiple conformations but have never seen anything in
practice beyond a single assertion with a single confirmation (I'm not
saying they don't exist, only that I haven't run across them).

> I'm thinking here of the web app use case. In that scenario, I would SSO
> into the web app (bearer confirmation of browser to web app), and then I
> would like to delegate to the web app the ability to access the authz server
> to obtain the access token (holder of key or bearer confirmation of web app
> to authz server).

In that scenario, are the authz server and the resources it issues
oauth tokens for all part of the same domain as the SP and web app?
Or are they a downstream SP in the delegation chain?   I guess it's
not really material anyway beyond how trust between all the parties is

> It's completely natural for the web app to "get access" to the assertion.
> Why wouldn't it?

Fair enough, I was thinking about different entities at the IdP
getting access to the assertion rather than the receiver of the
assertion at SP as you described above.  That is natural.

I think I understand the point you are making but I'm still on the
fence about it.  I'll raise the issue of allowing more than one
SubjectConfirmation with the OAuth list and see if others that might
implement against this feel strongly one way or the other.

> I'm not saying the subject *can't* be the resource owner, but that's a
> specific flow that may or may not be present. It could simply be some entity
> who has been granted access.  I'm just saying the subject should be, well,
> the subject. Not solely the resource owner, unless it actually is the
> resource owner.

Who is the subject (other than just the subject) if it's not the
resource owner?   Someone whom has been granted access by the resource
owner.  That's delegation (or impersonation if it's not stated), isn't
it?  And wouldn't it be most approprate to represent that delegation
in the assertion?

I feel like there is value in specifying that the resource owner be
expressed in some way in the assertion rather than having the authz
server just have to figure it out based on some access grants that it
likely doesn't know anything about.    The subject seemed like the
most natural way of doing that (other than some combination of subject
and attributes).

> That's one route to take, but it has optional semantics. The new condition
> is more appropriate in most cases since it requires the consumer to
> recognize and accept the delegation.

OK, I just read "SAML V2.0 Condition for Delegation Restriction" and
see how that would be generally preferable to using the
SubjectConfirmation.  But it still seems to me that the subject is the
resource owner and the delegation is a means to represent (and
restrict) the entity that is actually presenting the assertion on
behalf of the subject.

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