Kerberized authorization service

[g.w@hurderos.org]

On Feb 11,  8:30am, John Hascall wrote:
} Subject: Re: Kerberized authorization service

Good day to everyone, hope the approaching end of the week is going
well.

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

I agree completely.  The difference is I tend to believe LDAP
directories are the path which organizations will travel for
maintaining information of this type.

If this is correct and the IDfusion model is viable the necessary
decisions can be made at the application via the authorization API.

> > >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 our thinking 'maybe' implies there is the possibility of more than
a binary answer to the authorization question.

Lets consider the hypothetical case of access to a host via SSH.  It
is entirely realistic to consider an organization may want to store IP
access information in a centralized directory rather than in local
/etc/hosts.allow files.  In this case after confirming the user's
identity the authorization API would answer the yes/no answer based on
a comparison of the connection IP address against a list of allowed IP
addresses for that user.

In the case of, for example, ERP applications the 'maybe' answer will
probably be qualified based on some characterizing element of the
user's role.

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

I certainly wouldn't want that as my legacy.  I'm perhaps more persona
non-grata with the I2 Middleware digiratti than I am the Kerberos
community... :-)

An authorization server implies an environment where the rules/logic
used to validate the authorization decision is detached from the
application itself.  If this is the case all of the authorization
rules for each application need to be replicated in the authorization
server(s).  This may not even be feasible in some commercial or binary
only applications.

In this case the application needs to have access to the relevant
information needed to qualify the authorization decision.  This
implies returning the information to the application after the initial
yes/no decision is made.

Consider Shibboleth.  The return of identity attributes is a
requirement since the application logic is detached from the pool of
user information.

All of this is why I believe there needs to be a standard API for
applications to ask an authorization question.  This would allow
binary only applications to ask a qualified authorization question
while retaining internalized control over the rules logic.

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

I agree 100%, we only differ in our vision on where this will all
happen.  I believe it should happen at the application via a
standardized API to a canonical data repository.

Irregardless, the primary challenge is intercalating the request for
authorization into the program logic.  Not a problem where application
source is available but a big issue for binary applications.

Thats why I believe it is critical for the open-source community to
lead the way in defining this API.  Done properly the implementation
of the API could be done with either IDfusion or an external
authorization server.

> As soon as you talk about doing this in a space larger than one
> computer you are talking about a network protocol.

As I've stated before I believe that network protocol is/will be LDAP.

With respect to authorization servers one also has to consider a space
larger than one application or service.  In that case there either
needs to be multiple authorization servers or a protocol which allows
the client to differentiate what type of service or application is
requesting authorization.

The former scenario suggests increased deployment complexity while the
latter requires development and standardization of a 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.

There is no need for a data provisioning scheme if LDAP is the central
repository for information needed to make the authorization decision.
What is needed is a system for modeling the information so the
applications/API can interpret the data.  This latter concept is what
IDfusion is all about.

Crossing a trust domain raises a host of additional issues which comes
under the generic problem area of Reciprocal Identity Management
(RIM).  Ken had issues with that term, I will follow up in the context
of a reply to him on that concept.

> John

Hope the semester is going well.

Have a good weekend.

}-- End of excerpt from John Hascall

As always,
Greg Wettstein

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"If you get to thinkin' you're a person of some influence, try
 orderin' somebody else's dog around."
                                -- Cowboy Wisdom