Kerberized authorization service

[John Hascall]

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