Page Comparison

...

This precise methodology is straightforward. A web application, having received an opaque ticket from the incoming HTTP request (via its ticket parameter), marshals a SAML request to be sent using SOAP, over HTTPS, to the CAS server. The application contacts CAS over a well-known URL and authenticates CAS using CAS's SSL certificate (applying rules at least as restrictive as a common browser's, to prevent spoofing of CAS). Thus, no XML Signatures are necessary; the underlying channel is trusted. Over this secure channel, the application sends a SAML request of the following form:

  <Request
    RequestID="..."
    MajorVersion="1"
    MinorVersion="0"
    IssueInstant="...
  >
    <AssertionArtifact>opaque ticket string</AssertionArtifact>

  </Request>

When CAS recognizes the opaque ticket string sent within this request, it produces a response containing an appropriate assertion, along with supplemental information that the application will need to ensure that the ticket was intended for it and not for another application:

Listing 2

  <Response>
    <Status>
      <StatusCode Value="Success"/>;
    </Status>
    <Assertion
      MajorVersion="1"
      MinorVersion="0"
      AssertionID="..."
      Issuer="URI for CAS login page"
      IssueInstant="date of response, not of TGC"
    >
      <Conditions>
        <AudienceRestrictionCondition>
          <Audience>service URI associated with ticket</Audience>

        </AudienceRestrictionCondition>
      </Conditions>
      <AuthenticationStatement>
        <Subject>
          <NameIdentifier>subject name</NameIdentifier>

        </Subject>
      </AuthenticationStatement>
    </Assertion>
  </Response>

...

This approach is straightforward. To authenticate itself to CAS when sending the request from listing 1, the application supplies an XML Signature using the <Assertion> element's <Signature<; subelement. If it is satisfied with the application's authenticity, CAS includes an <AttributeStatement> in the assertion contained in its response. This statement has the following format:

  <AttributeStatement>
    <Subject>
      <NameIdentifier>subject name</NameIdentifier>

    </Subject>
    <Attribute AttributeNamespace="http://www.yale.edu/cas"
                  AttributeName="pgt">
      <AttributeValue>PGT value</AttributeValue>
    </Attribute>
  </AttributeStatement>

Once a proxy has used the PGT acquired in this statement to generate a PT (again, using an out-of-band mechanism that does not necessarily use SAML), it supplies a SAML document to its target back-end service. (It could also simply provide the ticket as a query parameter, just as in the current model; however, using SAML arguably makes it easier for a back-end service to use multiple authentication schemes.) This SAML document contains the following assertion:

  <Assertion
    MajorVersion="1"
    MinorVersion="0"
    AssertionID="..."
    Issuer="URI for application service"
    IssueInstant="date of assertion, not of PGT"
  >
    <AuthenticationStatement>
      <Subject>
        <NameIdentifier>subject name</NameIdentifier>

      </Subject>
      <SubjectConfirmation>
        <ConfirmationMethod>http://www.yale.edu/cas/proxy</ConfirmationMethod>

        <SubjectConfirmationData>proxy ticket</SubjectConfirmationData>

      </SubjectConfirmation>
    </AuthenticationStatement>
  </Assertion>

...