[Zope] kerberos ? + LDAP + ecommerce + ZEO replication etc

Tue, 27 Mar 2001 01:33:20 +1000

[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 )