On Thu, Oct 21, 2010 at 11:04 AM, Scott Cantor <[log in to unmask]> wrote:
>> You are assuming no one will have a policy that denies access based on
>> the presence of an attribute? I personally think having a policy like
>> that is a real bad idea, but people will try it if you don't prohibit
>> it.
>
> I'm not sure what we could do to "prohibit" it, but it's just not practical.
> Privacy controls alone guarantee that you can't assume data.

Well, you can tell people "don't do that". Mainly I was wondering if
Moonshot had come to consensus on this. From your and Nico's replies
I'm taking you plan to support it under a "it's your foot, shoot it if
you want" philosophy.

>> Then keep in mind that missing attributes due to gathering failures
>> will potentially cause strange, from the point of view of the users,
>> authorization failures (or successes if you don't prohibit what I
>> state above).
>
> Yes, that's the reason many/most federated apps look and behave terribly.
> Apparently they stopped teaching "null checking" at some point in programmer
> school.

I agree it's a programmer's fault if a programmer can distinguish
between "no attributes" and "failed to get attributes". But that's not
what you appear to be saying (quoting you from earlier in the thread):

-quoting-
Given "valid" configurations of the various components, there aren't any
other common sources of failure I can think of, but whatever might occur is
really not something that ought to be visible to an application other than
as missing or insufficient attributes.
-end quoting-

Which seems to be arguing for treating a failure to get attributes as
zero attributes.

Mainly what I'm suggesting is that if there is an attribute gathering
failure, let the app know so that it can say/log "Authorization
failed, but there was an error getting attributes" rather than just
"Authorization Failed". It's far from perfect I realize, but a big
step forward in terms of usability IMHO.

Von

>> I agree making this a fatal error is a catch-22: if the attribute are
>> important it's good, if they weren't you've not got unnecessary
>> fragility. But if it's not a error, make sure there is sufficient
>> instrumentation for debugging "why couldn't I log in?"
>
> I think making it a fatal error should be the apps' choice, not the
> infrastructure's, but I will not disagree that pushing things on to
> developers is tantamount to guaranteeing bad outcomes, at least in the web
> world.
>
>
> -- Scott
>
>
>



-- 
Von Welch Consulting, LLC
Technical Leadership for Distributed Cyberinfrastructure,
Cybersecurity and Federated Identity
[log in to unmask]
www.vonwelch.com
(217) 621-2795