/proxyValidate should validate both Service Tickets and ProxyTickets.
 However, its the DEPLOYER's choice to accept proxy tickets.  Configuration
for that should not be set up automatically.

The CAS Client only validates against the proxyvalidate call *if* you either
say "allowAllProxy=true" or you provide proxy paths to validate against.


On Tue, Mar 16, 2010 at 3:28 PM, Adam Franco <[email protected]> wrote:

> Joachim,
>
> I've been reading through the protocol to see if I could figure out a
> better fix if the ticket has no reliable differentiation between service
> tickets and proxy tickets. The most relevant thing I've found is this
> statement:
>
> 2.6. /proxyValidate [CAS 2.0]
>>
>> /proxyValidate MUST perform the same validation tasks as /serviceValidate
>> and additionally validate proxy tickets. /proxyValidate MUST be capable of
>> validating both service tickets and proxy tickets.
>> 2.6.1. parameters
>>
>> /proxyValidate has the same parameter requirements as /serviceValidate.
>> See Section 2.5.1.
>>
>
> This makes it sound to me like having phpCAS blindly use proxyValidate for
> everything is the appropriate thing to do if proxy ticket validation is
> desired.
>
> Maybe it would be appropriate to add configuration options to phpCAS to
> force it to only allow service tickets, only allow proxy tickets, or allow
> any (current default). This would allow usage if serviceValidate if the
> client application doesn't need to support proxied authentication.
>
> - Adam
>
> On Tue, Mar 16, 2010 at 3:04 PM, Joachim Fritschi <
> [email protected]> wrote:
>
>> Since i'm the author of the patch, i guess it fixed one bug and introduced
>> another one...I guess i missed that part in the specs.
>>
>> But why bother with a ticket prefix / serviceValidate url if you can't
>> differentiate between both kinds before validating them at the server?
>> Somehow this does not make any sense to me.
>> Is this just backwards compatibility or what is the reason for this ST -
>> PT confusion?
>>
>> Regards,
>>
>> Joachim
>>
>>
>> Scott Battaglia schrieb:
>>
>>> On Tue, Mar 16, 2010 at 2:17 PM, Adam Franco <[email protected]<mailto:
>>> [email protected]>> wrote:
>>>
>>>    *Question (up front for those skimming the list):*
>>>
>>>
>>> Answers, for those looking for them quickly :-)
>>>
>>>
>>>    Should my CAS server be returning proxy tickets that begin with "PT"?
>>>
>>> No, it can return them with ST.  See the spec for more info.  Its been
>>> doing this since 3.0
>>>
>>>    Is this a configuration option?
>>>
>>>
>>> No, its not.
>>>
>>>    Is this something that was added after CAS-3.3.3?
>>>
>>>
>>> No, its been there since CAS 3
>>>
>>> Cheers,
>>> Scott
>>>
>>>
>>>    *Background:*
>>>
>>>    I have been recently testing the latest phpCAS version (1.1.0RC6 /
>>>    https://www.ja-sig.org/svn/cas-clients/phpcas/tr...@48086)  which
>>>    now has a switch that now runs service tickets through a different
>>>    path than proxy tickets. Their relevant change is:
>>>
>>>                         break;
>>>                     case CAS_VERSION_2_0: // check for a Service or
>>>    Proxy Ticket
>>>    -                    if( preg_match('/^[SP]T-/',$ticket) ) {
>>>    -                        phpCAS::trace('ST or PT \''.$ticket.'\'
>>>    found');
>>>    +                    if (preg_match('/^ST-/', $ticket)) {
>>>    +                        phpCAS::trace('ST \'' . $ticket . '\'
>>> found');
>>>    +                        $this->setST($ticket);
>>>    +                        unset ($_GET['ticket']);
>>>    +                    } else if (preg_match('/^PT-/', $ticket)) {
>>>    +                        phpCAS::trace('PT \'' . $ticket . '\'
>>> found');
>>>                             $this->setPT($ticket);
>>>                             unset($_GET['ticket']);
>>>                         } else if ( !empty($ticket) ) {
>>>                             //ill-formed ticket, halt
>>>                             phpCAS::error('ill-formed ticket found in
>>>    the URL (ticket=`'.htmlentities($ticket).'\')');
>>>
>>>    What I noticed in testing is that with this client is that my CAS
>>>    server (3.3.3 with a custom overlay) returns proxy tickets that
>>>    begin with "ST-" rather than "PT-":
>>>
>>>
>>> https://login.middlebury.edu/cas/proxy?targetService=http%3A%2F%2Fchisel.middlebury.edu%2F~afranco%2Fphpcas_cookiestorage%2Fservice%2F%3Fparam%3D1397087449&pgt=TGT-2447-zAWGcUHZvTgFNaTwjWG1nSU0gxiOoCIbbflTgeunLwaMU2nJoq-harpie<https://login.middlebury.edu/cas/proxy?targetService=http%3A%2F%2Fchisel.middlebury.edu%2F%7Eafranco%2Fphpcas_cookiestorage%2Fservice%2F%3Fparam%3D1397087449&pgt=TGT-2447-zAWGcUHZvTgFNaTwjWG1nSU0gxiOoCIbbflTgeunLwaMU2nJoq-harpie>
>>>    <
>>> https://login.middlebury.edu/cas/proxy?targetService=http%3A%2F%2Fchisel.middlebury.edu%2F~afranco%2Fphpcas_cookiestorage%2Fservice%2F%3Fparam%3D1397087449&pgt=TGT-2447-zAWGcUHZvTgFNaTwjWG1nSU0gxiOoCIbbflTgeunLwaMU2nJoq-harpie<https://login.middlebury.edu/cas/proxy?targetService=http%3A%2F%2Fchisel.middlebury.edu%2F%7Eafranco%2Fphpcas_cookiestorage%2Fservice%2F%3Fparam%3D1397087449&pgt=TGT-2447-zAWGcUHZvTgFNaTwjWG1nSU0gxiOoCIbbflTgeunLwaMU2nJoq-harpie>
>>> >
>>>
>>>    <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
>>>        <cas:proxySuccess>
>>>
>>> <cas:proxyTicket>ST-3103-cn5FJWG4Cvv4OdfGNAqZ-griffon</cas:proxyTicket>
>>>        </cas:proxySuccess>
>>>    </cas:serviceResponse>
>>>
>>>    Because phpCAS now switches based on the first part of the ticket
>>>    string, proxy tickets get sent to the serviceValidate URL rather
>>>    than the proxyValidate URL and fail validation. At the end of the
>>>    day, it may be that this phpCAS change is invalid due to the CAS
>>>    Protocol <http://www.jasig.org/cas/protocol> section 3.3.1 allowing
>>>
>>>    proxy tickets to begin with "ST-":
>>>
>>>        Proxy tickets SHOULD begin with the characters, "PT-". Proxy
>>>        tickets MUST begin with either the characters, "ST-" or "PT-".
>>>
>>>
>>>
>>>    *My questions for this list: *
>>>    Should my CAS server be returning proxy tickets that begin with "PT"?
>>>    Is this a configuration option?
>>>    Is this something that was added after CAS-3.3.3?
>>>
>>>    Once I know if my CAS server is messed up or is operating as
>>>    expected, I'll follow up with the phpCAS team to notify them if
>>>    their client change don't fit the protocol correctly.
>>>
>>>    Thanks for your help,
>>>    Adam
>>>
>>>    P.S. I have have attached my logs for the sequence for the client
>>>    app, the service app, and the pgt storage script for reference in
>>>    case they are helpful.
>>>
>>>
>>>    --     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-user
>>>
>>>
>>> --
>>> You are currently subscribed to [email protected] as:
>>> [email protected]
>>>
>>> To unsubscribe, change settings or access archives, see
>>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>>
>>>
>> --
>> You are currently subscribed to [email protected] as:
>> [email protected]
>>
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>
>
> --
> You are currently subscribed to [email protected] as: 
> [email protected]
>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>

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

Reply via email to