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 (Gavin Carr)
----------------------------------------------------------------------
Message: 1
Date: Sun, 10 Sep 2006 10:31:52 +1000
From: Gavin Carr <[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=us-ascii
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
End of modauthtkt-users Digest, Vol 4, Issue 4
**********************************************
