CAS protocol violation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CAS protocol violation

Andrew Morgan
It appears that Shibboleth v3.3.1 does not generate Service Tickets that
are compliant with the CAS Protocol specification when the
encodingTicketService is used.  Specifically, the Service Tickets contain
an underscore character.  The CAS Protocol only allows {A-Z, a-z, 0-9},
and the hyphen character {-}:

   https://apereo.github.io/cas/development/protocol/CAS-Protocol-Specification.html#37-ticket-and-ticket-granting-cookie-character-set

I found this issue while troubleshooting a problem with a mod_auth_cas
v1.1 client that was looping continuously, adding a new ticket with every
loop.  v1.1 of mod_auth_cas has stricter character set validation that
earlier versions.  This issue was also identified in
https://github.com/apereo/mod_auth_cas/issues/134, and is probably the
root cause of the incompatibility, not the ticket length.

Jira IDP-1018 mentions an incompatibility with mod_auth_cas that came up
during testing.  Maybe this is it?  Is it possible to fix this issue in
Shibboleth?  If this hasn't come up already, I'm happy to file a new Jira
for it.

Thanks,
  Andy
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CAS protocol violation

Marvin Addison
On Mon, Mar 12, 2018 at 4:51 PM Andrew Morgan <[hidden email]> wrote:
It appears that Shibboleth v3.3.1 does not generate Service Tickets that
are compliant with the CAS Protocol specification....
https://apereo.github.io/cas/development/protocol/CAS-Protocol-Specification.html#37-ticket-and-ticket-granting-cookie-character-set

The IdP CAS protocol support targets the v2 specification [1] that puts no restrictions on ticket entity character sets.

This issue was also identified in
https://github.com/apereo/mod_auth_cas/issues/134

Did you try Dave's patch? I'm pretty sure the issue is "fixed" but we're waiting for some positive feedback before merging his patch. Your feedback would be helpful to moving it along.

Personally, I'm not too keen on trying to make the EncodingTicketService compatible with such a restrictive character set as defined in the v3 protocol spec. I suppose we don't _have_ to use a baseN encoding scheme, but it's a justifiable choice that is non-compliant due to the '=' padding character.

M



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CAS protocol violation

Andrew Morgan
On Mon, 12 Mar 2018, Marvin Addison wrote:

> On Mon, Mar 12, 2018 at 4:51 PM Andrew Morgan <[hidden email]> wrote:
>
>> It appears that Shibboleth v3.3.1 does not generate Service Tickets that
>> are compliant with the CAS Protocol specification....
>>
>> https://apereo.github.io/cas/development/protocol/CAS-Protocol-Specification.html#37-ticket-and-ticket-granting-cookie-character-set
>
>
> The IdP CAS protocol support targets the v2 specification [1] that puts no
> restrictions on ticket entity character sets.
>
> This issue was also identified in
>> https://github.com/apereo/mod_auth_cas/issues/134
>
>
> Did you try Dave's patch? I'm pretty sure the issue is "fixed" but we're
> waiting for some positive feedback before merging his patch. Your feedback
> would be helpful to moving it along.
>
> Personally, I'm not too keen on trying to make the EncodingTicketService
> compatible with such a restrictive character set as defined in the v3
> protocol spec. I suppose we don't _have_ to use a baseN encoding scheme,
> but it's a justifiable choice that is non-compliant due to the '=' padding
> character.

I haven't tried the patch myself.  My use of mod_auth_cas is v1.0.9.1 in
Debian 8.  It looks like I'll have this same problem in Debian 9 though.
One of our departments on-campus is using mod_auth_cas v1.1 and ran into
this problem.

At first, I thought this was a new restriction in v3 of the protocol too.
However, take a look at section 3.7 of the v2 spec...  Same character
class restriction.

Given the character class restriction, I wonder if the patch will ever be
accepted into mod_auth_cas.  :/

  Andy
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CAS protocol violation

Marvin Addison
On Mon, Mar 12, 2018 at 5:55 PM Andrew Morgan <[hidden email]> wrote:
At first, I thought this was a new restriction in v3 of the protocol too.
However, take a look at section 3.7 of the v2 spec...  Same character
class restriction.

Wow. I was so sure that the character set was an editorialization on top of the original document [1], but I'm just wrong. That raises the priority in my view to "something we probably should fix." Thinking on it more, it's probably not too much work to simply use base 32 encoding and swap out the "=" padding character with "-" in a post-encoding/pre-decoding step. I've filed an issue to track it:


Given the character class restriction, I wonder if the patch will ever be
accepted into mod_auth_cas.  :/

While your observation about character set requirements in the protocol makes it less palatable perhaps, one could argue it's a reasonable improvement nonetheless. In any case I'm fairly certain dhawes would consider positive feedback on the patch as a sign that it should be accepted.



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CAS protocol violation

Voradesh Yenbut
I am not sure if this is relevant.

Anyway, at our site, in order for shiboleth-idp 3.3.1/3.3.2 to work
with mod_auth_cas-1.0.9.1 or mod_auth_cas-1.1 on Fedora systems, a new
"CASBase64.java" was made from "Base64.java" in commons-codec-1.10
with all of its routine names changed from Base64 to CASBase64 and one
base64-encoding character changed as follows:

--- Base64.java 2018-03-13 09:36:34.623321637 -0700
+++ CASBase64.java 2017-03-20 13:44:19.000000000 -0700
@@ -90,8 +90,8 @@
     private static final byte[] URL_SAFE_ENCODE_TABLE = {
             'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M',
             'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z',
             'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm',
             'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',
-            '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '-', '_'
+            '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '-', '.'
     };
 
@@ -115,7 +115,7 @@
     private static final byte[] DECODE_TABLE = {
             -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
             -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-            -1, -1, -1, -1, -1, -1, -1, -1, -1, 62, -1, 62, -1, 63, 52, 53, 54,
+            -1, -1, -1, -1, -1, -1, -1, -1, -1, 62, -1, 62, 63, 63, 52, 53, 54,
             55, 56, 57, 58, 59, 60, 61, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3, 4,
             5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,
             24, 25, -1, -1, -1, -1, 63, -1, 26, 27, 28, 29, 30, 31, 32, 33, 34,

(I did not see '_' or '.' character at https://issues.shibboleth.net/jira/browse/IDP-1265.)

A compiled CASBase64.java, CASBase64.class, is added to
commons-codec-1.10.jar, and CASBase64 is made used by the following
beans in cas-protocol.xml:

  <bean id="CASencodedTicketSealer" lazy-init="true"
     class="net.shibboleth.utilities.java.support.security.DataSealer"
     p:keyStrategy-ref="shibboleth.DataSealerKeyStrategy"
     p:encoder-ref="CASbase64Codec"
     p:decoder-ref="CASbase64Codec" />

  <!-- CASBase64 is org.apache.commons.codec.binary.Base64 with encoding '_' character changed to '.' -->
  <bean id="CASbase64Codec" class="org.apache.commons.codec.binary.CASBase64"
     c:lineLength="0"
     c:lineSeparator="#{new byte[] {10} }"
     c:urlSafe="true" />

That seems to have worked until we hit another problem when large
number of attributes are passed via XML and a buffer in mod_auth_cas
had to be increased.

---
Voradesh Yenbut

Computer Science & Engineering
University of Washington


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]