Apps aquiring tickets (was Re: gssapi/openssh)

[Dr. Greg Wettstein]

On May 6,  9:16am, Simon Wilkinson wrote:
} Subject: Re: Apps aquiring tickets (was Re: gssapi/openssh)

> On Mon, 5 May 2003, Dr. Greg Wettstein wrote:
> > It would seem that Java would be the language of choice for something
> > like this, it at least makes the graphical issues less of a problem.
> > Since 1.4.x also supports GSSAPI there is low-level support for
> > Kerberos credential management in at least the IBM and SUN
> > distributions.

> GSSAPI doesn't help, unfortunately, as it doesn't contain any routines
> to do credential management.

If I remember the documentation properly I think that at least IBM has
a 'value added' jar file in their 1.4.x distribution for Linux which
has class files for dealing with some Kerberos specific issues such as
credentials acquisition.  I haven't had the time to dig deep enough to
completely understand what is there and what is not there.

They do implement things like kinit in Java so there has to be some
Kerberos specific stuff knocking around in one place or another.  I
did notice that their kinit DOESN'T support obtaining credentials
based on a keytab so their implementation is not as complete as what
comes in C with the MIT distribution.

Hurderos uses something called the SPL (Service Provisioning Layer)
which takes XML-encoded requests for service provisoning commands from
the identity and services management engine.  Since SPL needs to
authenticate itself it needs to get various service tickets.  As the
code base has been built and tested up to this point on 1.3.x I had to
write Java wrappers around the MIT C based utilities to do things like
credentials acquisition.  As I began studying 1.4.x I was reasonably
confident that most of what would be needed was now going to be
available in Java.

> > So again, all thats needed is someone with some spare coding
> > cycles... :-)
> 
> Something like this has been on my list for a long time now. I think the
> big problem is that exactly _what_ it does is going to be incredibly
> dependent on the local system. For example, what I'd like is something
> which uses PAM to do the reinitialization, so that other credentials (such
> as those for x509 and AFS) can be renewed at the same time.
> 
> The key implementation issue is, I think, how you keep up with all of
> things that a user can do with a credentials cache. When this cache is
> administered via a shared-memory API, you've at least got a common entry
> point you can monitor. With file based ccaches, you don't really have that
> - as you need to handle situations such as the user removing the file,
> changing KRB55CNAME to point elsewhere, and copying a different file over
> their current cache.

I certainly agree with your assertions and concerns on these issues.
It also seems that we share a common belief that attention should be
focused on using PAM in order to centralize a lot of this
functionality.

While not strictly on topic I think that PAM would also benefit from
these efforts.  While PAM is a very powerful facility there are not
enough people thinking about all the engineering issues with respect
to SSO and what is required.  Most of my current efforts are directed
at dealing with the fact that while PAM deals with orthogonality
between representational and internal identities there are very few
applications coded to properly deal with the implications of this.

The problems with respect to the multiplicity of presentation problems
that managing credentials caches poses may be, paradoxically, becoming
easier.  I'm assuming that, for the most part, something like a
management/refresh daemon would be desired for users who posess less
in the way of technical skills than those of us building the
infrastructure.  In the push button world of GUI's which most people
would be using there is probably a reasonably high probability that
the cache could be managed without the user interfering with it too
much.

I've told a number of people that simple RFC compliance is only one,
very small, part of the puzzle with respect to providing a unified
authentication and authorization infrastructure.  There are huge
killer issues as simple as where does the credentials cache go that
pose significant inter-operability problems.  I am chagrined that
something like ms2mit actually needs to exist.

> S.

Thanks for the reflections Simon, best wishes for a productive week.

}-- End of excerpt from Simon Wilkinson

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-4950            WWW: http://www.enjellic.com
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"This is a single non-reentrant routine which takes the received packet
queue and throws it at the networking layers in the hope that something
useful will emerge."
                                -- dev.c, Linux Networking Sources