OpenCCC SSO Gateway Landing Page
Request Signing
When the SSO Gateway is unable to find a EPPN → CCCID mapping, it will need to make a request to OpenCCC in order to build that mapping.  This will be accomplished by redirecting the user to the SSO Gateway landing page in OpenCCC.  The SSO Gateway landing page requires 3 arguments:  eppn, redirectMessage and redirectUrl.
eppn: Â The EPPN value for the user that is attempting to reach a service protected by the SSO Gateway
redirectMessage: the "SP name from the IdP name" string that is displayed on the landing page to make the redirect feel less suspicious.
redirectUrl:  The URL to return to once the EPPN → CCCID mapping has been created.
In order to ensure that untrusted users are not doing URL hacking in order to register bad mappings, the SSO Gateway will need to sign each request to the SSO Gateway landing page. Â We will use HMAC_SHA256 to generate the signature. Â The signature will be generated from the request parameters and a secret key that will be shared by the SSO Gateway and the SSO Gateway landing page.Â
Format of signature string
In order to ensure that the SSO Gateway and the SSO Gateway landing page are both able to generate the same signature, they must agree on the format of the message that is signed. Â The current message format is based on how LTI signs messages, but is simplified.
To generate the message that needs to be signed:
- Sort all GET parameters alphabetically.
- URL encode the values for all GET parameters
- Add parameters to a GET format parameter string
- Sign the message string
- Generate a final URL that includes all the GET parameters and an additional "signature" parameter with the calculated signature.
The SSO Gateway landing page will repeat these steps and ensure that the signature generated by the SSO Gateway matches the signature generated by the landing page.
Example:
eppn: Â test@test.com
redirectUrl: Â https://www.google.com
Signing message: Â eppn=test%40test.com&redirectUrl=https%3A%2F%2Fwww.google.com
Signing message must include all GET parameters included in the final request except the "signature" parameter. Message uses simple URL format but the GET parameters must be listed in alphabetical order.
signature (using 'test' as a secret key): Â b78a0b9069957cd547b3a4e7ef54a3ab3392e7612f4ecfea2c8f13b652279534
Note that final URL does not require parameters to be in any specific order.