[Philip Mayers] Yes, I'm well aware of the uses of kerberos other than "Check my passwords against it" - my point was I don't know how many python modules are geared up to deal with kerberos (*and* since environment variables are per-process and ZServer is threaded I see some problems with it 'just working'). The LDAP situation was the "thought" I had, closely followed by IMAP and Exchange 2000 for the Worldpilot end of things. I'm not sure what relevance PKINIT has to Zope directly (although it is supremely good for initial authentication, ZServer never sees a users private key) - am I missing something? Surely a traditional TGT would do just as well? [Albert] Not sure if we are at cross purposes. I haven't given any thought to either use of kerberos from browser to Zope or generic use of kerberized python modules by Zope as a client. Sounds like you are far more familiar with the issues than me and should be able to deal with them ;-) There *must* be *some* way to smoothly kerberize python modules and integrate them with Zope. Looks like you might be the guy to do it. (There's a raw sockets interface to python and it's supposed to provide SSL sockets though I haven't seen documentation of that yet). Whoops I should have just said "slow initial logon" below (not necessarily "PKINIT logon").I'm not sure of relevance of PKINIT either. Just mentioning that it's there. Might be relevant to subsequent add-ons for replacing AD completely with something that uses completely standardized certificates with migration path able to use both standard and AD via a Zope intermediary (for both Windows clients expecting AD and other clients conforming to standards). Current draft is: http://search.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-13.tx t (Would need to compare with -09 used by Microsoft if any problems). I expect the Zope environment variables and threading issue would have already come up in some other context and would have a straight forward solution. I don't know any more than what is in: http://www.zope.org/Documentation/How-To/ThreadSafety and the existence of the Shared.py module for holding things shared between threads without making them persistent. I'm only thinking about the scenario in which an end user has a plaintext password for authenticating over an existing standard secure transport method (SSL) to Zope and Zope wants to act on behalf of that identity in accessing various stuff from Microsoft based services, without either the end user or the Zope server having to use Windows. Zope has to be able to act as though it *is* the end user so far as the Microsoft stuff is concerned, like IIS, but without the benefit of the "impersonation" facilities IIS uses from the Windows NT operating system and Internet Explorer browsers from Windows clients. (Legally requires only a single $100 or so "client access licence" for the only client - the Zope server, not 1 for each end user). This seems to me the key to being able to avoid installing lots of otherwise useless Windows servers (and clients) just to provide reasonably seamless applications also available to those you are stuck with. [Philip] The point about the AD groups is a good one - mapping those into Zope roles would seem like a very cool LoginManager plugin, *but* I'm not about to do that with trade-secret information (regardless of the publishing method) and have MS lawyers crawling out of the woodwork... :o) - It's certainly a good idea though. I have deep heebie-jeebies about storing the ticket as a cookie - I realise if it's a secure cookie, then it should be safe, but... A better bet would be the Kerberos cipher suites for TLS (with delegation enabled) RFC2712: ftp://ftp.isi.edu/in-notes/rfc2712.txt or IPSEC with the same (work in progress, no link available), or some kind of SASL or SNEGO HTTP auth mechanism, but that has high reauthentication costs for opening new connections. [Albert] Yep, the idea is essentially a LoginManager plugin, able to authenticate on behalf of the user to Active Directory like any other Windows client, and then able to access other Microsoft based stuff *as* that user and also able to seamlessly apply the same groups/permissions stored in AD to any resources Zope makes available directly itself. Unless I've misunderstood, the standard kerberos "delegation" won't actually work for Win2K stuff because it needs the SID/PAC and list of groups in the Microsoft extension to kerberos tickets. Getting around that would help "change the world". These extensions are both: a) A good idea for a much more flexible and scalable mechanism which ties in nicely to things like Zope roles. A server doesn't need an extra lookup of group membership etc in the directory for each "hit", once it has that ticket. b) A typical Microsoft ploy for encouraging "upgrades" from "problematic" unix boxes that don't fit in seamlessly with Microsoft boxes, while still being able to claim a minimal "single signon" facility across both unix and windows. (Unix boxes can authenticate via AD and Kerberos, - they just can't do much else with the ticket so other services end up having to maintain and replicate their own access control information for each user anyway). See section 3.5 of the kerberos faq: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html There's definately no problem with Microsoft lawyers. Whoever first published it might have broken some NDA, though one can't even be sure of that as people often decide to release documents that were previously confidential without changing the labels on the original document - it is the act of publishing the document that makes it no longer a "secret" - not the presence of words saying whether it was once thought to be so. The tech specs are now in the public domain and have been for some time. It isn't patentable or copyrightable (apart from the actual document) and it's no longer secret. The actual document can be rewritten as an informational RFC and interoperable implementations can work from that. It's exactly the same situation as Samba having figured out how to replace an NT4 domain controller without access to either the specs or the source code. Essentially this *is* the obstacle to replacing a Win2K domain controller. (Microsoft started promoting SMB as CIFS, *because* Samba had done that - making the best of it - no lawyers involved). All the rest of the specs needed are in detailed documentation of Active Directory and Windows security infrastructure available from MSDN. Just that part has been missing. What's needed now to get the ball rolling on other bits is just an implementation of that spec with the existing Microsoft open source unix client that already does the rest of the protocol needed for working with AD compatible kerberos (plus wrapping it in python). Re cookies, my proposal is actually far more brain damaged than just storing the ticket in a cookie. It involves the user's plaintext password being transmitted (securely) to Zope, which essentially negates the whole point of Kerberos. For explanation of this common absurd practice see pp22+ at: http://www.ncsu.edu/nt/unity-nt/Unity-NT.pdf especially p24. It's quite safe for passwords that aren't being used for anything else except that access to Zope (including multiple ZEO Zopes etc). Just funnelling "extranet" access via Zope like any other external web authentication system without compromising internal systems. (Zope is being trusted by each external user, not by other internal systems - unlike use of IIS). Can be usable in other ways provided client uses certificates to authenticate the Zope server before revealing it's password over SSL. That is much hairier. But I can't see any problem with the method proposed at the link below for storing tickets like credit card numbers using XOR cookies. Neither the client nor the server stores the actual ticket and it is never transmitted between them. (The original plaintext password used to obtain the ticket is also discarded). Only the *combination* of the cookie subsequently supplied by the client on each "hit", XORed with the one-way encrypted ticket stored by Zope as session data for that client can be used to recover the ticket. So Zope can recover the ticket instantly on each web hit - but only if it was a hit from the client with correct cookie. The client never gets the ticket and Zope never stores it, so anybody cracking either or the link between them is no better off. You still get the benefits of a single ticket for signing on, with expiry and renewal and protection from eavesdropping. Unlike end to end kerberos you have to trust the intermediary (Zope). [Philip] So yes, there are lots of things you *can* do with the ticket - just I'm not sure about whether you can do them *now*. (Kerberos is coming in Samba, as soon as I get some free time) [Albert] Yep. No use can be made of the Microsoft extensions to an AD kerberos ticket now. Great to hear you are doing Kerberos for Samba!!! Please pass on details of this stuff to the people working on Samba NT4 and Win2K domain controller replacement as in the mailing list search at link below. I'm quite sure they'll be anxious for these (fairly trivial) extensions to be included. Sorry, I'm just not involved in Samba myself but you look like the ideal person to take care of this and it will certainly end up helping Zope. -----Original Message----- From: Albert Langer To: 'Mayers, Philip J'; zope@zope.org Sent: 25/03/01 06:12 Subject: RE: [Zope] kerberos ? + LDAP + ecommerce + ZEO replication etc The kerberos ticket certainly *can* be put to "sensible use". An open source unix interoperability kit for using the Active Directory (AD) version of Kerberos is freely available from: http://msdn.microsoft.com/library/techart/kerberossamp.htm It is based on the same underlying software as the PAM modules. The AD "Public Key Cryptography for Initial Authentication in Kerberos." is based on IETF PKINIT draft 09: http://support.microsoft.com/support/kb/articles/Q248/7/53.ASP Other details on MS kerberos can be obtained by search for "kerberos" keyword on MSDN. Except for certain proprietary extensions, the technical specs for which have since been published elsewhere: http://www.gnosis.cx/download/kerbspec.pdf These extensions include a list of the resource and account groups that the principal is a member of, which enable very rapid and scalable use of finely grained AD permissions via only the kerberos "ticket" once the slow initial PKINT logon to obtain that ticket has been done. This is a vast improvement on simple LDAP authentication, which Microsoft attempted, but failed, to keep a "trade secret", presumably to shore up their monopoly against competition from Samba NT domain controllers etc. BTW I've done some detailed study of the AD permissions structure and it's relation to other things if anybody needs help with that side of it. Adding those specs to the freely available unix kit should allow any client on any platform to work with any services dependent on AD and thus avoid being locked out. In particular Zope (on any platform) could provide a web (including XML-RPC/SOAP etc) front end for both access and management by obtaining the client (from any platform) plaintext logon password over a secure transport, never storing it persistently unencrypted, but returning an encrypted kerberos ticket as a cookie for future access. I described a plausible approach for a similar problem with credit card numbers at: http://lists.codeit.com/pipermail/zcommerce/2000-June/000247.html The ticket will automatically expire (and can automatically be renewed) giving all the usual kerberos safeguards, provided the transport is secure and there is no unencrypted persistent storage within Zope. The list of groups can then work well with the Zope acquisition based access control system. Separately, freely available Kereberos and OpenLDAP implementations can be extended to eliminate any need for Win2K AD itself by adding the single valued binary attribute "ntSecurityDescriptor" in the same format as AD. The Samba project ought to be very interested in that: http://marc.theaimsgroup.com/?l=samba-ntdom&w=2&r=1&s=active+directory&q =b So should DC for Zope together with ActiveState that already has expertize in ADSI/COM. (Likewise has major implications for distributed COM+ version of Mozilla XPCOM). http://www.activestate.com/Products/Komodo/PyXPCOM/index.html Zope's ZODB/ZEO also provides an excellent OODBMS "aggressively optimized" for a high ratio of reads to writes that is very suitable for the "active" side of an Active Directory (using BerekelyDB storage similar to that used in OpenLDAP). ZEO is also looking at multi-master replication issues (though the approach looks a bit naive to me). TransWarp is very relevant to the stuff below. http://www.zope.org//Members/pje/Wikis/TransWarp/HomePage PostgreSQL provides an excellent ORDBMS more suitable for the "search" side of a directory than ZODB. It will very soon include python as a backend stored procedure language and has a sophisticated "rules" system. OpenLDAP already provides an excellent front end, including SASL authentication: http://www.openldap.org/software/roadmap.html ACS 4 provides an Oracle based web application server framework with LDAP integration. The kernel has a finely grained permissions system, with a role/party/group framework compatible with the "Accountability" pattern and an object model compatible with the "Domain Object Model" pattern. This is very appropriate for a sophisticated LDAP directory backend (as well as being necessary for the industrial strength RDBMS essential for serious Zope ecommerce). http://developer.arsdigita.com/doc/kernel-doc.html http://www.martinfowler.com/ap2/index.html http://www.martinfowler.com/apsupp/accountability.pdf http://st-www.cs.uiuc.edu/users/johnson/DOM.html ACS4 also provides an excellent workflow engine: http://developer.arsdigita.com/doc/acs-workflow/ This can add the missing "strategy" side of the Domain Object Model together with Transwarp. Zope can provide much better UI and management stuff to work with the engine. It can also be a basis for reliable distributed workflow/transactions/replication: http://www.distribution.cs.ncl.ac.uk/projects/WorkflowSystem/index.html This is a better approach for some types of database replication than that currently proposed for ZEO or the usual approaches described in Chapter 8 of: http://research.microsoft.com/pubs/ccontrol/ ACS4 is being ported to PostgreSQL by OpenACS which has previously ported ACS3: http://openacs.org/4/ http://openacs.org/bboard/q-and-a.tcl?topic_id=12&topic=OpenACS%204%2e0% 20De sign Initial version of kernel already out. Adapting the unix interoperability kit for AD to also use the kerberos extensions for AD groups and permissions and provide a cross platform solution like (and with) OpenSSL is a small project. OpenSSL should have any needed expertize: http://www.openssl.org Public Key Certificate Authority software is also available, including for python: http://www.pyca.de/ A number of better approaches to trust management are well known: http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html Unfortunately that minor adaptation of kerberos clients is peripheral to the main focus of most of the projects mentioned, but could well be a key link for bringing them together to both knock Microsoft off it's perch and provide more decentralized trust and directory services necessary for the rapid explosion of peer to peer networked web services. I sure hope somebody is working on it. If anybody has any relevant links or email addresses please email them directly as well as posting here (I only scan occasional messages from the Zope list). BTW, while I'm at it with all the links above, I'd like to draw attention to some earlier postings re the need for Zope and ACS to combined for viable ecommerce: http://lists.codeit.com/pipermail/zcommerce/2000-June/000265.html http://lists.codeit.com/pipermail/zcommerce/2000-June/000259.html http://lists.codeit.com/pipermail/zcommerce/2000-June/000257.html Right now arsDigita is going through a major upheaval and it looks like OpenACS will provide an umbrella home for various ports of ACS 4, including python/Zope as well as their main orientation to Tcl. The data model of ACS4 is now much better separated from the Tcl side and they are doing a Query Dispatcher for supporting multiple RDBMS ports (with some tools in python for extracting SQL from the Tcl code completely ;-). http://developer.arsdigita.com/commerce-project-central/ http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000b5M&topic% 5fid =web%2fdb&topic= http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000ZGz&topic% 5fid =web%2fdb&topic= A Zopista involved in OpenACS has mentioned working on port of data models of ecommerce module. That could result in a Zope port if there is active support from DC. http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001AP&topic_id=1 2&to pic=OpenACS%204%2e0%20Design At the same time there seems to be some problems with an AOLserver fork that could result in greater interest in using Zserver (don't know much about that - just speculating). If June 2000 was "premature", perhaps this is a better time to hope for some serious DC interest both in enabling an industrial strength ecommerce and workflow system for Zope and in integrating Zope with enterprise systems dependent on AD (if not in eventually replacing AD ;-) -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Mayers, Philip J Sent: Sunday, March 25, 2001 9:12 AM To: 'zope@zope.org' Subject: RE: [Zope] kerberos ? Yes - There's a pam module for Python, and with PythonScripts, External methods and a LoginManager setup, I got it working. Quite slow, which is fine if you only authenticate once, but not if you do it on every HTTP request. (Note: I never bothered to check if LoginManager does once-only or per-request HTTP auth - I only did it as a five minute test, and a quick check on the machine shows that the logs have rotated out :o() The PAM module for Python can be found at www.python.org, go to Search, in the Vaults of Parnassus link type PAM. I'm not sure the ticket you got could be put to any sensible use though... Maybe... Hmm, just had a thought... Cheers, Phil -----Original Message----- From: Darcy Clark To: zope@zope.org Sent: 24/03/01 22:29 Subject: [Zope] kerberos ? has anyone tried to get Zope working with kerberos authentication ? Darcy _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )