Page Comparison

...

Boolean. If true, signed backchannel request must include a timestamp to prevent replay attacks. If false, the timestamp can be included and, if present, will be included in the signature validation, but needn't pass a "freshness" check. Default is true.

TBD: When was this added?

signedUrlToLiveMinutes

If checkTimeStampRange is true, timestamps sent on signed backchannel requests must evaluate to a time within this number of minutes (plus or minus) of current server time. Default is 5.

...

Will be 'and-ed' with termCode and sectionCode when looking up the targeted roster/roster enrollment if either or both of those fields are also present. When sent by itself (i.e. without sectionCode and/or termCode), formattedCourse is an ambiguous roster identifier unless SSP external data has been configured to treat this as a unique section identifier (as was traditionally done in very early 1.x deployments, but is no longer recommended). Otherwise sending this identifier by itself may result in unpredictable behavior.

...

Will be 'and-ed' with formattedCourse and termCode when looking up the targeted roster/roster enrollment if either or both of those fields are also present. But this field is sufficient to uniquely identify a roster when sent by itself. As such, as of 2.5.0, it is the preferred means for identifying the targeted roster via this protocol.

termCode

This is the identifier of the academic term in which the targeted section is offered. Should correspond to v_external_term.code, v_external_faculty_course.term_code, and v_external_faculty_course_roster.term_code.

When sent by itself (i.e. without formattedCourse and/or termCodesectionCode, this identifier is an ambiguous roster identifier and may result in unpredictable behavior.)

studentSchoolId

This is the identifier of a student who is enrolled in the specified section. This value must match the school_id column in the will be considered an error condition). In 2.x deployments prior to 2.5.0, it was often sufficient to send only formattedCourse and termCode, but this was dependent  v_external_faculty_course_roster view. Only relevant if view=ea.newcourse and v_external_faculty_course_roster uniquely identifying a section using only those two fields, which is at odds with usage of those fields elsewhere in external_* tables, and is not recommended when using this protocol in 2.5.0+.

TBD: The 2nd paragraph in the description is wrong... this is new as of 2.5.0.

studentSchoolId

This is the identifier of a student who is enrolled in the targeted section/roster. This value must match the school_id column in the v_external_faculty_course_roster view for the targeted section/roster, and it must also be consistent with values in external_person.school_id and person.school_id representing this student in the SSP database.

Only relevant if view=ea.new. In that case, at least one of studentSchoolId and studentUserName is required as of 2.5.0. Prior to that, only studentSchoolId was required. If this field is present, studentUserName is ignored.

studentUserName

New as of SSP 2.5.0.

This is the schoolId (corresponds to external_person.school_id and person.school_id in the SSP database) of a student who identifier of a student who is enrolled in the specified section/roster. Will  Will be resolved to a school_id, which must match a value in the school_id column in the v_external_faculty_course_roster view. Only will then effectively be treated the same way as studentSchoolId. 

Only relevant if view=ea.new. If In that case, at least one of studentSchoolId and studentUserName is required as of 2.5.0. Prior to that, only studentSchoolId was required. If studentSchoolId is present, this field is ignored.

...

org.jasig.portal.security.sso.mvc.SsoController.checkTimeStampRange=true in SSP Platform's portal.properties.

TBD: When was this added?

token

This parameter is the most complex. It must be equal to the result of hashing (using the MD5 algorithm) the URL-decoded value of the username parameter or schoolId parameter, the URL-decoded value of the timeStamp parameter if present, and the sharedSecret (from portal.properties). The SSO Servlet performs this computation on its own, then compares it's result with the token parameter passed by the client. This is a security measure intended to verify that the client system is authorized to use this service: any client that knows the secret is deemed to be authorized. If the values match, the SSO will be allowed.

If username is present on the request, its value will be validated against token and schoolId will be ignored.

Here is the Java code in SSP that calculates this hash:

    private boolean validateToken(final String usernameusernameOrSchoolId, final String timestamp, final String token) throws UnsupportedEncodingException, NoSuchAlgorithmException {
        final MessageDigest md = MessageDigest.getInstance("MD5");
        md.update(usernameusernameOrSchoolId.getBytes());
        if(timeStamp != null){
        	md.update(timestamp.getBytes("UTF-8"));
        }
        md.update(sharedSecret.getBytes());
        final byte[] hash = md.digest();
        final String md5 = new String(Hex.encode(hash));
        return md5.equals(token);
    }

    // if username="foo", timestamp="2013-08-26T16:44:03Z" and token="monkey", the md5 string will be a62e92eec800a52cf6d4c7a6288f4209

...

{"URL":"http://localhost:8080/ssp-platform/Login?ticket=foo&refUrl=%2Fssp-platform%2Fp%2Fearly-alert%3FpP_action%3DenterAlert%26pP_schoolId%3Dstudent0%26pP_formattedCourse%3DMTH101","success":true}

TBD: Need to add new messages for 2.5.0 and note any others that were version specific. Esp timestamp-related errors.

    HTTP 403 {"message":"The SSO handshake requires a secure connection  (SSL)","success":false}
       org.jasig.portal.security.sso.mvc.SsoController.requireSecure was turned  on, but the request was HTTP.

    HTTP 400 {"message":"One or more required inputs was not  specified","success":false}
       Missing input(s).

    HTTP 403 {"message":"Not authorized","success":false}
       Token was invalid.
 
    HTTP 403 {"message":"SSO key not configured","success":false}
       Feature is disabled

    HTTP 500 {"message":"Authorization check error","success":false}
       System-level failure while handling request, usually during token or timestamp validation.

...