The CAS protocol is modelled on the Kerberos protocol. A Service Ticket in Kerberos is encrypted with the secret of the target service, so if you get an ST for svc\foo.com it can only be validated by foo.com. Therefore, a ST in CAS is targeted to a service, but since the service does not share a secret with the CAS server, the validation cannot be done with crypto and instead requires an SSL exchange to the CAS Server where the service says “I am foo.com and I have this ST here, is it valid for me and if so please tell me the netid of the user”. All the client does is to know its own name, and the CAS server does the rest.
SAML on the other hand was originally designed to deliver a set of assertions about a person. I say originally because in most current use, the Assertions are about the “bearer” of the message (the HTTP session through which the SAML message is sent) but that wasn’t the original focus of SAML. SAML was designed originally to say a bunch of things about Joe Blow to foo.com, and it sort of didn’t matter how many hands the message passed through on its way to the intended destination. Originally, if you wanted to authenticate with SAML then one of the Attributes was supposed to be a Certificate or public key, and then the authentication would be done separately using the key. However, once you use “bearer” as authentication, you need something more and that is provided by SAML2 Metadata and the Profiles. The important piece from a security point of view is the underlying transport model and not the service (in CAS) or audience (in SAML). In CAS, the CAS server uses the service not only as the audience of the message but also as the network address to which the browser is redirected. In SAML, the audience of the message (the EntityID of the Relying Party) gets looked up in the Metadata and the SAML is sent to one of the configured AssertionConsumerService location URLs). So in both cases the service/audience is bound (by being the same thing or by a lookup to a configuration) to a specific network destination of the message. That is what makes it impossible for a third party to grab the message and replay it. From: Nate Klingenstein [mailto:[email protected]] Sent: Monday, March 14, 2016 11:05 AM To: Gilbert, Howard <[email protected]> Cc: CAS Community <[email protected]> Subject: Re: [cas-user] Ticket Forwarding Howard, So generally if foo.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__foo.com_&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=QpF8dn_hVuAkPB3pvSiqWRofnccZc_aZFXs0H7dYvJE&m=SwqE77xtn_QqhiDmEFUCZMnPhTiiLlBNY7C63Eg6Q7c&s=51wjrdTqhSiAsb7lI1yYs5nfrXGNVe1SwL1FnH2NEhY&e=> redirects to CAS with service=foo.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__foo.com_&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=QpF8dn_hVuAkPB3pvSiqWRofnccZc_aZFXs0H7dYvJE&m=SwqE77xtn_QqhiDmEFUCZMnPhTiiLlBNY7C63Eg6Q7c&s=51wjrdTqhSiAsb7lI1yYs5nfrXGNVe1SwL1FnH2NEhY&e=>, and then gets back a service ticket, and then redirects the browser with that ticket= to bar.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__bar.com_&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=QpF8dn_hVuAkPB3pvSiqWRofnccZc_aZFXs0H7dYvJE&m=SwqE77xtn_QqhiDmEFUCZMnPhTiiLlBNY7C63Eg6Q7c&s=jMpDAvkNTizCTAuKJnCWPwAccHwVqyTz7TmNrS3rG4U&e=>, then when bar.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__bar.com_&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=QpF8dn_hVuAkPB3pvSiqWRofnccZc_aZFXs0H7dYvJE&m=SwqE77xtn_QqhiDmEFUCZMnPhTiiLlBNY7C63Eg6Q7c&s=jMpDAvkNTizCTAuKJnCWPwAccHwVqyTz7TmNrS3rG4U&e=> tries to validate the ticket with validate?service=bar.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__bar.com_&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=QpF8dn_hVuAkPB3pvSiqWRofnccZc_aZFXs0H7dYvJE&m=SwqE77xtn_QqhiDmEFUCZMnPhTiiLlBNY7C63Eg6Q7c&s=jMpDAvkNTizCTAuKJnCWPwAccHwVqyTz7TmNrS3rG4U&e=> the request is rejected because “bar.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__bar.com_&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=QpF8dn_hVuAkPB3pvSiqWRofnccZc_aZFXs0H7dYvJE&m=SwqE77xtn_QqhiDmEFUCZMnPhTiiLlBNY7C63Eg6Q7c&s=jMpDAvkNTizCTAuKJnCWPwAccHwVqyTz7TmNrS3rG4U&e=>” does not match the service ”foo.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__foo.com_&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=QpF8dn_hVuAkPB3pvSiqWRofnccZc_aZFXs0H7dYvJE&m=SwqE77xtn_QqhiDmEFUCZMnPhTiiLlBNY7C63Eg6Q7c&s=51wjrdTqhSiAsb7lI1yYs5nfrXGNVe1SwL1FnH2NEhY&e=>” presented when the ticket was issued. This is helpful. If I were to reword this, the protocol allows the CAS server to associate the ticket with an intended service, but there’s nothing for a CAS client to check, and this is in the protocol rather than the payload. Is that correct? It’s interesting to me since SAML took the exact opposite approach, relying on the service to discard any inappropriate assertions. I haven’t really thought through pros and cons. Thanks for your help, Nate. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
