Send modauthtkt-users mailing list submissions to
modauthtkt-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of modauthtkt-users digest..."
Today's Topics:
1. Re: Fallback to guest access (Garrett, Philip (MAN-Corporate))
2. Re: Fallback to guest access (Charles Bueche)
3. Thoughts on how to resolve "require user chains to basic
auth" issue (John Wade)
----------------------------------------------------------------------
Message: 1
Date: Sun, 10 Sep 2006 18:25:46 -0400
From: "Garrett, Philip \(MAN-Corporate\)" <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Fallback to guest access
To: "Gavin Carr" <[EMAIL PROTECTED]>,
<modauthtkt-users@lists.sourceforge.net>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
Gavin wrote:
- ii. if we make it user configurable, what should the default
be?
Now that I spell it out like this, I think we probably do want
it user
configurable. What should the default be though? Which of a.
and b. gives
the least surprising user experience?
My vote is for the current behavior. No surprises for folks who don't read the
changelog for every release. (That includes me!)
Regards,
Philip
P.S. Sorry for the poor formatting -- using OL web client.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://sourceforge.net/mailarchive/forum.php?forum=modauthtkt-users/attachments/20060910/6441d863/attachment.html
------------------------------
Message: 2
Date: Mon, 11 Sep 2006 08:55:12 +0200
From: Charles Bueche <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Fallback to guest access
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I like (a) better. If a logged-in user (not guest) ticket times out, it
should go to login page again to re-authenticate.
Silent-failback to guest as in (b) will only cause calls to helpdesk "I
see a menu entry I can't use" (eg when the browser cache the user-menu).
The most elegant solution is probably a "login as guest" button on the
authentication page. The user has choosen himself what he wants, and
know the consequences.
(please note I haven't used "Guest-mode" so my view isn't authoritative.
And neither if I would have used "Guest-mode" :-)
Charles
Gavin Carr wrote:
> On Fri, Sep 08, 2006 at 11:56:02AM +0200, Charles Bueche wrote:
>> I'm not sure if I understand the issue correctly, but :
>>
>> we use mod_auth_tkt to secure a whole bunch of customer secure sites,
>> including planning physical money transfer for a swiss financial
>> institution. If there is a default behavior, I would rather prefer it to
>> be a DENY.
>>
>> When considering security design, the globally accepted best practice is
>> default==secure.
>
> Sure. But this is really more a usability issue than a security one, I
> think. The specific issue is this:
>
> - mod_auth_tkt is configured for guest access i.e. anyone who connects gets
> authenticated as a guest and given access to some subset (presumably) of
> your site (or privilege levels)
>
> - a user logs in and receives a valid (non-guest) user ticket. When that
> ticket times out, what to we do?
>
> a. Just treat as a timeout, and redirect them to the login page to
> reauthenticate. Note that if they don't login again (just hit the
> back link, say), because we've destroyed their old ticket they'll
> get issued a new guest ticket and will have access to guest
> content anyway. If they do login, they'll be back to where they
> were before with their normal user privileges.
>
> b. Automatically reissue them with a guest ticket. If they're in a
> guest-accessible location, they'll stay where they are, but with
> guest privileges. If they're in a location that's not guest-
> accessible, they'll be redirected to the unauthorised URL, and
> be given the opportunity to login again.
>
> So in neither case can they access content that isn't available to
> guests. If that's misconfigured, of course, you're probably already toast.
>
> So my two questions are:
>
> - i. do we ever NOT want the fallback-to-guest functionality? i.e. should
> we make it user configurable (which is what Philip has done)
>
> - ii. if we make it user configurable, what should the default be?
>
> Now that I spell it out like this, I think we probably do want it user
> configurable. What should the default be though? Which of a. and b. gives
> the least surprising user experience?
>
> Cheers,
> Gavin
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> modauthtkt-users mailing list
> modauthtkt-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
--
Charles Bueche <[EMAIL PROTECTED]>
sand, snow, wave, wind and net -surfer
------------------------------
Message: 3
Date: Mon, 11 Sep 2006 09:35:01 -0500
From: John Wade <[EMAIL PROTECTED]>
Subject: [modauthtkt-users] Thoughts on how to resolve "require user
chains to basic auth" issue
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Hi All,
First thanks to Gavin and all for putting together a great module, this
is clean, straightforward, and manageable and really meets our needs.
Thanks!
Back in April there was a discussion on this list about the issue of
apache reverting to basic authentication when the config has a "require
user" directive, but the authenticated user is not authorized to access
the directory. Gavin had responded that the behavior was
"non-optimal" but that no one had had time to look at it in depth.
I took a look at it, and my guess is that the problem is that in the
cases where we are not using tokens, (i.e. either require valid-user or
require user) the module authenticates users, but does not authorize
them. Since the "auth_tkt_check function is registered as
APR_HOOK_FIRST, the authorization for both of these cases is passed down
the chain and handled by the "check_user_access" function in mod_auth
(see /modules/aaa/mod_auth.c in the apache 2.0 source tree) Since
mod_auth knows nothing about mod_auth_tkt, it returns HTTP_UNAUTHORIZED
which triggers the basic auth retry instead of the preferred redirect to
the TKTAuthUnauthURL
It would seem that there are two possible solutions to this.
1. Add a directive to the mod_auth_tkt configuration like:
TKTAuthRequire. This could use the same syntax as "require user" or
"require valid-user". We would then have to implement the
authorization check by replicating the code from the "check_user_access"
function in mod_auth.c in the "auth_tkt_check" function with the
appropriate changes to redirect to the TKTAuthUnauthURL if the user is
not authorized. This approach has the advantage that it should not
break any existing configuration.
2. Continue to use the standard "require user" and require "valid-user"
directives, but implement the authorization in the "auth_tkt_check"
function (once again by essentially copying the section from the
check_user_access" function in mod_auth.c ) I am not sure of the
feasibility of this for several reasons, but I will defer to those more
knowledgeable. The first potential problem is that I suspect this
function gets called for all check_user_id calls, thus it would probably
break the fail through to basic authentication for those who wanted to
use both techniques in different directories. I also am not sure if
the function call "ap_get_module_config(r->per_dir_config,
&auth_tkt_module)" will return the "require user" directives which are
probably registered by the mod_auth module.
I am willing to give a stab at putting together a patch for this if
anyone has any suggestions about the correct way to implement this or if
anyone has any other insights.
Thanks in advance for your advice,
John Wade
------------------------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------
_______________________________________________
modauthtkt-users mailing list
modauthtkt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
End of modauthtkt-users Digest, Vol 4, Issue 5
**********************************************
