[29216] in Kerberos
Re: Kerberized authorization service
daemon@ATHENA.MIT.EDU (John Hascall)
Mon Feb 11 09:32:44 2008
To: kerberos@mit.edu
In-reply-to: Your message of Mon, 11 Feb 2008 07:25:28 -0600.
<200802111325.m1BDPSRM018018@wind.enjellic.com>
Date: Mon, 11 Feb 2008 08:30:55 CST
Message-ID: <9026.1202740255@malison.ait.iastate.edu>
From: John Hascall <john@iastate.edu>
Cc: g.w@hurderos.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Greg Wettstein writes:
> As attractive as it may sound architecturally there is no rationale or
> justification for the concept of an 'authorization server'. It brings
> no value and simply adds complexity, latency and an additional attack
> vector to the IAA stack.
There certianly is value in rationally organizing authorization information.
> >From an application perspective there are three possible answers when
> an authorization decision is requested, they are as follows:
>
> 1.) Yes
> 2.) No
> 3.) Maybe
>
> The 'maybe' decision is what makes an authorization server an
> unrealistic approach. The 'maybe' answer is also what organizations
> are most interested in.
Maybe just means you haven't asked the right question.
> In order to resolve the 'maybe' answer the application has to apply
> some form of decision making process (rules) to a set of
> attributes/information which for all practical purposes is going to be
> supplied by LDAP.
>
> In order to make the decision for the application the authorization
> server either needs to have a copy of the rules or alternately provide
> the informational attributes needed to make the decision back to the
> application.
Sounds like you've just reinvented shibboleth.
> The net result is complexity with little added value.
There is tremendous value in having a canonical place to make
statements like "X is no longer an employee" and have *all* of
X's access rights quickly and accurately reflect this.
As soon as you talk about doing this in a space larger than
one computer you are talking about a network protocol. Now,
I suppose one could, to a certain scale, do this with some
sort of mass data provisioning scheme. When you get large
enough, certainly once you start crossing trust domains,
this is clearly unworkable.
John
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
