If you consider a new ticket a new authentication request what are you doing with the old session if the ticket is invalid?

Ignoring the ticket seems to be a poor choice if it is some kind of intentional reauthentication. Then you would miss a killed TGT session for example if you don't have Single Sign-Out enabled. But on the other hand killing the old session would open a security hole where anyone could kill my session and data by supplying me with a fake ticket embedded in some link.

Regards,

Joachim


Am 25.05.2010 05:59, schrieb Scott Battaglia:
I would lean towards either generating it as an error or considering it
a new session.

The CAS Client for Java, if it sees a ticket, will treat it as a new
authentication request.

Cheers,
Scott


On Thu, May 20, 2010 at 3:25 PM, Joachim Fritschi
<[email protected] <mailto:[email protected]>> wrote:

    One of the issues [1] that was recently opened for the phpCAS client
    has left me with a question i struggle with answering myself. The
    cas protocol definition hasn't helped me much.

    How should a cas client react if i submit a new [SP]T during a valid
    session and the new ticket was not explicitly requested with one of
    the clients own functions (recheck authentication with a gateway or
    renew call)?

    I have gathered a few options and have tried to analyse them below:

    1. ignore the ticket
      a) remove it from the url and log it to the debug log
      b) ignore ticket and issue some error message that this is not
    supported + reload page button with ticket removed
    2. validate the ticket
      a) if valid update the session with possible new data (attributes,
    ticket info for single logout etc.)
      b) if invalid
         I) ignore
         II) kill old session


    1-b seems to be the best solution. Simple and clean. If they want to
    reauthenticated they can use one of the client supplied funtions.
    The customer gets an error and can resume the old session.

    1-a is not that good since it will bury the error somewhere in the
    debuglog.

    2-b-II is a really bad since it will allow a malicous user to kill
    your session with a bad ticket.

    That leaves the combination 2-a / 2-b-I . This is also a potential
    security hole since this will not revalidate a session but only
    update the attributes. (That should be cached by the server anyway,
    right ?) This might lead to some confusion for the users.

    Am i missing something? Thanks in advance for your ideas and input.

    Regards,

    Joachim

    [1] http://www.ja-sig.org/issues/browse/PHPCAS-61

    --
    You are currently subscribed to [email protected]
    <mailto:[email protected]> as: [email protected]
    <mailto:[email protected]>
    To unsubscribe, change settings or access archives, see
    http://www.ja-sig.org/wiki/display/JSG/cas-dev


--
You are currently subscribed [email protected]  
<mailto:[email protected]>  as: [email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-dev



--
Joachim Fritschi
Hochschulrechenzentrum (HRZ)
L1|01 Raum 248
Petersenstr. 30
64287 Darmstadt

Tel. +49 6151 16-5638
Fax. +49 6151 16-3050
E-Mail: [email protected]

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to