[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 implementation. 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 established. > 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]