Re: [AOLSERVER] authuser
Jeff Rogers schrieb: Does anyone (other than me) think there would be value in allowing the conn username to be updated, i.e., by a new 'ns_conn setauthuser' subommand? i would appreciate it. -gn -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] authuser
On Wed, Mar 05, 2008 at 11:42:38AM -0800, Jeff Rogers wrote: The authUser field of a conn is logged by nslog and can be read with ns_conn authuser but is only set in the driver from basic authentication. Does anyone (other than me) think there would be value in allowing the conn username to be updated, i.e., by a new 'ns_conn setauthuser' subommand? I didn't know any such feature exists at all. Since it does, sure, broadening that support sounds reasonable. The primary benefit would be to let you log usernames with requests in your access log when your authentication method is something other than http basic. You can already log arbitrary additional information to the access log right now. I log the OpenACS user_id to the access log on every request, using the 'ns_param ExtendedHeaders X-User-Tracking' method Vadim Nasardinov figured out back in 2001 What I'd really like, so some way to include the same user_id info in the server/error log! Or even better, some simple way to exactly match up each hit in the access log with all the actions it triggered in the server log. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] authuser
Oh, that's an attractive notion. Very. I wish I'd thought of it years ago, would have simplified a lot of my logging. Actually it still would. Jeff Rogers wrote: The authUser field of a conn is logged by nslog and can be read with ns_conn authuser but is only set in the driver from basic authentication. Does anyone (other than me) think there would be value in allowing the conn username to be updated, i.e., by a new 'ns_conn setauthuser' subommand? The primary benefit would be to let you log usernames with requests in your access log when your authentication method is something other than http basic. A possible secondary benefit would be to standardize how different parts of an application (esp. a pluggable authentication system) could pass around the logged-in username. I have a simple patch to add this to stock 4.5; a better overall approach would be to adopt naviserver's more flexible auth handling. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] authuser
We do this already, haven't committed it back, unfortunately. We also set password. It's very useful, especially if you're supporting more than one authentication method. (Why set password? Uh... probably a new thread is useful for that). -- ReC -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Rogers Sent: Wednesday, March 05, 2008 11:43 AM To: AOLSERVER@LISTSERV.AOL.COM Subject: [AOLSERVER] authuser The authUser field of a conn is logged by nslog and can be read with ns_conn authuser but is only set in the driver from basic authentication. Does anyone (other than me) think there would be value in allowing the conn username to be updated, i.e., by a new 'ns_conn setauthuser' subommand? The primary benefit would be to let you log usernames with requests in your access log when your authentication method is something other than http basic. A possible secondary benefit would be to standardize how different parts of an application (esp. a pluggable authentication system) could pass around the logged-in username. I have a simple patch to add this to stock 4.5; a better overall approach would be to adopt naviserver's more flexible auth handling. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] Pluggable auth modules (was RE: [AOLSERVER] authuser)
OK, so here's the other thread: Alex Hisen I've talked about this, but we haven't pushed forward on a unified model. That's my fault; I just haven't put the cycles into imagining a more comprehensive model than what KnowNow is doing, nor looked at the OpenACS stuff in any depth. What KnowNow does is: * Authentication (authN) is coordinated by a pre-auth Tcl script. That uses a set of callbacks for each authentication module we support. We have authentication modules for Basic, SPNEGO / Kerberos, and cookie-based sessions with form-based challenges. * In that script, we're experimenting with a model where individual drivers are configured for which authN modules to use (so an intranet NIC can require SPNEGO and not support Basic, for example, while a NIC facing the internet can require forms sessions, and Basic can be restricted to SSL). * We have a library for verifying passwords by binding to an LDAP or AD server if necessary, though it's quite ugly -- for efficiency reasons, we usually look up the groups for the user at this stage. We provide an out-of-band communication between this library and the authZ stuff (a cache) (actually, it's far uglier than that, but it's easier to explain this way). * We stuff the user name into the conn's username field, and then we stuff the meta-information about the authN module into the password. This also allows us to do impersonation (where an administrator becomes a person; in this case, the password records the original administrator user). * We hook 401 and 403 so we can determine which challenge (or redirection) to use (and get the domain, realm, and SSL redirect right based on how the connection came in). * We have two grades of anonymous users: true anonymous accesses and identified anonymous users (user ids stored in cookies). The identified anonymous users get treated just as if they'd come in a real authN module; their ID gets stuffed into the username, and the anon handler gets stuffed into the password. * We've ripped out nsperm entirely, since our URL design (and resources) have some real oddities that nsperm can't handle (allow GET for all URLs starting with /a/ and ending in /x/y [yes, those are slashes] to their owner and administrators only). The actual auth module only does authorization (authZ); it uses the 401 403 hooks as necessary to get the appropriate challenges or redirections made. This has evolved over a long time and isn't entirely working yet, and we haven't packaged it at all for contribution back to the community (though the spnego module is close). Overall, though, I think the core decisions about separating authN from authZ, and using Tcl to plumb the policies together are working OK. And to do any of it, we needed setauthuser and setauthpassword. -- ReC -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Michael Roberts Sent: Wednesday, March 05, 2008 12:56 PM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] authuser Oh, that's an attractive notion. Very. I wish I'd thought of it years ago, would have simplified a lot of my logging. Actually it still would. Jeff Rogers wrote: The authUser field of a conn is logged by nslog and can be read with ns_conn authuser but is only set in the driver from basic authentication. Does anyone (other than me) think there would be value in allowing the conn username to be updated, i.e., by a new 'ns_conn setauthuser' subommand? The primary benefit would be to let you log usernames with requests in your access log when your authentication method is something other than http basic. A possible secondary benefit would be to standardize how different parts of an application (esp. a pluggable authentication system) could pass around the logged-in username. I have a simple patch to add this to stock 4.5; a better overall approach would be to adopt naviserver's more flexible auth handling. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
