On Thu, Oct 21, 2010 at 10:33 AM, Nicolas Williams
<[log in to unmask]> wrote:
> On Thu, Oct 21, 2010 at 10:25:11AM -0400, Scott Cantor wrote:
>> > I'd appreciate input from a wider audience.
>> >
>> > I guess one question I'd have is why would it tend to fail?
>>
>> Aside from invalid input, generally it wouldn't fail visibly because any
>> internal failures to resolve specific attribute sources would be hidden
>> behind the various plugin façades. Those can fail for all kinds of reasons,
>> like network outages, data source outages, timeouts, Apache and OpenSSL
>> bugs, etc.
>>
>> 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. That's just a fact of life in a
>> federated app.
>
> Agreed.
>
Couple thoughts-
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.
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).
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?"
Von
|