> 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.
> 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 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
|