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 [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
