[OpenAFS] Authentication without aklog

[Dave Botsch]

On Linux, we use krb5-auth-dialog with its aklog plugin.
Krb5-auth-dialog auto renews tickets and tokens, which is really nice
(no need to run a separate krenew).

On Mac (and replaced with krb5-auth-dialog for Linux), we use my now
quite old AFSTokens application as an all-in-one app. Like I said, it's
quite old and the code needs some updating, but it's there. And it works
with cross-realm principals!

AFSTokens doesn't do auto renew, but that would be easy enough to put in
there.  It also just uses the current kerberos cache instead of making
its own cache.

On Mac, destroying tokens is broken for some reason. Oh, well :) And
XCode broke the project, so to update it, one would have to make a new
XCode project and connect the gui components to the underlying code
components.


On Thu, Jul 31, 2014 at 03:29:47PM -0500, Andrew Deason wrote:
> Hi all,
> 
> I've had a few users and administrators complain to me from time to time
> about the existence of 'aklog'. (By 'aklog' I really mean any mechanism
> to convert krb5 tickets to AFS tokens, but I'm referring to them all as
> 'aklog' for simplicity.) The need for an AFS-specific authentication
> step is an annoyance for some, and for some others, prohibits the use of
> AFS in some applications.
> 
> The first time I heard this I was a bit surprised, but that may be just
> because I'm very used to the 'aklog' approach and find it intuitive. You
> need to tell the kernel what credentials you want it to use for AFS
> access; makes sense to me.
> 
> The alternative is to effectively "guess" what credentials we should be
> using, which is what NFSv4 does (rpc.gssd). That is, all you need to do
> to authenticate is to run a plain 'kinit' or equivalent (with no
> knowledge of AFS/NFS), and the kernel tries to find the ccache you used
> and turn it into a token itself. This approach has a noticeable number
> of cases where it does the wrong thing, and so you hear complaints about
> it from time to time. But when it works correctly, it's invisible, so I
> expect the only time you hear about it (from users) are the complaints.
> 
> But, at least for some environments, the downsides of rpc.gssd are
> smaller than the downsides of needing to run 'aklog' at all. I don't
> expect openafs to completely get rid of aklog and move to an rpc.gssd
> approach (I personally don't think I would like that), but I think there
> may be some compromises that would be helpful to people.
> 
> Some possible approaches:
> 
>  - We could have a client option to make rpc.gssd-like behavior a
>    fallback, if no other credentials were set with e.g. 'aklog'.
>  
>  - We could have an option to turn on rpc.gssd-like behavior as a
>    fallback for a specific PAG. That is, within a pag you say something
>    like 'pagctl pick-my-creds --enable'. ('pagctl' doesn't exist yet, of
>    course; it's just an idea in my head)
> 
>  - We could have an option to aklog that would automatically renew
>    credentials using the information available to aklog at the time. For
>    example, if you run, say, 'aklog -autorenew', aklog would tell the
>    kernel its KRB5CCNAME and any other relevant information, and the
>    kernel would later on run an equivalent aklog command to obtain
>    credentials in exactly the same way for that PAG. For example, if
>    KRB5CCNAME was set to FILE:/tmp/foo1234, the kernel would later on
>    try to use the ccache file /tmp/foo1234 to obtain creds before the
>    existing creds expire.
> 
> With those last two, you still need to run some afs-specific command for
> authentication, but you only need to run it once for the entire life of
> the "session"/PAG. That's still annoying, but it removes the need for
> renewing credentials within the actual session, which is not always
> practical. (k5start/krenew works for many cases, but sometimes you don't
> have the ability to run your own command)
> 
> 
> Anyway, I'm sending this to the -info list to try to get some feedback
> from other users. I've mentioned these ideas briefly to a few others,
> who seemed to want something in this direction, but I'd like to get
> opinions and feedback from as many sites as possible. The actual details
> of implementing these ideas is a discussion for developers, but just
> seeing what behavior people want is a discussion for here.
> 
> So, please speak up. Does this sound helpful do you? Or a bad idea? Or
> anything else? Feedback is appreciated, even if it's just a "yeah, that
> would be nice to have", or even "I don't really care".
> 
> Also, while I would prefer that any feedback goes to the list, if you
> don't want to send to the list for any reason, even just sending
> something directly to me is helpful, so I at least know your opinion.
> 
> -- 
> Andrew Deason
> adeason@sinenomine.net
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 
********************************
David William Botsch
Programmer/Analyst
@CNFComputing
botsch@cnf.cornell.edu
********************************