Greg, Thankyou for your feedback. I am sorry it has taken me a few days to respond.
Anyway, I include my feedback below : Thanks, Tim. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 19 September 2003 18:33 To: Tim Alsop; [EMAIL PROTECTED] Subject: Re: Kerberos / PAM Usage ? On Sep 18, 6:26pm, Tim Alsop wrote: } Subject: Kerberos / PAM Usage ? > Hi, Good morning to Tim and everyone on the list. Tim> Good evening/morning to you - it is probably morning for you, but evening for me :-) > I am looking for advice and feedback from the Kerberos community in > relation to UNIX, PAM and Kerberos. If you can provide me with some > feedback based on your views and experiences it would be very much > appreciated. > > It is clear that PAM is becoming a common way to provide pluggable > authentication services on UNIX or Linux operating systems. I am > particularly interested in PAM for authorisation and wanted to hear > from you about this. If you can help me, please provide feedback on > the points listed below : Fascinating. Its been my experience that people in the industry don't seem to understand authorization or perhaps don't understand the technology when they see it. Tim> yes, this is correct. The nature of my question might not have made my need for this feedback very clear. I hope that my response to Marcus made recently on this same subject helps explain ? I've been working for about five+ years on the issue, a few reflections FWIW, on what I have encountered. Tim> I look forward to being able to benefit from your experience in this space. > 1. Do you, or the company you represent use Kerberos, or are you > considering using Kerberos with PAM for authorisation, authentication, > or both authentication and authorisation. Yes. My interest has been on addressing issues which allow Kerberos to be used to synergize an open-architecture authorization scheme. > Note: Currently PAM with Kerberos can be used for authentication so > that login to the operating system directly at console, or via telnet > can be handled consistently. The use of PAM for authorisation would > involve checking .k5login files in home directories and/or using an > aname database on each system, or perhaps some other form of > mechanism. PAM is actually not carrying out Kerberos authentication, at least not with the pam_krb5 module which everyone seems to be using. Instead PAM is using Kerberos to do validation of authentication tokens, ie. passwords. There are actually well taken purists who will claim that using Kerberos with PAM is inherently evil in a strict security context. Tim> This is related to use of PAM for authentication. I am more concerned with authorisation and PAM. I don't think that using .k5login files as the basis for PAM authorization makes sense or is scalable. There is already a well understood role for the .k5login files. Extending them to implement any type of significant authorization strategy would require either changing the semantics of a widely used system or crafting extensions on top of it. Given the complexity of issues that a proper authorization system needs to deal with the latter course would be a poor architectural decision. Tim> Yes, I agree. My question relates more to having an application that uses a PAM module and then the PAM module is configured to either use local .k5login files, make a lookup via LDAP, or use some other method to determine if a specific principal can access a certain unix account. Maintaining an aname database on each system is also not scalable and questionable from a security perspective. Directory services, ie LDAP, is really the appropriate technology to craft any type of significant authorization system on. Tim> yes, correct. This is why I am looking for feedback on whether PAM would be an appropriate way to allow both aname/.k5login to be used and then gradually change to using an LDAP approach (or some other approach) without having to change each application. Changing the PAM module, or configuring the PAM module would allow all authorisation checks to be switched to the new method - this is far more acceptable than having each application make the authorisation check itself once it has authenitcated the user ? Any comments ? > 2. If you are using, or considering using PAM for authorisation I > would like to hear if you using it with .k5login files, or checking > authorisation via an LDAP lookup, or some other method. Can you > provide details of your usage, or intended usage of PAM for > authorisation ? The industry has two well understood technologies on which to build an open-architecture authorization strategy, Kerberos and LDAP. Perhaps the most important question is how to blend these technologies in an appropriate fashion which synergizes the strengths of each component technology. Tim> Yes, I agree. This is why I am interested in this and also interested in your Hurderos project. This is what the Hurderos Project is focusing on. In IDfusion authorization flows directly from a strong identity generation model. Kerberos is used to authenticate both the fundamental (user, service, server) and derived (authorization) identities. The Hurderos source release includes a hurderos_pam module which implements the IDfusion authorization model using a combination of both Kerberos and LDAP technologies. One of the questions which arises is which of the four PAM phases should implement authorization. In the case of hurderos_pam the decision was made to use the account management phase and implement the necessary code through the pam_sm_acct_mgmt API call. PAM has a number of warts when an attempt is made to extend it past authentication. Its a useful technology but a number of issues need to be addressed when extending it to more sophisticated identity and authorization tasks. Most notable is the fact that PAM has infra-structure to handle identity translation but I have yet to see an application which has been coded properly to handle it. The callback system (pam_converse) is a bit clumsy as well and tends to show its heritage as an interactive login authentication mechanism. I've spent a fair amount of time coding up patches to common applications to allow their PAM support to implement identity translation and a more sophisticated authorization strategy. These will be included in the source release. I've had some interesting conversations with implementors of ERP solutions on the subject of authorization. By and large both the open-source community and proprietary solution providers need to do a lot of thinking before code-bases are ready to handle authorization in a more sophisticated fashion. Tim> I would love to talk to you more about this when you/I have time to discuss Hurderos. > 3. Do you have any GSS-API enabled applications, or any Kerberos > enabled applications that accept a security context to determine the > users principal name and then use PAM for authorisation, or do you > have any applications that you would like have enabled in this > way ? Yes, I've coded support into applications for PAM to make an authorization decision based on a GSSAPI/KRB5 authenticated identity token . You haven't even begun to understand the warts of PAM application support until you enter that domain. Tim> yes, this is what we want to do. Hurderos actually treats Kerberos as an authorizable service. This is actually an artifact of strict isolation between intrinsic and representational identities. From a PAM authorization perspective it actually makes life a little bit easier. Tim> Sounds interesting. It also makes it easy to quickly shutdown user access without disturbing the user's authentication status. Denying authorization for Kerberos service effectively denies all service delivery since the user can't authenticate themselves. Tim> Does Hurderos make a course grained entitlement decision at the KDC, thereby deciding whether to issue a service ticket for a specific principal based on authorisation rules ? > Many thanks in advance for your help, > > Tim Alsop Indeed, FWIW, it seems. }-- End of excerpt from Tim Alsop As always, GW The Hurderos Project - Open Identity and Authorization Management ------------------------------------------------------------------------------ "The vast majority of human beings dislike and even dread all notions with which they are not familiar. Hence it comes about that at their first appearance innovators have always been derided as fools and madmen." -- Aldous Huxley ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
