> User Agent ---- zope site ---- LDAP Break "zope site" into Web Server and the module in the web server that runs the application.
> the User Agent being a web browser. You do not want to restrict read > access to the document as long as the accessor is authenticated. > Correct so far? I guess. > If so then there is a problem that I cannot solve: The > challenge-response Authentication mechanism between User Agent and LDAP > must exchange messages, Yep. > and the web site in the middle must forward > them back and forth, including protocol conversion between whatever the > User Agent implements (HTTP digest authentication?) and the SASL library > in the LDAP. Not likely. > I would guess that there is no ready solution for this but > I admit that I know little of web site programming and the libraries > that might be available there. Nope. > Most likely, what you can have is either: > User Agent --- login,password --- zope site --- c/r --- LDAP > i.e. password authentication against the site which in turn uses the > password to initiate a SASL bind against the LDAP, or: Yep. > User Agent --- c/r --- zope site --- secret lookup --- LDAP > i.e. c/r authentication against the site which fetches the necessary > secret information from the LDAP. > In the latter case the site would use a single LDAP account to fetch > each secret and access the documents. Ick. > The first approach is very probably easier to implement. And less stupid; you loose all of LDAP's security (ACLs, etc...) this way. The user agent [browser] must authenticate TO THE APPLICATION (in your case you zope thingy). The web server may be able to do this for your, depending. Or you application does it. How the application handles authentication is an issue with the application. > Oh, and do you need to create the accounts through the site or is an > offline tool acceptable? Eh? What are you talking about? Accounts are in LDAP, who cares how you create them. If the accounts are not in LDAP then what are we talking about? > One cannot, to my knowledge, create the secrets > for file-based SASL c/r authentication through the LDAP. Don't use file-based SASL secrets. Put them in the Dit. SASL secrets in a file are a PITA - you have to back them up, replicate them, etc... And since you have an LDAP server sitting there... --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
